Shipping 69% of Engineering Work with Agentic Coding: What I Learned

Between February 2025 and June 2026 I logged 398 engineering deliveries across 20 product lines. Of those, 275 — roughly 69% — were shipped using agentic coding workflows.

That number is not a boast. It is a sample size large enough to say something more useful than “AI is transformative” or “AI is overhyped”. Both of those are lazy. The interesting question is which parts of the work actually change.

What agentic coding is, minus the marketing

Autocomplete suggests the next line. Agentic coding is different: you describe an outcome, and the tool reads the codebase, plans an approach, edits multiple files, runs the tests, and reports back.

The distinction that matters in practice: autocomplete speeds up typing; agentic workflows change what you spend attention on. You stop writing boilerplate and start reviewing decisions. Whether that is a gain depends entirely on how good your review is.

Where it consistently helps

Migration and refactoring work

This is the strongest fit. Migrations are mechanically repetitive but require holding a lot of context — exactly the shape where the tooling pays off.

During the Odoo v14 → v18 migration covering 213 modules, the repetitive transformations were an obvious candidate. The verification, however, was not delegated. Which brings me to the rule that governs everything below.

Writing tests for existing code

Describing intended behaviour and letting the tool generate cases, then pruning the ones that test nothing, is materially faster than writing suites by hand. Coverage on legacy code goes from “we should” to “we did”.

Infrastructure and configuration

Docker configs, CI pipelines, nginx rules. Fiddly, well-documented, and easy to verify by running them. During the DigitalOcean → AWS migration, standardising security across 12+ containers was largely this kind of work.

First-draft implementations

Getting to a working-but-imperfect version quickly, then reshaping it. Reviewing something concrete beats staring at an empty file — as long as you actually reshape it rather than shipping the draft.

Where it costs you

Anything requiring domain judgement

Building Indonesian accounting compliance (SAK EP) into an Odoo module was not primarily a coding problem. It was a what does this regulation actually require problem. The tooling produces confident, plausible, wrong answers in that territory — and confident-and-wrong is more expensive than slow-and-right.

Debugging unfamiliar systems

When you do not yet understand a system, generated fixes address symptoms. You end up with three patches and no understanding, which is worse than where you started.

Security-sensitive code

I hold a Cyber Security Engineer certification, and this is where I am most conservative. Generated authentication and permission code looks correct far more often than it is correct. Every line gets read.

Anything you cannot verify

This is the general rule the others are instances of: if you cannot check the output, do not delegate the task. Not “should not” — cannot. Unverifiable output is not a shortcut; it is a liability you have not discovered yet.

The workflow that actually works

After 398 deliveries, this is what I settled on:

1. Write the intent down first. Vague requests produce vague code. The clarity you need to explain a task is most of the work anyway.
2. Keep the scope small. One task, a few files. Large sweeping changes produce diffs too big to review honestly.
3. Make verification runnable. Tests, a type checker, a linter — anything that fails loudly. Without it you are reviewing on vibes.
4. Read every diff. Every single one. The moment you start skimming is the moment the quality gap opens.
5. Keep the commit history granular. Small commits stay reviewable and easy to revert.

The honest trade-off

Agentic coding shifts your bottleneck. You produce changes faster, so review becomes the constraint. Teams that do not adjust for this ship more code and more defects at the same time.

The teams I have seen do this well have one thing in common: their definition of done did not change. Same tests, same review standards, same deployment gates. What changed was how quickly they reached the point where those standards apply.

FAQ

Does this replace developers? It changes what a developer’s day contains. Less boilerplate, more architecture and review. On the work I have logged, the constraint moved from writing code to deciding what should exist — and that is still firmly a human job.

Is generated code lower quality? It is roughly as good as your review process. With solid tests and real code review, quality holds. Without them, it degrades faster than hand-written code because volume increases while scrutiny does not.

What about proprietary code and confidentiality? Read the data-handling terms of whatever tool you use, and check them against your client contracts. For work under NDA, that check happens before the first prompt, not after.

Where should a team start? Test coverage on existing code. It is low-risk, immediately verifiable, and teaches you the failure modes on work where mistakes are cheap.

---

If you are evaluating how these workflows fit your team — or want a second opinion on where the risk sits — I am happy to talk it through.