Theo on AI Coding, Cognitive Debt and Keeping Your Skills

AI coding tools are here to stay, and I enjoy using them. I also notice that I write less code myself: my editor is often full of prompts and data for agent runs. I am learning new skills, including Git and remote systems, while some old ones feel rusty. When a result fails, it is tempting to pull the slot-machine lever again rather than understand why.

Lars Faye’s article “Agentic Coding is a Trap” calls this cognitive debt. Technical debt is an interesting contrast: agents can also help remove it. At Twitch, a GraphQL migration once broke roughly 8,000 TypeScript files, and engineers divided the fixes in a spreadsheet. Such repetitive migrations are the kind of work AI can make much less costly.

The old migration consumed engineering time because the same mechanical change had to be applied across thousands of files. That kind of maintenance often accumulated when it was too expensive to tackle. Agents can change the economics of this work, even as generated changes still need validation.

Faye challenges the idea that a developer can write a plan, delegate implementation, and simply steer the agents from above. Repeated generations may increase the distance between the person responsible and the code being committed. He lists system complexity, skill atrophy, vendor dependence and uncertain spending as tradeoffs.

I agree with much of that, but I would separate the price of a token from the cost of achieving a given result. Teams may spend more because they use far more tokens, even if a comparable level of model performance becomes cheaper. A higher bill and a lower cost per task can coexist.

In the benchmark chart I was viewing at the time, GPT-5.5 medium and GPT-5.4 xhigh received similar scores, while the displayed cost of running the benchmark was roughly $1,200 versus $2,850. The chart is a snapshot of one benchmark and its accounting, not proof of equivalent performance on every real task or a current price quote.

I also pointed to a roughly $500 benchmark cost for GPT-5.5 low and about $4,200 for Sonnet 4.6 max at a similar score. That comparison illustrates my point about cost at a chosen benchmark level, not a universal eightfold reduction in every application. Companies can nevertheless see their total AI expenditure rise sharply as usage grows.

An illustrative company might have paid $100,000 for a coding tool last year and already spent $500,000 only a few months into this year. That rising bill is a real budget concern even if the unit cost of comparable model work has fallen.

Faye argues that supervising thousands of generated lines requires critical thinking and architectural knowledge—the very skills that can suffer if people stop exercising them. Cognitive debt is the gap between a system and the team’s understanding of how and why it works. Reports of that gap are important, though anecdotes alone cannot establish how common it is.

I have experienced a version of this for years: build a project quickly, leave it for a month, and come back unable to remember all the details. Before AI I shipped several projects a year by cutting scope aggressively and moving on as soon as something worked. AI lets many more people move at a similar pace.

My early approach was to narrow projects until I could deliver something useful. I created the T3 stack partly to make it easier to build quickly and confidently using familiar components. Moving quickly did not mean I could remember every decision after leaving a project.

The difference is that I had worked hard to understand the building blocks. Even when I forgot how a particular project was assembled, I could infer likely failures from those pieces. If AI removes the immediate incentive to learn them, a developer may produce more software without acquiring the knowledge needed to maintain it.

Learning often feels unpleasant before it pays off. I compare it to learning to skateboard: falling, failing and feeling incompetent cause many people to quit before mastering a trick. With AI there is always an easier-looking option: ask again and hope the answer works, instead of reading documentation or debugging.

I try to deliberately enter unfamiliar territory, such as using Rust, and resist the urge to have the model remove every difficult step. Yet the same tools have helped me learn more about cryptography: I can ask questions, make challenges, and arrive at conversations with experts better prepared. Whether AI replaces thinking or supports it depends on how I use it.

For example, I now make cryptography challenges and ask agents questions until I have exhausted what they can explain. When I turn to friends with deeper expertise, I can ask better questions. The tool lowers the cost of starting, but curiosity still has to drive the investigation.

Faye questions the claim that prompting is simply the next abstraction layer, comparable to moving from assembly to C or from C++ to JavaScript. Higher-level languages hide details but provide structured interfaces. Natural language introduces ambiguity; I have become less convinced that it is the same kind of abstraction.

Strong engineers benefit from understanding adjacent layers, even when they normally work at a higher level. Faye points to posts by developers who feel less confident after heavy AI use. These are individual accounts, not a controlled estimate of population-wide decline, but they show why people are worried.

Faye includes accounts from experienced developers as well as juniors. One describes an employer requiring AI to write and review code while humans inspect outcomes, leaving the developer worried about losing the skills needed for future work. I regard such a mandate as a bad idea.

My background may explain why my experience differs. I had already spent years managing a team, understanding systems and helping debug outages rather than writing every line myself. I write a small share of our product code, yet my system understanding has grown, and AI helps me guide the team. That is my experience, not a guarantee for everyone.

Newer developers face a different challenge: the tools can let them build a large system before they have learned how its pieces fail. Posts about juniors who cannot debug AI-written code are worrying. I would not conclude that debugging with AI is itself bad; the issue is relying on it while refusing to learn the system.

A report about a junior who cannot debug generated code prompts an important distinction. When users are affected, I want every useful tool available. AI can help inspect errors and propose hypotheses, but the developer still needs to reason about evidence and understand the application.

During an outage in our Ping video product, I sent an error to one Codex instance while I investigated the browser and logs myself. My familiarity with the T3 stack helped me narrow the problem to a Prisma relation returning a null identifier. The first agent had a different theory, so I did not simply accept it.

