AI-Augmented Development: Doing More Without Growing Headcount

Last updated: August 22, 2026

By Colin Boothe, CIO at Foretopia

AI-augmented development means your existing engineers ship more work by handing AI the well-specified parts of the job and reviewing every line that comes back. It raises output without raising headcount. It does not remove the reviewing, and reviewing is where most teams quietly lose the gain they thought they bought.

A controller at a distributor asked me in March how many developers she should budget for. Her team had two. The backlog had forty-one open items, and eleven of them were the same request typed four different ways by four different people who had never met.

She did not have a developer problem. She had a specification problem wearing a developer costume. Big difference.

I bring that up because almost every conversation about AI and engineering headcount starts in the wrong place. The question gets framed as how many people can we stop hiring. Wrong question. The question that actually pays is which parts of this work were ever hard, and which parts were just tedious and badly written down.

Fair warning on who is talking. I run an ERP and business systems consulting group, and my team writes NetSuite code for a living, so I have skin in this. Finish this and want a hand with it? My calendar is open, which is exactly the bias you should be discounting for. The offset is that most of what follows is a set of rules you can copy for free, and I will tell you the two places where AI made us slower before it made us faster. You are also reading this on a staffing firm’s site, and their IT staffing services team places the engineers who end up doing this work. That matters at the end, when I argue the headcount question has a real answer and it is not zero. If you want the wider version of this argument across the whole business, not just the dev team, that lives in practical AI for business operations.

What AI-Augmented Development Actually Means

AI-augmented development is the use of code generation and analysis models inside a normal software delivery process, where a named human engineer owns the output, reviews it before merge, and remains accountable for it. The scope is a task inside a sprint. It is not autonomous development, and it is not a headcount replacement plan.

Two words in there do the heavy lifting. Named. Reviewed.

Strip either one out and you do not have augmented development. You have a very fast intern with commit access and no manager, which is a thing I have now watched three companies build on purpose.

The distinction matters because the market has spent two years selling the other version. Autonomous agents. Self-healing pipelines. A demo where somebody types a sentence and a working app falls out. Those demos are real, in the sense that they happened. They are also run against a greenfield repo with no legacy schema, no compliance surface, and no eight-year-old integration that three people are afraid to touch.

Your repo is not that repo. Mine is not either. Nobody’s is.

The Study Nobody Wants Framed on the Wall

In July 2025, the research group METR ran the experiment everybody had been avoiding. A proper randomized controlled trial, on 16 experienced open-source developers working through 246 real tasks in repositories averaging more than 22,000 stars and a million lines of code. These were not tourists. They had years of history in the codebases they were working in.

With AI tools allowed, they were 19 percent slower. Slower. Read it again.

Before the study, those same developers predicted AI would speed them up by 24 percent. After the study, having personally lived through the slowdown, they still believed it had sped them up by about 20 percent. Read that twice. The measurement said one thing and the feeling said the opposite thing, and the feeling did not budge.

That gap is the single most useful finding in this entire field, and it is useful for an unglamorous reason. It means self-reported productivity gains from your own engineers are not evidence. They are a feeling with a percentage stapled to it. The 2025 DORA report from Google Cloud, built on roughly 5,000 technology professionals, found more than 80 percent believe AI increased their productivity. Both of those findings can sit in the same room without either one being a lie about what actually happened on anybody’s calendar. Belief is not measurement. Never has been.

Now the part everyone skips. METR was explicit that their result does not rule out speedup with better scaffolding, better prompting, or domain-specific training on the codebase in question. They tested general-purpose tools pointed at a general-purpose problem, and they said so in the caveats.

Which is the gap we went after. Deliberately.

Nine Years of Codebase Is the Whole Trick

Our technical team has not grown in headcount. Demand for development work has, a lot. Delivery time per task has come down, and defect rates have not gone up, and that second clause is the only reason the first clause is worth saying out loud to anybody who has to sign the invoice at the end of it.

The thing that made the difference was not the model. Everybody has the same models. It was nine years of our own NetSuite code, plus the unglamorous discipline of getting that history indexed, tagged against the specifications it came from, and put in front of the tooling in a shape it could actually consume at the moment somebody was writing.

Here is the honest mechanical version, because the phrase “we fine-tuned a model on our codebase” gets thrown around by people selling six-figure projects. Most of the value is retrieval, not training. Your repository, your specifications, your review comments, and your incident history, indexed and surfaced to the model at the moment it writes. A light behavioral layer on top for house style and output shape. Training a model on code that changes every sprint bakes in decisions that will be wrong by the next release. If someone quotes you a one-time fine-tuning engagement for a living codebase, ask what happens in month four.

Why does any of this matter more in a platform like NetSuite than in a generic web app? Because platform-specific correctness is where general models are confidently, cheerfully wrong.

A stock model will write you SuiteScript that runs beautifully against a sandbox with 400 records and falls over on governance limits the first time it meets a real transaction volume. It will reach for a deprecated interface because four years of blog posts on the open internet still recommend it. It does not know that the NetSuite MCP connector changed what you should be doing by hand at all.

