LLMs in development: four approaches teams use and how they differ

LLMs have stopped being merely smart autocomplete and have become a full-fledged development tool. But the phrase "coding with AI" covers very different practices, from targeted suggestions to handing nearly all the code over to the model.

Two main axes

To avoid lumping these scenarios into one category, it helps to look at two parameters. The first is how involved a person is in the code itself: whether they write it by hand, read, edit and review it, or mostly hand the task to the model and receive finished fragments or whole modules. The second is how the team verifies the result: by gut feel and manual clicking around, or through formal mechanisms such as tests, types and specifications.

Where these axes cross, you get a simple 2×2 matrix. It is useful because it removes the false debate over whether using AI in development is "right" or "wrong." In practice, the question is not ideology but working mode. The same tool can be a safe accelerator in one process and a source of chaos in another, if the team does not understand who is responsible for the code and what confirms that it is correct.

Four working modes

Four practical approaches grow out of this scheme, and each looks normal to a team in its own way. They differ not only in how much the model is trusted, but also in how much engineering discipline is needed after generation. In some cases the LLM remains a handy assistant next to the developer; in others it becomes an almost autonomous executor. This is why arguments about the usefulness of AI so often miss the point: people are comparing processes that are not the same.

• Manual code + informal verification. The developer writes the core themselves, while the LLM helps with autocomplete, refactoring and small pieces. Verification is a quick run and a visual check.
• Manual code + formal verification. AI stays an assistant, but every change passes through tests, typing, linters and code review. This is the most predictable mode for a product team.
• Delegated code + informal verification. The model is given whole functions, pages or services, and a human checks whether it "seems to work." Speed is high, but the risk of hidden defects is higher still.
• Delegated code + formal verification. The most ambitious option: the LLM generates large parts of the system, and quality rests on a good test suite, contracts and strict environment constraints.

The main difference between these modes is not the volume of generated text but the cost of an error and how quickly it is detected. While the model helps in local spots, a person can usually notice oddities while reading the code. But when large blocks of responsibility are handed over, a project without formal validation quickly starts accumulating bugs, duplicated logic and non-obvious dependencies. The more autonomous the model, the more expensive superficial checking becomes.

Why the choice matters

Many teams confuse the speed of the first result with the speed of development overall. Informal verification does give a sense of progress: the screen opens, the button clicks, so everything is done. But this approach is poor at catching regressions, edge cases and architectural errors. It is especially noticeable when an LLM confidently writes code in a style unfamiliar to the team, or adds solutions that look plausible but contradict the project's internal rules.

Hence the practical conclusion: the further you move toward delegation, the stronger the automated verification layer must be. Without it, AI does not reduce work but shifts it in time, and problems surface later, when the code is already built into the product. If tests, types and specifications are set up well, the model can be used far more boldly: not only for suggestions but for draft implementations of entire tasks.

What this means

There is no universal way to "code with an LLM." Instead of arguing about the magic of AI, teams are better off honestly choosing their mode: where a human must read and edit code and where delegation is acceptable, and what counts as sufficient verification and what does not. It is this combination, not the loudness of the promises, that decides whether an LLM becomes a development accelerator or a factory of expensive errors.