Greenfield vs. existing tech stacks: AI excels at unconstrained prototyping but struggles to integrate with existing systems. Beyond that, operating in production environments imposes hard limits that turn prototypes brittle. Greenfield vs. Existing Tech Stacks<\/p>\n Large language models (LLMs) can draft a new microservice quickly in a vacuum that will perform well in isolation. But operating in production demands integration with messy realities: legacy code, service boundaries, data contracts, authorization middleware, protobuf schemas, CI\/CD pipelines, observability stacks, service-level objectives (SLOs), performance budgets\u2026 I could go on. This is all before unpredictable users interact with the software.<\/p>\n When you build new software, you engage in what might be called an artistic process. You start with a vision of expected behavior: Data should flow from this initial state to this end state, transformed in this particular way through a specific control flow. You\u2019re painting with possibility, creating something from nothing.<\/p>\n This is why AI coding assistants produce such impressive prototypes. They\u2019re phenomenal at this forward-looking, unconstrained creative generation. But to run high-quality software well, more code isn\u2019t the answer. You need code that can operate within a very specific set of parameters. The challenge is that communicating these many and nuanced parameters to an LLM is not a simple task.<\/p>\n Because LLMs excel at communicating with us in our natural language, we overestimate their ability to write quality software. But while language is flexible and forgiving, code is not. Code is executable and compositional: Correctness depends on precise contracts across files\/services. The compiler and runtime are unforgiving; small errors cause cascading failures, security holes or performance regressions.<\/p>\n The Dory Problem<\/p>\n We\u2019ve established that current LLMs struggle to write code that will operate outside of controlled greenfield environments. But why can\u2019t we use AI to troubleshoot and debug that code?<\/p>\n To debug properly, you need to wrap your head around the entire architecture. You need to understand how data actually flows through the system, not just how it was supposed to flow. You need the ability to reverse-engineer a system starting with a defect. You need models that can consume massive, complex architectures built over decades and understand why they behave the way they do. You need an understanding of what already exists, what came before, the paths not taken.<\/p>\n Unfortunately, most LLMs operate a lot like the character Dory in \u201cFinding Nemo\u201d: They have no context from one query to the next and have extremely short memories.<\/p>\n Many companies operate codebases accumulated over 20, 30 or 40 years. These systems have emergent behaviors, implicit dependencies and historical workarounds \u2014 compound interest on their technical debt. Without a broad understanding of the entire system architecture, the interconnections of multiple code repos, past decisions and deploys, it\u2019s nearly impossible to troubleshoot complex issues.<\/p>\n Inconsistent Tool Maturity<\/p>\n The last reason AI code struggles in production is because the AI tools to support the software delivery life cycle<\/a> (SDLC) have not all matured at the same rate. Take for example, the evolution of the digital camera. The first digital cameras looked a lot like their analog counterparts \u2014 we couldn\u2019t imagine another way to apply the technology. But soon we learned we could embed cameras everywhere: from laptops to phones to doorbells to cars. Cameras aren\u2019t just for taking pictures anymore; they can also help us get from point A to point B.<\/p>\n Even though it\u2019s only been a few years, AI code generation tools have already gone through a rapid transformation. Our first attempts at integrating AI into our SDLC looked a lot like slapping AI into our IDE \u2014 the equivalent of a digital SLR camera. The initial version of GitHub Copilot was essentially enhanced IDE autocomplete.<\/p>\n But over the past few years, tools like Cursor<\/a>, Windsurf<\/a> and Claude Code<\/a> took over with a very different approach. They imagined a whole new workflow where you\u2019re not actually writing the code at all. Instead of working in the code editor, you\u2019re working in a chat box, expressing your intent, and the changes in the code happen naturally.<\/p>\n Today\u2019s standard for AI code generation is a second-generation product that changed the entire workflow. But when we look beyond code generation at the rest of the SDLC, we\u2019re still in the first generation of these products. If we really want to improve engineering velocity, we need to look beyond code generation. We need tools that will help us reimagine and manage the complete end-to-end SDLC with AI.<\/p>\n The Path Forward<\/p>\n There are many tools that tackle modern code operations<\/a>, but they are looking at each step in the process in a silo. They are building very effective digital cameras, but don\u2019t have the imagination to rethink entire processes from scratch.<\/p>\n You can get incremental gains from a better AI-powered code review system or with an agentic site reliability engineer, but the biggest advances will come from tools that rethink the entire software operations process, not just enhance an existing process.<\/p>\n The AI tools that succeed in helping operate production environments will be those that can reverse-engineer complex systems, enumerate states systematically and help developers pin down the specific conditions that produce unexpected behavior. They\u2019ll need to be more than artistic builders \u2014 they must also be scientific investigators. And they will look at the problem holistically, not in silos.<\/p>\n Until then, expect to see impressive prototypes and frustrating production experiences. The cognitive mismatch isn\u2019t going away \u2014 it\u2019s fundamental to how these systems work.<\/p>\n
\nThe Dory problem: AI struggles to debug its own code because it lacks persistent understanding. It can\u2019t learn from past mistakes<\/a> or have enough context to troubleshoot systems.
\nInconsistent tool maturity: While AI code generation tools are evolving rapidly, deployment, maintenance, code review, quality assurance and customer support functions still operate at pre-AI velocities.<\/p>\n
![](\"https:\/\/www.newsbeep.com\/il\/wp-content\/uploads\/2025\/11\/689e701c-cropped-25d4a37b-animesh-koratana-scaled-1-600x600.jpeg\"\/)
<\/p>\n