Engineering AI, Copilots and Code Generators: A Taxonomy

"AI writes code now" describes four different products with four different failure modes.

A team that buys a copilot expecting a deliverable is disappointed. A team that evaluates a code generator the way it evaluates a copilot measures the wrong thing. And a team that assumes any of them removes the need to understand the code they ship learns otherwise, usually in production.

This is an attempt at a taxonomy. Not a ranking, because the families answer different questions, and the honest answer to "which one" is usually "which of these problems do you have".

1. Why the vocabulary is broken

Four words do most of the damage :

• "Assistant" and "copilot" are used both for tools that complete a line as you type and for tools that produce a whole file from a description. Those are different products.
• "Agent" now means anything from a loop around a chat model to a system that opens a pull request. The word tells you nothing about what you receive.
• "Generation" covers both a snippet and a runnable project with tests. The gap between those is most of the work.

The result is that vendor comparisons happen at the level of model quality, which is the least discriminating variable available, because everyone has access to similar models.

2. The criterion that actually separates the families

The useful question is not how the tool works. It is what it hands you, and who owns what happens next.

Two dimensions:

• Unit of output. A completion, a file, a project, or a running service.
• Who carries the integration burden. You, or the tool.

That second dimension is the one that gets ignored, and it is where the cost lives. A tool that produces good code you then have to wire in, test, document and make deployable has handed you a starting point. Whether that is a good deal depends entirely on how much of the remaining work you were going to do anyway.

3. The four families

The two middle families get conflated most often, and they differ on the dimension that matters. A conversational model produces plausible code fast, and leaves you to determine whether it handles the cases you did not mention. A specialized generator produces a narrower range of things, and is accountable for the artefacts around the code.

The fourth family is included deliberately, because for a large share of data ingestion work it is the correct answer.

4. What each family is genuinely good at

In-editor completion. Best-in-class at reducing keystrokes on code you already know how to write. The value is real and it compounds across a working day. What it is not good at is the code you do not know how to write, because you cannot evaluate a suggestion in a domain you are unfamiliar with. That is the failure mode: a plausible completion in unfamiliar territory is more dangerous than no completion.

Conversational generation. Best-in-class at breadth. Any language, any framework, any problem, immediately, plus an explanation. Unbeatable for exploration, for unfamiliar syntax, for a first pass at something you will then rewrite. The failure mode is the one everyone has met: code that runs on the example and quietly omits the handling of everything the prompt did not mention. It optimizes for a working demonstration, because that is what it was rewarded for.

Specialized generation. Best at producing the full artefact set for a bounded problem, because the boundary is what makes the completeness possible. If a system only ever produces one kind of thing, it can be accountable for the tests, the schema and the documentation of that thing. The trade is scope: outside its domain it does nothing. And the honest risk is that a complete-looking deliverable invites less scrutiny than a snippet.

Managed platform. Best when the source is in the catalogue and you would rather not own the code. That combination covers a lot of real situations, and treating it as a compromise is a mistake. The failure modes are known and they are commercial rather than technical: cost at volume, and the sources the catalogue does not cover.

5. Each family fails a different evaluation

The most common tooling mistake is not choosing the wrong family. It is evaluating one family with the criteria of another, which produces a confident decision based on a measurement that did not apply.

6. Choosing: four questions

Not "which tool is best", but "which of these is true for you".

Is the code you need in a domain your team knows well? If yes, completion tools give you the most value per euro, and generation adds process overhead for little gain.

Are your sources in a managed platform's catalogue? If yes, and you have no strong portability requirement, buy the platform. Building what you can buy is a common and expensive error.

Do you need to own and deploy the code? Compliance, air-gapped environments, exit-risk policies, or wanting to modify behaviour without waiting for a vendor. If yes, the managed family is out regardless of its other merits.

Is the work repetitive across many similar instances? Fifty sources of the same shape is where specialized generation earns its keep. Three sources is probably not worth changing your process for.

A note on how each family is priced
Pricing model shapes the decision more than most evaluations account for, because it determines who absorbs the cost of growth. Completion tools are priced per seat, which makes the cost predictable and independent of how much you use them.
Conversational tools are priced per seat or per token, and the token variant means your bill moves with your usage in ways that are hard to forecast. Specialized generators tend to be priced per unit of output or per seat, which ties cost to work delivered. Some managed platforms are priced on data volume, the model that surprises teams most often, because volume grows on its own and the bill grows with it.
The practical consequence: a comparison run at today's volume can invert entirely at next year's. Volume pricing is defensible for a managed service, but it's a reason to run the arithmetic at the scale you expect rather than the scale you have.

7. Where the categories are converging

Two movements worth watching, because they will make this taxonomy less useful over time.

Completion tools are moving up. Editor-integrated agents now open branches and produce multi-file changes. The unit of output is growing, which pushes them toward the generation families and raises the same question about accountability for tests and documentation.

Managed platforms are moving toward code. Several now offer connector development frameworks, which is an admission that the catalogue will never be complete. That narrows the gap from the other direction.

What will not converge is the criterion in section 2. Whatever the tools are called in two years, the question of what you receive and who owns the remaining work will still separate them, and it will still be the question vendor comparisons avoid.

What this taxonomy leaves out

Two things, named because a classification that pretends to be complete is less useful than one that states its edges.

It says nothing about model quality. Deliberately. Model capability moves every few months and it is broadly shared across vendors, so a taxonomy built on it would be obsolete before it was published. What persists is the shape of what you receive.

It does not cover tools that generate things other than code. Test generation, documentation generation, schema inference, and query assistants all exist and none of them fit cleanly here. A team assembling a toolchain will end up combining families and categories, which is normal and not a flaw in the choice.

What to take away

Four families, separated by unit of output and by who carries the integration burden. Completion for code you already know. Conversation for breadth and exploration. Specialized generation for repetitive, bounded, artefact-heavy work. Managed platforms when the catalogue covers you and ownership does not matter.

Most teams need more than one. The mistake is not picking wrong, it is picking a family whose failure mode you have not thought about.

And the question that outranks all of it: whoever reviews the output, do they know what a production-grade version of this looks like. No family removes that requirement, and the ones that produce the most complete-looking output are the ones where forgetting it costs the most.

PrettyWhale.ai sits in the third family, for one domain: ingestion and integration code. Given a source sample it produces the code, unit tests, data quality checks, schemas, configuration, orchestration and documentation, as portable code you own.