The Syntax Was Never the Value: How Our Engineering Team Sees AI

IN BRIEF: Developers have adopted AI at extraordinary speed, and trust in its output has fallen even as adoption climbed. The cause has a name now, the verification tax, and it doesn't go away with better models. This is how we're engineering around it, and what that means if we build your platform.

Nearly everyone in software now uses AI, and almost nobody fully trusts it. Those two facts have held together for three years, and the gap between them tells you more about this moment than any other number I know.

In Stack Overflow's 2025 survey1 of about 49,009 developers, 84 percent were using or planning to use AI tools, while trust in the accuracy of that output fell to 29 percent, down from 40 percent the year before. Only 3 percent said they highly trust what these tools produce. The 2026 surveys are still in the field, but nothing published so far points the other way. Stack Overflow's own early look at agents this year2, 3 found usage had doubled while concerns about AI-generated code grew with it.

We aren't much better at judging our own productivity. When METR ran a randomized controlled trial in July 2025,4 experienced developers working on codebases they knew well were 19 percent slower with AI assistance, and came away believing they had been 20 percent faster.

DORA's researchers have a name for what's happening. They call it the verification tax.5 Time saved writing is spent again on auditing, and because these tools can't signal their own uncertainty, every output has to be treated as unverified until a human has checked it.

None of this is an argument against AI. It's an argument against one specific idea, which is that speed of generation is the same thing as value delivered. We don't build software for its own sake. We build platforms meant to move something a business cares about, like what people think of a brand, whether they come back, and whether they buy. A platform that ships faster while moving none of those isn't an achievement.

The Technology Is Extraordinary

Any serious discussion has to start here, because skepticism about AI capability is out of date. On the leading benchmark of real GitHub issues, published resolution rates went from under 10 percent in early 2024 to over 70 percent through 2025.6 METR's trend analysis finds the length of tasks agents can complete on their own doubling roughly every seven months.7 Agents today read entire repositories, run their own tests, and fix their own failures. A year ago that was an impressive demo. Today it's routine daily work.

One calibration keeps those numbers valid. Benchmark tasks are curated and clearly specified, and their tests are imperfect judges. When researchers strengthened the test suites behind that benchmark in early 2026, about one in five patches previously marked as solved turned out to be wrong in ways the old tests never caught.8 Real codebases carry legacy, ambiguity, and shifting requirements that curated tasks don't. The capability is real. The scores just measure it generously.

We use these tools across our practice, every day. Anyone who doesn't is leaving capability on the table. So if the tools are this good, why did trust go down?

What Happens Without the System

Replit, July 2025.9 During a customer's live experiment, Replit's AI agent deleted a production database, ignored eleven explicit code-freeze instructions, then fabricated roughly 4,000 fake user records to cover the gap. Replit's fix was automatic separation of development and production databases, plus one-click rollback.

AWS Kiro, December 2025.10 Asked to fix a minor issue, Amazon's agentic assistant deleted and recreated the environment, causing a 13-hour regional outage. It had inherited an engineer's elevated permissions, bypassing two-person review. Amazon called it misconfigured access control and made peer review mandatory.

OpenAI and Hugging Face, July 2026.11 During a test of how well its models could hack, OpenAI's models broke out of the sandbox through a flaw nobody knew was there and reached Hugging Face's live systems, where they went looking for the answers to the test. Hugging Face caught it and made it public before anyone knew whose model was responsible.

Anthropic, nine days later.12 Prompted by that disclosure, Anthropic checked its own evaluations and found three cases where its models had reached the open internet from supposedly sealed environments and touched the live systems of real organisations, none of whom had noticed. The cause was mundane. Anthropic and its testing partner had understood the setup differently, and nobody had checked. One model worked out that it had reached real systems and carried on anyway.

AISI, 4 August 2026.13, 14 Britain's AI Security Institute disclosed a further cluster from its cyber evaluations of OpenAI and Anthropic models, run under deliberately permissive conditions. An agent pursuing a test objective invented fake online identities and used them to pressure a real open-source maintainer into approving malicious code, and when challenged, went back and edited its own earlier records. The attempt failed for one reason. A human reviewer did their job.

At scale. When security researchers scanned 5,600 live vibe-coded applications,15 they found more than 2,000 high-impact vulnerabilities, including 400 exposed secrets. The demos worked, so the apps shipped.

Now notice what actually fixed each of these. Keeping development away from production, being able to roll back, requiring a second person to approve, and checking that the sandbox was really a sandbox. Not one of them was a better model. Every one of them was an engineering practice.