The specific failure I use to explain this to executives is arithmetic, not opinion. We scoped an integration earlier this year where the obvious design, syncing at the unit level, would have burned roughly 1,350,000 API calls a year against a licensed allowance of 130,000. Over by a factor of ten. Not close. Batching at the transaction level, around 141 documents a month at four to six calls each, uses under a quarter of the allowance. No model caught that. A person with nine years of scar tissue caught that in about a minute, because the constraint lives in a licensing document, not in the code.

Same category of thing, different flavor. A NetSuite RESTlet will not accept a plain API key. External callers need OAuth 1.0 token-based auth or signed OAuth 2.0, so a vendor who only speaks API keys needs an authenticated relay sitting in front of it. Nobody tells you that. It is not in the tutorial. Not anywhere. You find out during integration testing, three weeks after somebody promised a date.

The Quality Bill Comes Due in Someone Else’s Sprint

Faster typing is not the same as faster shipping, and the independent data on what has happened to code quality since 2022 is not subtle.

The GitClear research covers 623 million analyzed changes from 2023 through 2026, which makes it one of the largest independent looks at this anybody has published. Their 2026 maintainability report found duplicated blocks at the highest level ever recorded, up 81 percent against 2023, while refactoring collapsed from 21 percent of changes to under 4 percent. Copy and paste beat cleanup for the first time on record.

Translated out of research language. Teams are producing more code and cleaning up less of it, and the difference between those two rates is accumulating in a pile that somebody who does not work there yet will inherit at some point in the next two fiscal years.

Meanwhile the Stack Overflow 2025 Developer Survey has 84 percent of developers using or planning to use AI tools, while positive sentiment toward those tools fell from over 70 percent in 2023 and 2024 to 60 percent. Usage up. Affection down. About 45 percent list debugging AI-generated code as more time-consuming, their second-biggest complaint, and 66 percent name the almost-right answer as their first, which is the most precise description of the failure mode anybody has published.

Almost right is worse than wrong. Much worse. Wrong gets caught. Almost right gets merged.

DORA’s framing is the one I steal most often. AI is an amplifier. It does not fix a team, it makes the team more of whatever it already was. If your test coverage is thin and your review process is a formality, AI hands you the same dysfunction faster and in more of it. That is not a tooling problem you can buy your way out of, and I say that as somebody who sells tooling work.

We Wrote Our Rules Down, So Here They Are

We do regulated work. Some of our deliverables sit inside validated systems for a mid-market pharma manufacturer, where code provenance is a question an auditor is allowed to ask and “the AI wrote it” is not an acceptable answer. So we wrote a policy. It is a real controlled document in our quality system, not a slide.

I have never seen a competitor publish theirs. Not one. Here is ours, in plain language.

You are probably not building validated pharma systems. Copy the rules anyway. All six. Every one of them survives translation into an ordinary commercial shop, and the second and fourth are the ones that separate a team getting a real return from a team generating expensive noise.

Rule two is the one that gets argued with the most, so let me be blunt about it. Writing the specification is the work. It always was. AI did not eliminate that job, it exposed how many teams were skipping it and calling the resulting confusion agility. If you want a related version of this argument aimed at the review side specifically, there is a good piece on AI code review for engineering teams that gets into who owns the merge button.

So What Actually Happens to Headcount

Here is the part I get asked in every board meeting, and here is the answer that has held up.

You do not cut. You stop adding at the same slope. That is the whole trick.

That is a less exciting sentence than the one on the vendor’s homepage, and it is worth a great deal more money. Say your team is six people and demand doubles over two years. If it is still six people at the end, you never paid for four salaries, four recruiting cycles, four onboarding ramps, four sets of benefits, or the standing coordination tax that four more humans add to every meeting. Our own team is the case study. Flat headcount, materially more delivered, same defect profile.

What does not shrink is review capacity. It grows. Every time. If your engineers are producing more code, someone senior is reading more code, and that person is now the constraint. Most teams I work with hit that wall inside a couple of quarters, usually in the form of one very tired principal engineer.

So the hiring mix changes rather than the hiring stopping. You need fewer people who can write a CRUD endpoint. You need more people who can look at a working diff and say this is fine but it will not survive the January volume, which is judgment, and judgment is still expensive. The Bureau of Labor Statistics still projects 15 percent growth for software developers, quality assurance analysts, and testers from 2024 to 2034, with about 129,200 openings a year. That is not a profession being deleted. The middle of that profession is thinning out and both ends are getting more expensive, which is a deeply annoying sentence to read if you happen to be standing in the middle of it and quite like it there.

Two practical notes on the staffing side, since I am a guest here and KORE1 knows this better than I do. First, senior review capacity is a terrible thing to hire slowly for, and their software engineer staffing practice closes a typical search in about 17 days, with 92 percent of placements still in seat a year later. Second, the review bottleneck is often seasonal rather than permanent, which makes it a good fit for contract staffing instead of a headcount request you will regret in Q3.

