“I don’t read the code”

AI adoption among software engineers is nearing total ubiquity. And there is a growing movement of individuals who claim that we have passed a threshold in model quality whereby we no longer have to read generated code. It may surprise you that I tend to agree in many cases. However, this does not absolve developers of the responsibility to understand what is being generated and to improve their strategy to produce better software into the future.

tl;dr, check out the bottom of the newsletter for some practical ways to become a better developer in 2026.

How can this drive cost?

As we become more adept at programming using AI tools, the cost of creating code goes down drastically (not to be confused with the cost of defining the problem, which is hard to change). But we tend to obsess over reducing the cost of code generation, while ignoring the cost of ongoing liability. This includes the cost of maintenance, extensibility, and any incidental costs along the technology’s lifespan.

This year, a group of researchers at SMU in Singapore performed an analysis of over 6500 public codebases that had at least one AI-authored commit. They then isolated 300,000+ commits from the top 5 AI coding tools within the sample (Copilot, Claude, Cursor, Gemini, and Devin). They ran these commits through a series of linters, and classified commits based on whether an issue was introduced or resolved. Issues included security vulnerabilities, runtime bugs, and code smell issues (such as broad exception handling and unused variables). Even with this relatively narrow, purely static analysis; the researchers found that more than 15% of all sampled commits contained one or more of these issues.

Now, the code analyzed by this study was mostly from 2025. You would expect that as models become more capable, that the percentage of commits which introduce issues will go down. This may be true, but as the volume of AI-generated code increases, the sheer number of introduced issues increases as well, even if the underlying rate goes down. This is reflected in the study’s findings, which indicate cumulative AI-generated tech debt growing exponentially within the study’s codebases.

Note that this measures surviving issues. They also checked to see if issues had been resolved within the time window of the study.

Tech debt is not new, and there is no attempt at comparing AI-authored code to human-authored code within this study. For one thing, there’s no way to guarantee that human attributed code was not actually generated, and analyzing code from before the advent of AI code generation introduces too many confounding variables. So, we must take from this data what we can.

Let’s isolate just the security issues, as these are the most likely to contribute to direct liability costs. These included executing subprocesses without a shell check and introducing partial executable paths, both of which can leave the door open for hackers to execute arbitrary malicious processes. Security issues only made up 5.1% of all recorded issues. Even so, this amounted to 3.22 surviving security issues per 100 commits.

To over-simplify, you can imagine that each time you have AI commit code, there is a 3.2% chance that you introduce a long-standing security vulnerability. If this percentage holds, a team of developers will be introducing a dozen or more (if AI actually accelerates the rate of commits) of these security issues per month.

Broadly speaking, there are two ways to preempt these security issues. The most robust way is to include these static linters or some AI-driven qualitative analysis within your CI/CD pipeline and catch the issues before they’re merged. The other way is to increase the care, agency, knowledge and responsibility of the human user who develops the specifications at the beginning of the process. I believe both of these approaches are important for sustainable AI development.

The automated approach introduces the direct cost of operating AI-driven analysis and re-executing targeted code generation. The human approach helps bridge an important contextual gap, which will improve overall strategy and code quality moving into the future.

The AI meta-context blind spot

Security on the whole is perfectly emblematic of what I call the meta-context blind spot. Other things included in this category are architecture, governance, codebase design, and proprietary business logic. All of these aspects are directly informed by business strategy, risk tolerance, future vision, user behavior, and/or relevant skill foundations. In other words, these all tend to touch the “real world” and contain deep wells of context wherein you don’t know what you don’t know. Only deep work and human context gathering (expertise) can provide the curated context to coding agents needed to account for these aspects within AI-driven development.

Of course, being trained on all of published human knowledge gives our coding agents very robust heuristics to guess at our meta-contextual needs. This is, however, where regression to the mean can make our coding agents quite bad strategists and decision makers in the long run.

This is illustrated in an analysis by the Software Improvement Group (SIG) that takes a critical eye to the architectural decisions made in Cursor’s FastRender browser development experiment from early 2026. In this experiment, a group of agents worked for 126 hours straight to produce 3M+ lines of code. This is estimated to have consumed 10-20 trillion tokens, which would cost some several millions of dollars. The end result was a mostly-functional, Rust-based web browser. The codebase contained an estimated 110 developer-years’ worth of Rust code.

After analyzing this experiment, SIG gave the FastRender codebase a 2.1/5 score on architecture (note: this is referring to the codebase structure, not cloud architecture, which is its own deep meta-contextual aspect), and a 1.3/5 score for maintainability. They found tight coupling and low modularity throughout the design of the systems, meaning that future change would be much more expensive.

Just as in systems built by human developers, a long series of reasonable-looking decisions can result in a tangled system and a mountain of technical debt. And the key difference between human developers and AI coding agents is that the human developers can easily access rich meta-context to inform strategy and future vision in order to correct the trajectory of code development.

It is also possible to give coding agents broad access to proprietary meta-context like internal documentation, or this neat architecture context graph tool developed by the folks at polylane (not a sponsor), that can give your agents at-a-glance insight to these meta-context systems. But this can introduce context bloat which ultimately can lead to poorer AI output and increased token costs. You can use sub-agents to run tools to curate context for coding agents, but this can create cascading hallucinations, a degrading game of agentic telephone. But no matter how you cleverly orchestrate the injection of relevant context to the coding agents, it is - at some level of the AI onion - the responsibility of humans to graft quality context into this system.

Now we’re left with a question: given that AI coding tools are here to stay, what are the practical strategies we can employ to mature our meta-context curation practices?

Conclusion: Maintaining meta-context

I would argue that developers who are having success in “not reading the code” are either deluding themselves, or have previously established a strong framework of how to provide meta-context. This framework has been built over years of writing code and interacting with complex systems. Given that we can now delegate much of the complexity of the code-writing process to AI, how do we develop our own sense of understanding?

1. 1. Apply curiosity to your code. Insist on ownership. Advocate for time to inspect, apply skepticism, and develop a perspective on the current and future state of the codebases you work in. Explore deeply in plan mode as well as in stand-alone exploratory sessions that are not tied to an explicit development effort.

2. 2. Find the meta-context aspects where you can provide the most value. Increase your proprietary expertise relating to the security, architecture, platform, or strategy around what you and your teams are building.

3. 3. Develop master-apprentice practices. As reliance on AI tools increases, knowledge silos will become more brittle. A large portion of junior developer responsibilities should revolve around developing and perpetuating quality context and software development heuristics.

4. 4. Study best practices and emerging technologies. Develop perspective and opinionated practices that you can apply to your specification development process.

5. 5. Get better at supplying context to agents. Find ways to introduce only the most valuable meta-context in order to direct agents up-front and employ your opinionated practices.

6. 6. Employ multi-perspective retrospectives. Identify key lenses through which to periodically assess the quality of AI output. Determine if more focus needs to be placed on security, architecture, codebase design, etc.

7. 7. Don’t be a notification juggler. Limit context switches in your everyday work. The value of developing focus will outweigh the value of tending to every agent stoppage ASAP. Time-box your deep work and exploratory sessions, and do not pay mind to human or agentic interruptions during these times.

At the end of the day, we must accept that using these tools is taking away our primary mechanism for learning about the work that we are responsible for. It’s up to you to address knowledge debt with intention.

For more of my writing, check out my blog.