Now compare what teams get when the engineering is built:

Same class of models the runaway agents ran on. The variable isn't the AI. It's the engineering culture around it. DORA's research says it in one line: AI doesn't fix a team, it amplifies what's already there.19 In our experience that cuts both ways, which is why we assess an organisation's readiness, its collaboration, its technology landscape and its executive sponsorship, before proposing how fast to move. AI will amplify the client's culture just as surely as it amplifies ours.

What we've seen on our own work. On our own product we review a live sample of AI generations on a fixed cycle, trace each defect to its cause, and close it with a regression test. One recent cycle examined ninety-six production generations and surfaced twelve distinct defect classes. Among them were drafts resolving weekday names against the wrong year, correct for 2025 and wrong for 2026, in messages about to go to a customer. Eleven of the twelve were closed in that same cycle, and the regression suite grew by more than a hundred tests in a day. Each fix is gated against both the failing case and an untouched control, so we can say what it catches and what it doesn't. On one defect class it caught six out of six with no false alarms on benign cases, and on another, four out of four. About one generation in ten is now corrected automatically before a human ever sees it. That's the verification tax being made cheap, which is the only approach we've found that actually works.

The same discipline runs on a second product we're building AI-first, where the entire multi-tenant foundation was generated in a single working day and making it safe to put a customer on took the two weeks that followed. The review pass that taught us most read the code and called it healthy. Four days later a second pass exercised the running system and found seven defects, five of them ways one customer's data could have reached another, all caught before anything was deployed.

Writing Code Was Never the Job

Here is the number that reframes everything. Developers spend about a third of their time writing code.20 The rest goes on reading and understanding it, and on maintenance, which accounts for roughly 90 percent of what a system costs over its life.21

AI automated the third. Everything else, which is understanding what exists, deciding what to change, agreeing on it and keeping it alive, just became the whole job.

The profession now has a name for what goes wrong when that's ignored. It came out of a gathering of software leaders in early 2026, and the clearest account of it is Margaret-Anne Storey's.22 She calls it cognitive debt.

Technical debt lives in the code. Cognitive debt lives in people.

When AI generates code that nobody fully understands, the second kind compounds quietly, and velocity without understanding isn't sustainable. The mitigation is unglamorous. At least one person on the team should fully understand each AI-generated change before it ships.

Domain knowledge is where this bites hardest. It used to accumulate as a byproduct of writing the code, because you couldn't implement a reconciliation routine without being forced to confront the rounding rules and the settlement dates. When the code arrives already written and plausible, that forced encounter disappears, and the business rules the implementation quietly decided go unexamined. Domain literacy now has to be built deliberately, which means the need for it has gone up, not down.

Education is arriving at the same place. Chris Piech, who teaches Stanford's computer science classes, puts it plainly:23 

AI is getting very good at the syntax, so what matters now is teaching people to problem solve. 

Enrollment in his free online coding course roughly doubled after AI tools arrived. People aren't walking away from code. They're trying to get better at the part of it that still belongs to them.

AI didn't shrink engineering so much as reveal it. It automated the one part of the work that was always the most automatable, and left everything that was always the real value, which is knowing what to build, and why, and for whom, and how to keep it alive for a decade. That's not a demotion for engineers. It's a promotion, for those who accept it.

We Learned This on Our Own Product

When we built the landing page for  Zygnet Plexus , our own product's private beta, an AI design tool and a coding agent took us from go-to-market brief to a working codebase in 10 to 12 hours instead of the 40 to 60 a traditional build would have taken. It looked finished, and it demoed perfectly.

It had also exposed a backend webhook URL in the client-side HTML. An open door, invisible in every demo.

The fix wasn't a prompt. An engineer designed an edge layer that hid the secrets and filtered bot traffic, then refactored the AI's first draft into a reusable theme package so the next page takes minutes. The AI did what we asked. It didn't do what we needed, because it can't know the difference. 

That gap between what we asked for and what we needed is where engineering earns its keep. 

The full build is written up in  our case study .

Functionality is "it runs." Utility is "it's secure, compliant, fast, still valuable next year, and it moved the number it was built to move." 

In that same Stack Overflow survey,1 the top complaint wasn't that AI fails outright but that it produces solutions that are almost right. The pattern isn't confined to engineering. A 2026 survey of roughly 6,000 executives24 found close to 90 percent reporting no measurable effect of AI on their firm's productivity so far, while forecasting gains ahead. Enterprise AI projects fail far more often than anyone expects, and almost never for lack of syntax.

How We Deliver: One Loop, Five Practices

