Cognitive debt in 2026: what we now know about AI code in web applications

Ask a language model for a search feature in your web application and the database query will probably be fine. In the benchmark Veracode published in March 2026, the models tested wrote code that stops SQL injection in 82% of cases. The same models stopped cross-site scripting in only 15%. The backend holds, and the search term lands in your HTML unescaped.

If you accept that change with one click, you won't see it. You have to know everywhere the search term ends up, and you only know that if you have worked through the code yourself. That gap between code that works and a team that understands why is called cognitive debt. In March I wrote a first article about it. Since then we have gained a model with three kinds of debt, a first experiment with an actual web application and a year of security data. There is also something uncomfortable: measuring it is getting harder, not easier.

Sources checked on 29 October 2026, at the original publication where possible. For each study I note whether it is peer-reviewed, a preprint, or from a company with a commercial interest. Advice that comes from me is marked as such.

What is cognitive debt, and what has changed since March?

Cognitive debt is the loss of a team's shared understanding of how and why a system works. The code runs, the tests are green, but nobody can say with confidence what a change will do. Margaret-Anne Storey, professor of computer science at the University of Victoria, gave the term this meaning in February 2026. In March she developed it into a preprint with three kinds of debt:

• Technical debt lives in the code: duplication, hacks, outdated abstractions.
• Cognitive debt lives in people. Storey calls it "the erosion of shared understanding across a team".
• Intent debt lives in what was not written down: the reasons behind the code, which developers and AI agents both need to work on it safely.

That third kind is the most useful addition. A team can understand its system perfectly well and still have recorded none of it. That works until a new colleague joins, or an agent that can only read what is there.

The profession picked the term up quickly. On 14 March Addy Osmani introduced the near-synonym comprehension debt: the growing gap between how much code exists in your system and how much of it any human genuinely understands. Martin Fowler adopted Storey's three-way split on 2 April, noting drily that he was getting "a bit bemused by debt metaphor proliferation". On 15 April Thoughtworks placed "codebase cognitive debt" in the Caution ring of its Technology Radar (volume 34), the category for things teams should consciously watch out for.

Is this old wine in new bottles? Partly. In 1985 Peter Naur wrote that a program is above all a theory in its makers' heads, and that the theory disappears when the makers leave. The new argument, made among others by Ginac in a preprint submitted to IEEE Software, is that with AI code that theory sometimes never forms. In Naur's case understanding was lost. Here it may never have existed.

The first experiment with a web application: further along, less understanding

Until this summer the hard evidence came mostly from Python exercises. On 29 July a preprint appeared that comes closer to everyday web work. A team led by Nishant Balepur had 54 students build a browser game in three files: HTML for structure, JavaScript for the game logic, CSS for styling. One group worked with Aider, a coding agent that edits the files itself (running GPT-4.1). The other group had a chatbot that could not see the code.

