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

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 survey of about 49,000 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 year 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, 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. 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. METR's trend analysis finds the length of tasks agents can complete on their own doubling roughly every seven months. 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. 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. 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. 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. 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. 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. 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, 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. 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. 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.

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. 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: 

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, 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 executives 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 Perspective ). The argument then was that quality means balancing the interests of everyone the software touches over its whole lifetime, that the non-negotiables must be defined before work starts, and that good code is code the next person can pick up. Replace "the next person" with "an AI agent", and a talk from 2013 turns out to describe 2026.

The outside evidence has only moved our way since. Veracode tracked more than 100 models for its July 2026 report and found they now write code that compiles almost every time, while the security pass rate has barely moved in three years. CodeRabbit found roughly 1.7 times more issues in AI-assisted pull requests. GitClear's review of 623 million code changes 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:

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  Drupal's AI work rather than around it. The community is building this capability in the open, with the governance to go with it. We'd rather use that and contribute fixes where we find gaps than hand you something private that you're left maintaining alone.
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 .

References

1. Tidelift & The New Stack. (2019). Developer time-allocation survey (nearly 400 professional developers: 32 percent of time on writing new code or improving existing code). [View on thenewstack.io]
2. Stack Overflow. (2025). Stack Overflow Developer Survey 2025 (49,009 respondents: adoption, trust and the "almost right" frustration figures). [View on stackoverflow.co]
3. Stack Overflow. (2026, February 18). Mind the gap: closing the AI trust gap for developers. [View on stackoverflow.blog]
4. Becker, J., Rush, N., Barnes, E., & Rein, D. (METR). (2025, July). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv preprint 2507.09089. A randomized controlled trial with 16 experienced developers across 246 real tasks on mature repositories. [View on arXiv]
5. METR. (2025, March 19). Measuring AI Ability to Complete Long Software Tasks (the roughly seven-month doubling). [View on metr.org]
6. OpenAI. (2024, August). Introducing SWE-bench Verified (the 500-sample human-verified subset used for the resolution-rate figures). [View on openai.com]
7. SWE-ABS. (2026, March). Adversarial Benchmark Strengthening [Preprint] (the strengthened-tests finding). [View PDF on arXiv]
8. DORA. (2025). State of AI-assisted Software Development, 2025 (the amplifier finding). [View on dora.dev]
9. DORA. (2026). Balancing AI tensions: moving from AI adoption to effective SDLC use (the verification tax). [View on dora.dev]
10. Tom's Hardware. (2025, July). Public reporting on the Replit agent incident. [View on tomshardware.com]
11. Engadget / Financial Times. (2026, February). Reporting on the AWS Kiro outage. [View on engadget.com]
12. OpenAI. (2026, July). OpenAI and Hugging Face partner to address security incident during model evaluation. [View on openai.com]
13. Anthropic. (2026, July 30). Investigating three real-world incidents in our cybersecurity evaluations. [View on anthropic.com]
14. UK AI Security Institute. (2026, August 4). Incident Report: unsanctioned agent behaviour during cyber testing. [View on aisi.gov.uk]
15. CNN. (2026, August 4). Report on the AISI disclosure. [View on cnn.com]
16. Stack Overflow. (2026, June). The 2026 Developer Survey is now open (the agents-survey finding). [View on stackoverflow.blog]
17. Escape. (n.d.). The State of Security of Vibe Coded Apps (the 5,600-application scan). [View on escape.tech]
18. Anthropic. (2025, July). How Anthropic teams use Claude Code (company-reported). [View on anthropic.com]
19. Scanlan, B. (Intercom). (2026, March). How we use Claude Code today at Intercom (company-reported). [View on fin.ai]
20. Spotify. (2026). How Spotify built Honk (company-reported). [View on spotify.com]
21. Hejazi Dehaghani, S. M., & Hajrahimi, N. (2013). Which Factors Affect Software Projects Maintenance Cost More? Acta Informatica Medica. (Estimates that about 90 percent of software life cost relates to the maintenance phase). [View on nih.gov]
22. Storey, M.-A., & Fowler, M. (2026, February). How Generative and Agentic AI Shift Concern from Technical Debt to Cognitive Debt & Future of Software Development (Thoughtworks retreat). [View on margaretstorey.com] and [View on martinfowler.com]
23. Piech, C. (Stanford University). (2026). Interview on learning to code in the AI era and the Code in Place experiments. [Watch on YouTube]
24. NBER / Federal Reserve Bank of Atlanta. (2026). Survey of approximately 6,000 corporate executives across four countries. [View on atlantafed.org]
25. Veracode. (2026, July). 2026 GenAI Code Security Report (56 percent average security pass rate across more than 100 models). [View on veracode.com]
26. CodeRabbit. (2025, December). State of AI vs Human Code Generation (470 open-source pull requests). [View on coderabbit.ai]
27. GitClear. (2026). The Maintainability Gap: 2026 AI Code Quality Research (623 million changes, 2023 to 2026). [View on gitclear.com]
28. Buytaert, D. (2026, June). AI and the great CMS unbundling. [View on dri.es]
29. Zyxware. (2013). Quality: A Perspective (internal presentation). [View on slideshare.net]

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. 

Written from several years of close observation of this field and hands-on work with AI on our own products. AI assisted with drafting and editing. All claims, figures and sources were verified by the author.