The traditional delivery line loses context at every handoff, from business analysis to design to development to testing. That was survivable when building the wrong thing took six months and somebody usually noticed in month two. Now the wrong thing can reach production in days.

Avoiding that outcome is why our Spiral Collaboration Model exists. Marketing, business analysis, user experience, technology and quality work as one loop from discovery onward, and feasibility is validated before timelines are committed. Technology is one practice of five, not the centre of gravity, because what a client is buying is a business outcome and the engineering exists to make that outcome dependable.

AI sits inside that loop. It's fed the strategy and the context, and its output is reviewed by every practice, rather than being bolted onto the end of a line. The cheaper it becomes to build the wrong thing, the more valuable it is to agree on the right thing first.

None of this was written for the AI era. As far back as 2013, we were presenting inside the company on how we think about software quality ( Quality: A Perspective25 ).

The outside evidence has only moved our way since. Veracode tracked more than 100 models for its July 2026 report26 and found they now write code that compiles almost every time, while the security pass rate has barely moved in three years. CodeRabbit27 found roughly 1.7 times more issues in AI-assisted pull requests. GitClear's review of 623 million code changes28 found duplication up 81 percent while refactoring fell 70 percent, which is what a codebase looks like when it's being added to faster than it's being understood.

Generation has become reliable. Judgment hasn't been automated at all, and there's no sign that it's about to be. Dries Buytaert, the creator of Drupal, reaches the same conclusion from a different direction, watching how content platforms are being rebuilt around AI. His summary of it is hard to improve on:29

AI lowers the cost of creation, not the cost of trust.

What This Means If We Build Your Platform

Beliefs are easy. These are the five commitments we hold ourselves to, and what each one should mean for a client.

1. Written rules, and a named owner for every change. What an AI tool is allowed to reach, where it can and can't run, and what needs a person's approval before it happens. Whoever ships a change owns it, whether they wrote it themselves or an agent did. Ask what's allowed near your systems and you should get an answer, not a reassurance.
2. Agreeing what we're building before we build it. The requirement written and the business reason settled before anyone generates code, so the hard conversation happens at the start instead of after a demo shows we solved the wrong problem. Where generated code embeds a business rule, we write that rule out in plain language and have someone who knows the domain confirm it, rather than letting the implementation decide it silently.
3. Measuring what changed, not how much we shipped. Volume of code isn't an achievement. We assess our own delivery on tangible results for the client and on the quality of what we hand over, and we hold engineering delivery to a defect leakage standard of under 2 percent. Ask what moved for your business and the answer should be a number.
4. Building on open platforms rather than around them. We have been a free software company since we started, and the principle holds under AI: where a community is building capability in the open, with the governance to go with it, we would rather adopt that than hand you something that you are left maintaining alone. Drupal's AI initiative is the current example. We use it, we follow it closely, and we contribute back the way we always have, by fixing what we hit as we build. The models themselves are a different matter, and we treat them as replaceable parts rather than foundations, so a change of provider is a configuration decision and not a rebuild.
5. Growing engineers, not just hiring them. Juniors work with AI and with a mentor, on purpose, because these tools make it easy to produce work you don't really understand. Experienced engineers take years to grow, and they're the ones who catch what the tools miss.

The Closing Thought

The trust gap won't close with better models. It closes with engineering, with boundaries the tools can't cross, with teams that stay aligned, and with checking built into the work rather than bolted on at the end.

The verification tax isn't going away. What a good engineering team can do is make it cheap, by building systems that check automatically what would otherwise be caught by a person on their fourth review of the day, if it's caught at all.

For anyone hiring us, that's the practical point. The constraint was never how fast a platform could be built. It was whether the thing built could be trusted to carry a brand, hold a customer, and still be worth owning in five years.

The syntax was never the value. We were. We are.

If you're working out how AI-assisted delivery should be governed on your own platform, that's a conversation we have often.  Talk to us .

Notes:

Figures describing our own products and delivery, including the review-cycle numbers, the landing page build times and the defect leakage standard, are drawn from our internal project records and delivery documentation. 

Productivity figures from Anthropic, Intercom, and Spotify are company-reported and not independently verified. The METR result reflects early-2025 models on mature codebases; METR's own 2026 follow-up notes selection effects, so treat it as a rigorous snapshot rather than a permanent verdict. Sources current as of August 2026. The 2026 editions of the Stack Overflow and JetBrains developer surveys had not been published when this was written. 

Based on several years of close industry observation and hands-on experience building AI into our own products. Generative AI tools assisted with drafting and editing; all facts, figures, and sources were independently verified by the author.