The agent group got further with the task. But on questions about how their own code worked they scored clearly worse, with a large effect (Cohen's d above 0.8). Afterwards all participants had twenty minutes to extend the game without AI. The agent users did no better there than the chatbot group, despite their head start.

The detail that matters most for teams: how people accepted the agent's changes made a difference. Those who let everything apply automatically averaged 0.615 on comprehension. Those who approved each file separately scored 0.777. And the participants knew it: they rated their own understanding lower and still preferred the agent.

These are students, a short task, and a preprint the authors themselves call exploratory. But it is the scenario Storey described, measured for the first time on web technology.

Where cognitive debt leaks in a web application

In a web application, code nobody understands is not a theoretical problem. It faces the open internet. The clearest figures come from Veracode, a security software vendor, so with an interest of its own. Still, this is the third measurement in a row showing the same pattern:

In July 2025, 45% of AI-written code contained a vulnerability from the OWASP Top 10. In March 2026 an average of 55% of generated code was secure, in July 56%: Veracode itself calls that "barely changed". By language, JavaScript scored 57%. Newer and larger models made little difference.

The pattern is instructive. Models have learned to use prepared statements, because every tutorial shows them. Escaping output depends on where the value goes: inside an HTML attribute, inside a piece of JavaScript or inside a URL, each needs something different. That is not in the code the model sees, but in how the application fits together. That is exactly the understanding missing from code nobody has worked through.

The documented incidents are often about authorisation: checks the builder did not know were needed. In May 2025 a researcher found that 170 of 1,645 apps built with Lovable had a Supabase database without working Row-Level Security. Lovable disputes the vulnerability report (CVE-2025-48757) and points to the customer's responsibility. Nobody disputes that the check was missing. In July 2025 a Replit agent deleted a production database during a code freeze and then wrongly claimed it could not be restored.

Then there are dependencies. A study at USENIX Security 2025 found that language models invented package names across 576,000 code samples: at least 5.2% for commercial models, 21.7% for open-source models. Whoever registers such a name gets free access to every project that copies the suggestion blindly. This is called slopsquatting. It is documented for npm and PyPI. For Composer, PHP's package manager, I found no research. That does not mean the risk is absent, only that nobody has measured it.

Why the bill lands at code review

When code appears faster than understanding, that understanding has to come from somewhere else. Usually that is the review. The largest datasets come from companies that sell analysis or review software, so read them as direction, not precise measurement:

• Faros AI (telemetry from 22,000 developers, 2026): pull requests 51% larger, 28% more bugs per PR, median review time five times longer, three times as many incidents per PR.
• GitClear (623 million code changes): moved code, a proxy for refactoring, fell from 21% in 2022 to 3.8% in 2026. Duplicated blocks rose 81% compared with 2023.
• Google's DORA team wrote in May 2026 that the time AI saves in writing is often spent again on checking and verifying.

More code is added, less old code is cleaned up, and review gets heavier. Yet no study has measured whether reviewers understand the AI code they approve. An approved PR is not evidence of understanding, only evidence that someone pressed a button.

How you use AI matters more than whether you use it

On one point last year's research agrees remarkably well, across very different setups. AI that delivers answers harms learning or adds nothing. AI that explains or gives hints does not.

Anthropic's study from January, which I already cited in March, can now be read in full. 52 mostly junior developers learned the Python library Trio. With AI they scored 50% on the comprehension quiz, without AI 67%. Within the AI group, people who first had code generated and then asked for explanations scored around 86%. Those who left debugging to the AI ended up around 24%. Those subgroups are tiny, two to seven people, so treat it as a hint, not proof.

Larger studies point the same way. In a randomised study with about a thousand secondary-school students (PNAS, 2025, peer-reviewed), the group with plain ChatGPT access scored 17% lower than the control group on the later exam without AI. A version that only gave hints removed that harm. A study at the Technical University of Munich with 275 first-year programming students (peer-reviewed) saw better scores on the exercise, but no extra knowledge. The researchers call unrestricted ChatGPT a "comfort trap". A meta-analysis from May 2026 of 23 programming studies (preprint) found a clear effect on productivity and no demonstrable effect on learning.

I also need to correct something. In March I cited the MIT study Your Brain on ChatGPT. A year and a half later it is still not peer-reviewed. A formal critical comment has appeared, covering among other things the small sample (18 participants in the decisive fourth session) and the EEG analysis. An EEG study by other researchers from June 2026 did find behavioural differences, but no significant differences in brain activity. It may still hold up, but I would no longer build an article on it.

Why the productivity question is becoming unmeasurable

METR, the independent research organisation behind the well-known 2025 measurement (experienced developers 19% slower with AI), tried again in 2026. It did not work. Between 30% and 50% of developers held back tasks they did not want to do without AI. The new estimates (18% and 4% faster) have confidence intervals that include zero, and METR itself calls them "very weak evidence". On productivity, the only thing published since is a survey of how useful people themselves find AI.

That is more than a methodological detail. You measure cognitive debt by having someone work on their own code without AI. Those people are getting harder to find. In the Stack Overflow survey of October 2026, 73% of developers use an AI assistant or agent every day. Asked when AI can be trusted, 48% say: when I can easily check the answer. For important decisions, 6.6% trust it.

What a web team can do tomorrow

The research does not call for a ban. It calls for a different way of working. The first point below is documented practice. The rest is my advice, derived from the studies above, and none of it has been tested for effect yet.

If you can't explain it, it doesn't go live

Kubernetes has had this as a rule since April 2026: "If you cannot personally explain changes that AI helped generate, your PR will be closed." Authelia, Asterisk and Apache Mahout have similar rules. For a web team that means the author of a PR can say for every change what it does and why, without asking the AI.

Approve per file, not everything at once

The difference between 0.615 and 0.777 in the browser game experiment cost nothing but attention. Switch off "accept all" in your coding agent for code that touches user input, authorisation or money.

Ask three web questions about every AI change

1. Where does this value end up in HTML, a template or JavaScript, and is it escaped correctly there?
2. Who may read or change this record, and where is that checked: in the database, in the API, or nowhere?
3. Does this package really exist, and is it the version and the author you expect?

This list is mine, but each question matches a measured weakness: 15% on XSS, the missing Row-Level Security, the invented package names.

Write down the reason, not just the code

You pay off intent debt with text. Record why a module is built the way it is, in a decision record, in the PR description, or in the instruction files agents read (AGENTS.md or CLAUDE.md). That helps the next colleague, and also the next agent, which will otherwise start guessing again.

Let the AI explain, and write some of it yourself

Claude Code has the output styles "Explanatory" and "Learning". The latter deliberately leaves gaps (TODO(human)) for you to write yourself. ChatGPT and Gemini have similar learning modes. No vendor has published what these modes achieve. They do fit the pattern from all the studies above: asking for explanations costs little, outsourcing everything costs understanding.

What nobody knows yet

As of October 2026 there is not a single study of cognitive debt in a real team maintaining a real PHP, JavaScript or TypeScript application over months. Every hard number about understanding comes from students or short lab tasks. The numbers from practice, such as bigger PRs, longer reviews, less refactoring and a 15% XSS score, come from vendors and measure symptoms, not understanding. Storey herself wrote in June: "We are still figuring this out."

My expectation: the first convincing evidence will not come from a lab but from incident data. It will be an outage where recovery time spirals, while on paper several people know the code. Until that research exists, I would treat the XSS figure and the comprehension gap after auto-accept as the same problem: code nobody thought through, live on a public URL. The participants in the browser game experiment knew they understood less and chose the agent anyway. That is not a reproach. It shows that the feeling of speed will not warn you here. Your working agreements have to.

For further reading: I wrote earlier about why beginners in particular have a hard time in the 2027 job market and about how to build an AI agent in PHP where a human says yes before anything happens.

Sources

• Margaret-Anne Storey, From Technical Debt to Cognitive and Intent Debt (preprint, March/April 2026) and Three Debts, Three Threats to Meaning (23 June 2026)
• Addy Osmani, Comprehension debt (14 March 2026)
• Martin Fowler, Fragments, 2 April 2026
• Thoughtworks Technology Radar vol. 34, Codebase cognitive debt (15 April 2026)
• Ginac, Epistemological Debt (preprint, 2026)
• Balepur et al., (Im)Paired Programming: Coding Agents Improve Productivity but Harm Understanding (preprint, 29 July 2026)
• Veracode, Spring 2026 GenAI Code Security Update (24 March 2026), 2026 GenAI Code Security Report (28 July 2026) and 2025 report (30 July 2025)
• Matt Palmer, Statement on CVE-2025-48757 (29 May 2025)
• Replit incident: eWeek (July 2025)
• Spracklen et al., We Have a Package for You! (USENIX Security 2025)
• Faros AI, The Acceleration Whiplash (2026)
• GitClear, Write-Only Mode: AI Code Quality in 2026
• InfoQ on the DORA report on the ROI of AI-assisted software development (May 2026)
• Shen and Tamkin (Anthropic), How AI assistance impacts the formation of coding skills (January 2026) and the full paper
• Bastani et al., Generative AI without guardrails can harm learning (PNAS, 2025; Wharton summary)
• Bassner et al. (TU Munich), Computers & Education: Artificial Intelligence (December 2025)
• Maier et al., meta-analysis of AI and programming (preprint, May 2026)
• Kosmyna et al., Your Brain on ChatGPT (preprint), comment by Stankovic et al. and EEG study by Khurana and Liew (June 2026)
• METR, We are Changing our Developer Productivity Experiment Design (24 February 2026)
• Stack Overflow, Developer Survey 2026, AI (6 October 2026)
• Kubernetes, Open source maintainership in the age of AI (26 June 2026) and the AI guidance
• Claude Code documentation, Output styles
• Peter Naur, Programming as Theory Building (1985)