One more number, because it is the one that changes budgets. On regulated work, validation runs about 30 percent of base hours, and our blended delivery rate is $215 an hour across roles. AI compresses the build. It does not compress validation, and it does not compress review. Any proposal that shows both lines shrinking proportionally is cheaper by exclusion, not by efficiency, and you will meet the excluded parts later.

Sixty Days, and You Will Know

This does not need a steering committee. It needs one team, one repo, and a willingness to measure something other than how everybody feels.

Weeks one and two, baseline. Pull your last two months of merged pull requests and record cycle time, review time, change failure rate, and rework. If you cannot produce those four numbers, that is your actual finding and you should stop here and fix it, because without a baseline every result from here forward is an opinion.

Weeks three through six, one team, real work, and the two rules that matter. Generation happens against a written specification. Review before merge happens with a named reviewer. Point it at the work with a right answer, not at the work with a judgment call. Migration mapping is the obvious candidate, which is why I treat ERP data migration scripts as code and put them through the same review. AI is a high speed idiot, brilliant and fast and completely without instinct, which makes it superb at the well-defined and dangerous at the ambiguous.

Weeks seven and eight, compare. Same four numbers. No new ones. Then a fifth one that most teams forget, which is how much of the generated code got rewritten within thirty days. That number is where the truth lives. Ask for it first.

If throughput went up and change failure went up with it, you did not get a productivity gain. You got a volume increase with the invoice deferred. Fix the review capacity first and run it again.

Do not do all of this at once across four teams. That is a program, and programs get status reports instead of results.

What Engineering Leaders Ask Me After They Have Already Bought the Tools

Do we actually need to fine-tune anything, or is that a vendor upsell?

Mostly an upsell. Sometimes entirely. Most of the gain comes from retrieval over your own repository, specifications, and review history, with a light behavioral layer for house style. Full fine-tuning on a codebase that changes every sprint bakes in decisions that go stale fast. Ask any vendor quoting a one-time training engagement what happens in month four, and watch what the answer does to the price.

My team says they are twice as fast. Are they?

Almost certainly not. They also are not lying to you. METR’s controlled trial found experienced developers were 19 percent slower with AI, and they still believed they were 20 percent faster after living through it. Self-reported speed is the least reliable metric in this whole category. Go look at merged pull request cycle time and thirty-day rework instead. It takes an afternoon. Maybe two.

Who signs off on code the AI wrote?

A named person, same as always. Every time, no exceptions. In our quality system, AI output is draft material and a qualified human is author of record, accountable for the content and required to be able to explain any part of it without reference to the tool. Review before merge is done by someone other than that author. If nobody’s name is on it, you do not have a process, you have a habit.

We are in a regulated environment. Is any of this allowed?

Yes, with controls, and the controls are not exotic. Generation against an approved specification rather than a prose prompt, documented independent review, human-authored test protocols, and disclosed tooling. That combination preserves traceability from requirement through code to test, which is the thing validation actually cares about. If your client’s quality system restricts AI-assisted work, that restriction wins, and you record it at engagement start rather than discovering it during an audit.

Does this mean we stop hiring engineers?

Nope, and the framing is off. It means you stop adding at the same rate, and the mix shifts toward people who can review rather than people who can type. Review becomes the bottleneck inside a couple of quarters in nearly every team I have watched try this, and senior judgment does not get cheaper because generation got faster. BLS still projects 129,200 annual openings in the field through 2034.

What is the first thing to point it at?

Whatever your team complains about in standup that has a right answer. Test scaffolding. Data transformation scripts. Documentation for code that already works and nobody has opened in a year. Migration mapping between two schemas a human already reconciled on paper, where the right answer is knowable by looking it up rather than by arguing about it in a meeting. High volume, checkable by someone who is not the author, cheap to catch when wrong. That last criterion is the one people skip, and it is the one that decides whether this goes well.

One Sprint Is Enough to Know

You do not need a strategy for this. You need one repository, one honest baseline, and eight weeks of not lying to yourself about what changed.

The companies getting real value out of AI-augmented development are not the ones with the best models. Everybody has the same models. Same weights. Same benchmarks. They are the ones who already wrote things down, already reviewed each other’s work, and already knew what their cycle time was on a Tuesday. Let’s graduate the tech stack from the 90’s to at least the 2000’s, and then let the fast tool loose on the part that was always just typing.

The rest of it, the specification, the review, the judgment about what should have been built at all, that stays yours. It was always the expensive part. It just used to be hidden inside a queue of tickets nobody had time to read.

Building or scaling the team that has to absorb all this? KORE1 places the engineers, and you can talk to a recruiter about what the review layer should actually look like. If you want to argue with me about the fine-tuning part, or you have a NetSuite environment doing something expensive and stupid, hit me up on LinkedIn.