AI CompendiumA public chart of the language
Home / Patterns of Work / AI-Assisted Development
Patterns of Work

AI-Assisted Development

Day-to-day engineering with a model in the loop.

Definition

Using AI across the normal work of building software: drafting code, writing tests, explaining unfamiliar code, reviewing diffs, debugging. Incremental rather than a new paradigm.

The gains come from the boring parts — boilerplate, tests, migrations, first drafts, searching a codebase you do not know. The parts that need judgment still need judgment, and review does not disappear.

The evidence is genuinely mixed and worth holding both halves. A controlled experiment on a specific task found a large speed-up; a randomised trial on experienced maintainers working in their own repositories found tasks took longer. Both results are real, which means the answer depends on task shape, familiarity and how the tool is used.

How people use it
An engineer describing their workflow.
"I write the design and the tests; it writes the first draft of the code. Review is where my time went, not away."
Worked examples

Where the time actually goes

A team wants to know whether their tooling is paying off.

Measure your own workflow rather than citing someone else’s study. The two most common findings are that generation is fast and verification is not, and that gains concentrate in unfamiliar code and boilerplate while experienced work in familiar code can get slower.

Reading productivity studies honestly

A headline number is quoted in a planning meeting.

Check the population, the task and the year. A single narrow task, or a tool set from eighteen months ago, does not transfer to your team. The research is useful for the mechanisms it identifies, not as a forecast of your results.

Sources
Related terms