Halfway through a code walkthrough with a fintech client last quarter, their lead engineer stopped us and asked directly: "Did AI write this?"
The honest answer was yes, parts of it. And then we did something that seemed to matter more than the answer itself: we opened the commit history and showed them which parts, who reviewed each one, what the spec said before the code existed, and which tests gated the merge. The AI-assisted commits were tagged. The security-sensitive files were not among them. Every diff had a named human approver.
That conversation is the reason for this post. "Do you use AI?" is the wrong question to ask a software vendor in 2026, because everyone does. The useful questions are where, with what guardrails, and who is accountable when it's wrong. Here is how we answer them.
The prompt is the cheapest part
There is a specific illusion that AI coding demos create. You watch a model turn a one-line prompt into a working feature in thirty seconds, and it feels like software development just got 50 times faster.
What actually happened is that one stage of the process got faster. GitHub's own controlled study found developers completed a specific task, writing an HTTP server, 55% faster with Copilot. That is a real gain on a bounded, well-understood problem. But writing the first draft of code was never where projects went wrong. Projects go wrong in specification, integration, edge cases, security review, and the slow work of making something reliable enough to run unattended.
AI compresses the drafting. It does not compress the rest, and in some measures it makes the rest harder. The 2024 DORA report found that a 25% increase in AI adoption was associated with a roughly 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. A 2025 METR study put experienced open-source developers on their own codebases and found they took 19% longer with AI tools, while estimating they had been 20% faster. The gap between how fast AI feels and how fast it is turns out to be wide.
Where the effort goes, roughly:
| Stage | Traditional build | AI-assisted build |
|---|---|---|
| Spec & design | medium | medium (unchanged) |
| Writing code | large | small |
| Review & integration | medium | large |
| Test & harden | medium | large |
AI shrinks the drafting stage. It does not shrink spec, review, or hardening, and the time it saves flows straight into the stages that decide whether the software is safe to ship.
So our starting assumption is the opposite of the demo. AI gives us a faster first draft. The value of that draft depends entirely on the process wrapped around it.
Our prompt-to-product pipeline
Every feature we build with AI assistance moves through the same six stages. AI participates in some. It is deliberately kept out of others.
- Spec - human. A model cannot draft usefully without a fixed target, so we write the spec (inputs, outputs, error cases, constraints) before any prompt.
- Scaffold - AI + human. Structure and file layout generated with AI, adjusted by an engineer.
- Draft - AI. First-pass implementation inside the spec.
- Review - human, hard gate. Every AI diff has exactly the standing of a junior developer's pull request. Read line by line, checked against the spec, rejected freely.
- Verify. Tests, type checks, linters, security scanners. AI-drafted code passes the same gates as everything else.
- Integrate & ship.
Nothing skips a stage because a model wrote it.
The pipeline is not exotic. It is the normal software delivery lifecycle with one rule added: AI-generated code carries no special privileges. It does not get a lighter review because it "looks clean." It does not bypass tests because it was fast to produce. If anything, it gets read more carefully, because AI-generated code has a particular failure mode. It is fluent. It reads well, uses plausible names, and follows house style, which makes a subtle logic error or a wrong assumption easier to miss than the same mistake in awkward human code.
Where we let AI drive, and where we don't
Not every part of a system carries the same risk if it is subtly wrong. We split the codebase into a zone where AI assistance is encouraged and a zone where it is restricted to small, closely-reviewed help or excluded entirely.
Green zone - AI drafts freely:
- Boilerplate and glue code: CRUD endpoints, DTOs, config wiring, adapters
- Test scaffolding: unit test skeletons, fixtures, mock data builders
- Mechanical refactors: renames, extractions, framework version migrations
- Documentation and comments: API docs, README drafts, changelog entries
- Well-specified pure functions: parsers, formatters, transforms with clear I/O
- Exploratory prototypes: throwaway spikes, never merged as-is
Red zone - human-designed, AI limited:
- Authentication and authorization: session logic, permission checks, token handling
- Data models and migrations: schema design, indexes, irreversible migrations
- Money and billing math: pricing, proration, tax, ledger and reconciliation
- Security boundaries: input validation, sanitization, trust boundaries
- System architecture: service boundaries, data flow, failure and retry design
- Dependency selection: models suggest abandoned or hallucinated packages
The dividing line is the cost of a subtle mistake. A wrong variable name in a formatter shows up the first time you run it. A wrong assumption in an authorization check might not show up until someone reads data they should not have. AI is good at the first kind of code and dangerous at the second, so we let it draft the first and design the second ourselves. This is the same principle we apply when we build agentic AI systems for clients: the model handles the fluent, bounded work, and deterministic human-designed logic guards anything where being wrong is expensive.
The 2024 Stack Overflow Developer Survey found that while 76% of developers were using or planning to use AI tools, only 43% trusted their accuracy, and the most common complaint was that the tools handle complexity poorly. That matches our experience exactly. The green zone is where the tools earn their keep. The red zone is where trusting them costs you.
The review gate is the whole point
If you take one thing from this post, make it this: the safety of AI-assisted development lives almost entirely in the review step.
Every AI-generated change in our workflow is treated as a pull request from a fast but unreliable junior developer. A senior engineer reads the full diff, not a summary. They check it against the written spec. They look specifically for the things models get wrong: off-by-one errors in boundary conditions, missing null and error handling, plausible-looking but incorrect library calls, silent changes to behavior in code the model "helpfully" refactored along the way, and dependencies that do not exist or are no longer maintained.
We also track two numbers over the life of a project: code churn, meaning code that gets rewritten or reverted within a couple of weeks of being merged, and duplication. GitClear's analysis of millions of commits found that AI assistance correlates with rising churn and more copy-pasted blocks, both signs that code is being generated faster than it is being understood. If those metrics start climbing on one of our projects, that is a signal to slow down, not to push harder.
Commits that involved AI assistance are tagged. If a defect surfaces months later, we can trace how it entered and feed that back into the process. This is the same discipline we bring to SaaS platforms and custom web applications whether or not AI touched a given module. The tool changed; the accountability did not.
What this means if you're buying software built this way
If you are commissioning custom software in 2026, your vendor is using AI. The question is whether they are using it with a process or just using it. Four questions will tell you which:
- Which parts of our system will AI tools touch, and which are off limits? A good answer is specific and mentions a red zone. A bad answer is "we use AI to move faster" with no boundaries.
- Does AI-generated code get the same review and testing as everything else? The answer you want is that it gets the same gates or stricter ones, with a named human approving every merge.
- Where does our code and our data go when you prompt these tools? You want enterprise-configured tooling with no training retention, and sensitive data excluded from AI tools entirely.
- Who is accountable if AI-assisted code has a bug in production? The only acceptable answer is "we are," with no distinction between AI-drafted and hand-written code in the contract.
Used with a real pipeline, AI is a genuine improvement to how software gets built. It gets a working draft in front of a human sooner, which means more iterations, better test coverage, and more thorough documentation within the same budget. Used without one, it is a faster way to accumulate code nobody fully understands. The difference is not the model. It is everything around it. That distinction is also at the center of how we approach digital transformation work: the technology is the easy part, and the process around it decides whether it holds up.
Talk to us about your build
If you have a software project in planning and you want to know exactly how AI will and won't be used on it, ask us for a written breakdown before any work starts. We will walk your technical team through the toolchain, the red zone for your specific system, the review process, and the data handling terms.
