AsianDadEnergy's Substack Podcast
A few weeks ago, I stumbled across a debate that has been making the rounds in software engineering circles. The spark came from Boris Cherny, an engineer at Anthropic and the creator of Claude Code, arguably the most influential AI Agentic Coding harness in the world today. During a podcast appearance, Boris made a statement that immediately grabbed my attention: Coding is largely a solved problem. He went on to explain that he hadn’t written a line of code by hand since November, and that essentially all of his code is now authored by Claude Code. Needless to say, this generated strong reactions. Some people interpreted it as evidence that software engineering is about to be fully automated. Others saw it as confirmation that AI coding tools are delivering unprecedented productivity gains. As someone with twenty-five years of experience in software development, I found myself somewhere in the middle. Because while I absolutely believe AI is transforming software engineering, my own experiences suggest that programming is nowhere close to being a solved problem. In fact, the more I use these tools, the more complicated the situation appears. The Rise of Agentic Software Development Over the past few years, we’ve witnessed a rapid evolution in how software gets built. First, developers used AI to generate snippets of code. Then they began using AI assistants to complete larger programming tasks. Today, we’re entering what many people call Agentic Software Development. Instead of asking an AI for a few lines of code, developers increasingly delegate entire workflows. The AI can analyze requirements. Generate designs. Write code. Create tests. Review its own output. Deploy software. Monitor production systems. In theory, the human becomes less of a programmer and more of an orchestrator. The promise is obvious. If AI agents can perform most of the implementation work, then software engineers can become dramatically more productive. Ten times more productive, according to some advocates. Perhaps even more. At least, that’s the dream. My First Encounter With Enterprise Agentic AI In 2025, I returned to work after a lengthy medical leave. My wife had experienced a serious health crisis, and I had spent months focused almost entirely on family. When I came back, one of the first things I noticed was that my employer had become obsessed with Agentic AI. Leadership had heard about tools like Claude Code and Cursor. They had heard stories about developers becoming ten times more productive. Naturally, they concluded that our company needed its own internal version. Let’s call it Kevin. Kevin was our homegrown agentic harness. Compared to Claude Code, Kevin felt slower, heavier, and burdened with enterprise compliance guardrails. It ran on older-generation models. It often struggled with context. And yet, despite all its flaws, Kevin was still capable of orchestrating significant portions of software development. Using Kevin gave me a front-row seat to what Agentic AI actually looks like inside a large enterprise. What I observed left me both impressed and concerned. The Business Knowledge Problem One of the biggest weaknesses I encountered had nothing to do with coding itself. It had to do with understanding. AI models are remarkably good at generating software. What they are not particularly good at is understanding the business context behind that software. Organizations often operate on thousands of unwritten assumptions. Knowledge exists in hallway conversations. Slack threads. Meeting notes. Institutional memory. The heads of senior employees. Much of this information never appears in formal documentation. Humans navigate these gaps naturally. AI agents do not. If a requirement is not explicitly documented, the AI will often substitute something that appears reasonable based on its training data. The generated code may compile successfully. The unit tests may pass. The architecture may look elegant. And yet the implementation may completely miss the actual business objective. This problem becomes particularly severe in large brownfield systems where decades of accumulated business logic exist beneath the surface. The Context Window Wall Another challenge is context. Every AI model has a limited working memory. For small projects, this isn’t a major issue. For enterprise software systems containing millions of lines of code, it becomes a constant battle. Once an AI agent exceeds its effective context window, strange things begin to happen. The model forgets previous decisions. It hallucinates APIs. It reintroduces deprecated libraries. It generates solutions that were already rejected earlier in the workflow. Developers have created countless mitigation strategies. Context compaction. Summarization. Subagents. Selective context filtering. These techniques help. But they don’t eliminate the underlying limitation. The larger the system becomes, the harder it is for the AI to maintain a coherent mental model of the entire application. Ironically, this is often where software engineering is most difficult in the first place. The Hidden Cost of Infinite Code One thing AI agents are exceptionally good at is generating code. Lots of code. An astonishing amount of code. Thousands of lines. Tens of thousands of lines. Entire subsystems can appear almost instantly. The problem is that quantity and quality are not the same thing. Many AI-generated implementations contain unnecessary abstraction layers. Duplicate functionality. Excessive complexity. Architectural choices that seem reasonable locally but become problematic globally. Without strong human oversight, repositories begin accumulating what can only be described as AI sediment. Layer upon layer of generated code. Each piece understandable in isolation. Collectively becoming harder and harder to maintain. Technical debt compounds quietly. And unlike financial debt, software debt often remains invisible until it becomes a crisis. The Vibecoding Trap This brings us to what I believe is the most important problem. Human review capacity. A team of AI agents can generate thousands of lines of code per hour. A human engineer cannot review thousands of lines of code per hour with high confidence. The math simply doesn’t work. As output increases, review quality inevitably declines. Cognitive fatigue sets in. Attention drops. Comprehension weakens. Eventually, the reviewer stops acting as an engineer and starts acting as a rubber stamp. This is the danger behind what many people call vibecoding. The developer repeatedly prompts the AI until something appears to work. The code ships. Nobody fully understands it. Nobody feels ownership over it. And nobody wants to maintain it six months later. At that point, accountability becomes largely fictional. The engineer remains responsible for the software without truly possessing the knowledge necessary to evaluate it. So Is Coding Solved? Despite everything I’ve written, I remain incredibly optimistic about AI. These tools are genuinely transformative. For greenfield projects, prototypes, internal tools, and well-understood problem domains, the productivity gains are astonishing. Recently, I used Agentic AI to build one of my own projects. The agents completed work in hours that might previously have taken days. The productivity boost was real. But here’s the important distinction: The AI performed the implementation. I still spent days reviewing the code, testing the software, validating assumptions, and ensuring everything actually worked. The bottleneck moved. It didn’t disappear. And that’s why I struggle with the claim that coding is solved. Perhaps code generation is becoming solved. Perhaps implementation is becoming increasingly automated. But software engineering has always been about much more than typing characters into an editor. It involves judgment. Tradeoffs. Domain expertise. System design. Risk management. Human communication. Institutional knowledge. And responsibility. None of those problems appear solved to me. The Next Rabbit Hole: Loop Engineering What’s particularly fascinating is that many of the engineers pushing Agentic AI furthest seem to be moving beyond prompting altogether. Boris Cherny has suggested that developers should stop prompting and start building loops. Peter Steinberger has made similar arguments. The idea is that autonomous agents should continuously generate, evaluate, and refine their own work. This concept is often referred to as Loop Engineering. I’ve spent time reading about it. Experimenting with it. Trying to understand it. And if I’m being honest, I still don’t entirely get it. What’s more frustrating is that concrete, end-to-end examples remain surprisingly rare. The discussions often feel abstract. Almost mystical. As if everyone has seen the future except the people trying to build software today. Maybe that’s because we’re still in the earliest stages of this transition. Or maybe we’re collectively mistaking experimentation for certainty. Either way, I’m not convinced we’ve arrived at the destination yet. My Current Conclusion Agentic AI is one of the most important technological developments of my career. It is already changing how software gets built. It will continue changing how software gets built. But from where I sit, coding does not look like a solved problem. It looks like a rapidly evolving one. And that’s actually far more interesting. For now, I’ll keep experimenting. I’ll keep learning. And I’ll keep trying to separate the genuine breakthroughs from the hype. Because if the future of software engineering really is being rewritten by AI agents, I’d like to understand what’s actually happening beneath the marketing slides. And if you’re curious too, you’re welcome to come along for the ride. Get full access to AsianDadEnergy's Newsletter at asiandadenergy.substack.com/subscribe [https://asiandadenergy.substack.com/subscribe?utm_medium=podcast&utm_campaign=CTA_4]
38 Episoder
Kommentarer
0Vær den første til å kommentere
Registrer deg nå og bli medlem av AsianDadEnergy's Substack Podcast sitt community!