All articles

AI-Led or AI-Assisted: two ways we build software, and how to choose

•
12
NERDZ LAB
4 followers

We picked between two delivery models on every project this year: one senior engineer directing AI through the build, or a full team using AI to move faster while a second developer reviews everything. They are not two price points for the same thing — they produce different outcomes, and choosing wrong is expensive in both directions.

By Vasyl Khmil, CTO at NERDZ LAB

In April we published how we use AI across our development workflow — the tools, the hooks, the shared skills library, the practices we standardised on. The most common response was a question we didn’t answer: fine, but who is actually doing the work?

It’s the right question. “We use AI” stopped being a differentiator some time in 2025. Almost every development team now has an AI assistant open. What separates one engagement from another is no longer whether AI is involved. It’s who directs it, who reviews what it produces, and who signs off before anything reaches a user.

We run two answers to that question, and we pick one deliberately at the start of every project.

AI-led means one senior engineer directs AI through the build, then hands the result to a human QA for final sign-off. AI-assisted means a full team of specialists builds the product, using AI to move faster on specific tasks, with a second developer reviewing every contribution.

These are not two price points for the same thing. They produce different outcomes, and choosing wrong is expensive in both directions.

Model 1: AI-led

One senior engineer. AI does most of the typing. A human QA signs off before delivery.

The engineer on an AI-led project is not a junior with a chatbot. The role demands three things at once: enough breadth to cover front-end, back-end, infrastructure and data without a handoff; enough delivery-management experience to decompose a product into tasks an AI can execute correctly; and the instinct to recognise output that is fluent, confident and wrong. That third one is the hard part, and it’s why this model is staffed with our most experienced people rather than our cheapest.

The single-person structure isn’t a compromise we accept to hit a price. It’s the mechanism. On a four-person team, a meaningful share of the calendar goes to things that aren’t building: standups, planning, handoffs, merge conflicts, clarifying who owns which boundary, re-explaining a decision made in a meeting someone missed. Remove the second, third and fourth person and that entire category of cost disappears. On a two-week build, that’s not a rounding error.

What makes one engineer sufficient is that they aren’t starting from zero. We maintain a library of internal skills covering each technology and module we work in, built from our own production code, our own style guides and our own templates. When the AI writes an API layer, it writes it the way we write API layers. The engineer is directing accumulated team knowledge, not improvising.

AI runs the tests. A human QA still performs final sign-off. We don’t delegate that step, in either model, for any client. Automated tests confirm the code does what someone said it should do. They don’t catch a requirement that was misunderstood before a line was written.

AI-led is right for: proving an idea works, internal tools, single-purpose utilities, anything where the goal is learning something quickly rather than operating something for years.

Model 2: AI-assisted

A full team, one specialist per discipline. Humans design and build. AI accelerates specific tasks. Every developer has a second developer reviewing their work.

Here the ownership sits with people. A back-end engineer owns the back end. A designer owns the interface. AI compresses the parts that benefit from compression — test scaffolding, boilerplate, documentation, repetitive migrations — and the same internal skills library keeps output consistent with the rest of the codebase. The architecture, the trade-offs and the decisions about what the product should do remain human work, because those are the parts that are expensive to get wrong and cheap to get right if someone senior is paying attention.

The paired reviewer is the part worth dwelling on, because it addresses something the 2026 data has made hard to ignore.

Faros AI’s AI Engineering Report 2026, drawing on telemetry from roughly 22,000 developers across more than 4,000 teams, found median pull request review time up 441 percent, pull requests 51 percent larger, and 31 percent more PRs merging with no review at all. An analysis published in January 2026 of AI-generated build code found that more than 61 percent of agentic pull requests were approved and merged with minimal human intervention. GitClear’s June 2026 study of 623 million code changes found duplicated code blocks up 81 percent and refactoring activity down 70 percent since 2023.

The pattern is consistent: AI raises how much code arrives, and review capacity doesn’t rise with it. Google’s DORA team has a name for the gap — the verification tax. Teams that don’t budget for it ship faster and break more.

