LLMs in development: the 4 approaches teams use and how they differ

LLMs have stopped being just smart autocomplete and have become a full-fledged development tool. But behind the phrase 'coding with AI' lie very different practices — from targeted hints to almost complete code delegation to the model.

Two Main Axes

To avoid mixing these scenarios into one category, it's convenient to look at two parameters. The first is how much a person is involved in the code itself: do they write it by hand, read it, edit and review it, or mainly hand off the task to the model and receive finished fragments or entire modules. The second is how exactly the team validates the result: by feel and manual clicking or through formal mechanisms like tests, types, and specifications.

At the intersection of these axes, we get a simple 2×2 matrix. It's useful because it eliminates the false debate about whether it's 'right' or 'wrong' to use AI in development. In reality, the question isn't about ideology, but about the mode of operation.

The same tool can be a safe accelerator in one process and a source of chaos in another, if the team doesn't understand who is responsible for the code and how its correctness is confirmed.

Four Modes of Operation

From this framework, four practical approaches emerge, and each looks normal in its own way for a team. They differ not only in the degree of trust in the model, but also in how much engineering discipline is required after generation. In some cases, LLM remains a convenient assistant next to the developer, in others it becomes almost an autonomous executor.

This is exactly where you can see why debates about AI's usefulness often miss the point: people are comparing different processes. * Manual code + informal validation. The developer writes the main code themselves, while LLM helps with autocomplete, refactoring, and small pieces.

Validation is a quick run and visual inspection. * Manual code + formal validation. AI remains an assistant, but any change goes through tests, typing, linters, and code review.

This is the most predictable mode for a product team. * Delegated code + informal validation. Models are entrusted with entire functions, pages, or services, and a person checks if it 'seems to work'.

Speed is high, but the risk of hidden defects is even higher. * Delegated code + formal validation. The most ambitious option: LLM generates large chunks of the system, and quality is maintained through a good set of tests, 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 the speed of detecting it. As long as the model helps in local areas, a person usually has time to notice oddities when reading the code. But when large blocks of responsibility are handed to it, without formal validation, the project quickly starts to accumulate bugs, logic duplication, and non-obvious dependencies. The higher the autonomy of the model, the more expensive shallow validation becomes.

Why the Choice Matters

Many teams confuse the speed of the first result with the speed of development as a whole. Informal validation does give a sense of progress: the screen opened, the button works, so everything is done. But this approach misses regressions, edge cases, and architectural errors.

This 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 layer of automatic validation should be. Without it, AI doesn't reduce work, it shifts it in time — problems surface later, when the code is already embedded in the product.

But if tests, types, and specifications are well-configured, the model can be used much more boldly: not just for hints, but for drafting complete tasks.

What This Means

There is no universal way to 'code with LLM'. It's more useful for teams to not argue about AI magic, but to honestly choose their mode: where a person must read and edit code, and where they can delegate; what counts as sufficient validation and what doesn't. It is this combination, not the loudness of promises, that determines whether LLM will become a development accelerator or a factory of expensive mistakes.