I then asked another agent which referential-integrity check was likely to be involved. It identified the relationship between users and rooms. I used the model to help formulate queries to identify and remove the affected links, and the service recovered. This worked through an exchange between my existing system knowledge and the tool’s assistance.

I used the agent’s help in stages: identify the likely table relationship, find the affected row, and formulate cleanup queries. I was concurrently reading logs and code rather than waiting passively. Without my knowledge of the system, I do not think that exchange would have worked as well.

Faye’s concern is that senior engineers traditionally acquired experience through years of implementation and debugging before taking on more abstract roles. If juniors delegate every difficult step, where will the next generation of experienced engineers get that practice? I share the concern, even though I cannot prescribe a single new path to expertise.

I benefited from being allowed to participate in architecture and high-priority incidents early in my career. Understanding how a system fails made me better at finding causes across components. I think people can still build those skills with AI, but the incentives to examine fundamentals may be weaker.

My old advice was to learn fundamentals when a real problem makes them useful: for example, study a faster sorting method when performance demands it. Now an agent may apply a solution without the developer learning why. I worry about that, while still seeing curious young builders use these tools to explore and understand more than they could before.

AI can leave someone maintaining a codebase much larger than their current experience would normally allow. That is an opportunity if they investigate failures and build understanding, and a problem if they simply give up whenever it breaks. Open-source maintenance can offer valuable feedback from contributors with different levels of experience.

I value open-source maintainers because they learn to review contributions from people with many different backgrounds and deal with software used by real people. That experience can accelerate learning, although years on a résumé alone do not tell the whole story.

Experienced developers are not immune. Faye cites Simon Willison’s account of losing a firm mental model of some applications. He also cites Anthropic’s description of a supervision paradox: effective oversight requires skills that may weaken when AI use displaces the practice that develops them. The scope of any research finding still depends on the study.

I do not know exactly what the best training path looks like now; I cannot reset my own experience and start over. Faye argues that teams increasingly prioritize output speed over understanding, consistency and readable code. I would add that good engineering involves tradeoffs: solving the right user problem and delivering promptly also matter.

Speed can be valuable when it comes from understanding, but forcing everyone to keep pace can cause trouble. I have seen teams slow down to keep a shared grasp of what they are building. Agent-generated volume can overwhelm review, and company mandates or token leaderboards may reward activity instead of learning.

I am skeptical about whether education products can compete commercially with tools that deliver immediate gratification. That is my judgment based on investments I have made, not a measured law about every learner. People who deliberately use AI to explore and understand can still learn a great deal.

Coding is also a way to plan. At Twitch I often built a minimal version before writing a detailed specification. Sometimes the prototype was good enough to ship; otherwise, the experience exposed the hard parts and made the eventual plan better. An AI-assisted prototype can serve the same purpose if I remain engaged with it.

Faye quotes Dax explaining that writing types, functions and folder structures helps him figure out what a feature should be. I agree that this exploration is valuable. I also think AI can lower the cost of reversing a mistaken structure, making experiments worthwhile that I previously would have avoided.

A detailed prompt does not remove every ambiguity. Models can fill gaps with assumptions or invent an API, so their output needs review and revision. Understanding a problem through concrete implementation is one way to surface details that an apparently complete specification missed.

Faye warns that some teams stopped working during a provider outage because their workflow depended on one service. I disagree with treating all of this as unavoidable lock-in: developers can prepare alternatives. My own T3 Code supports switching between agents and providers, though that does not mean switching is effortless or that outages can never coincide.

I also disagree with the implication that variable token costs are unique to AI or that businesses should expect all costs to be fixed. Actual spending is still worth tracking, and alternatives need to be tested before an outage. My broader point is to understand what a service does for you and what work would be required to replace it.

Faye does not propose rejecting generated code. He suggests making AI a secondary process: use it for research and planning, stay engaged in implementation, and delegate selectively. His own workflow includes writing substantial portions by hand, using pseudocode, and never generating more than he can review in one sitting.

He also avoids asking an agent to implement something he could not do himself, except for learning experiments that may be discarded. I like going back and forth over pseudocode, including asking a model how a proposed approach maps to my actual codebase. That interaction can narrow the gap between intention and implementation.

I would add a distinction based on how the code will be used. A one-off analysis script or migration and a hot path executed by users thousands of times have different demands. AI makes it practical to write scripts for tasks that previously were faster to do by hand, while important production code deserves deeper understanding and scrutiny.

That distinction is only useful if you know what runs and how often. For disposable work, I can explore more possibilities. For core code, I can ask agents to explain architecture, identify hot paths and help with large changes, while taking responsibility for understanding and validating the result.

For one-off personal work, I have used generated scripts for calculators and managing files on my NAS. Before AI, writing a large script for a single operation might have taken longer than doing the job manually. Now some of those experiments have become practical.

Faye describes his approach as producing better work rather than necessarily making him faster. I want both: faster execution of small tasks and better quality where code matters. The danger is confusing those two categories and treating every generated change as equally disposable.

Faye closes by stressing that productivity gains are real, but so is the understanding developed through direct engagement. He worries that outsourcing all thinking will weaken the skills needed to supervise the tools. I agree with the warning: use AI to advance your thinking, ask better questions and learn more, rather than letting it replace the effort to understand.