Assigning a second developer as reviewer is how we pay that tax on purpose rather than discovering the bill later. It costs real hours. That’s the point.

AI-assisted is right for: products with real users, anything carrying a compliance surface, systems that another team will maintain in three years, anything where a defect costs more than the review that would have caught it.

Side by side

AI-ledAI-assistedTeamOne senior engineer + AIOne specialist per discipline + paired reviewerOptimised forTime and costQuality and controlWho designs the architectureThe engineer, with AI executingThe team, with AI acceleratingCode reviewAI first pass, engineer reviewsAI first pass, then a dedicated human reviewerQA sign-offHumanHumanCoordination overheadNear zeroReal, and deliberately paid forWhat you give upReview depth, redundancy, long-term maintainabilitySpeed and priceBest forProof of idea, internal toolsProduction systems with users and consequencesTypical

engagement

AI PoC — $8,000–$15,000, 2–4 weeksAI MVP — $40,000–$120,000, 8–16 weeks

What AI-led does not give you

An AI-led build produces working, inspectable software quickly. It does not produce a system ready to carry a user base, and we’d rather say so in an article than discover the disagreement in week six.

A recent internal AI-led build — a retrieval system over a large corpus of regulatory documents — shipped in weeks with a full passing test suite and a working interface. It also shipped with a documented list of what it deliberately didn’t have: no per-user access control, no audit trail, a front-end API key that a determined user could extract, and prompt-injection handling that was mitigation rather than a hard boundary. All of that was correct for its purpose. It was built to prove that the retrieval quality was good enough to justify a real product. It answered that question, and none of those gaps mattered for answering it.

Every one of them would matter the moment a real customer logged in.

That’s the honest shape of the trade. AI-led buys you an answer fast. Turning the answer into a product is the second project, and it’s an AI-assisted one.

How to choose

Four questions. Any yes points toward AI-assisted.

  1. Will real users, outside your company, depend on this?
  2. Does it touch regulated data, payments, or anything with a compliance obligation?
  3. Will someone other than the original builder maintain it a year from now?
  4. Is the goal to operate this long-term, rather than to learn something and move on?

Four nos, and AI-led will get you there faster and for less. Most companies we talk to need one of each, in sequence. Starting with the expensive one before you know whether the idea works is a common and avoidable mistake.

The two objections we always get

“If AI wrote it, why am I paying human rates?”

Fair question, and one being asked across the industry: a March 2026 survey of agencies found roughly a quarter had been asked to cut rates on the grounds that AI was doing the work. Our answer is that you’re not paying for typing. You’re paying for the decisions about what to build, the judgment to reject output that looks right and isn’t, the review that catches what the tests don’t, and accountability for the result. AI made the typing faster, and we’ve passed that on — an AI PoC costs a fraction of what the equivalent build cost two years ago. It didn’t make the judgment cheaper, because the judgment got more valuable, not less.

“One person on my project — what happens if they leave?”

Legitimate, and specific to AI-led. Three things reduce it: the code follows our internal standards rather than one individual’s habits, so any of our engineers can pick it up; documentation is generated as part of the build, not after it; and the code is yours from day one, with full IP assignment. It doesn’t reduce the risk to zero. If that risk is unacceptable to you, that itself is a signal you want AI-assisted.

Questions worth asking any development partner in 2026

  • Who reviews AI-generated code before it merges, and is that person different from the one who prompted it?
  • Who performs final QA sign-off, and are they a human?
  • What proportion of pull requests merge without human review?
  • Which parts of my system will AI write, and which won’t it touch?
  • Who owns the code and the IP?

Ask us the same ones. If a partner can’t answer all five specifically, the answer is probably “we haven’t decided,” which is the real risk.

Not sure which model your project needs?

That’s the conversation to have before the build starts, not after. Book a 30-minute scoping call and we’ll tell you which one we’d recommend — including when it’s the cheaper one.

See how this plays out in practice in our case studies, or read more about our AI development services.