3 posts tagged with "software-architecture"

The pitch is seductive: describe the behavior in English, the model emits the code, ship it. Prompts become the source, artifacts become the target, and the LLM sits between them like gcc with a friendlier front-end. If that framing held, the rest of software engineering — review, refactoring, architecture — would be downstream of prompt quality. It does not hold. And the codebases built on the assumption that it does start failing in a pattern that is now boring to diagnose: around month six, nobody can explain why a particular function looks the way it does, and every incremental change produces a wave of duplicates.

The compiler metaphor is the root cause, not vibe coding, not model quality, not prompt skill. It is a category error that quietly excuses teams from doing the work that keeps a codebase coherent over years. When you believe the model is a compiler, the generated code is an implementation detail, the same way assembly is an implementation detail of a C program. When you are actually running a team of non-deterministic, context-limited collaborators, the generated code is the asset — and the prompts are closer to Slack messages than to source.

The most effective AI agents in production today look nothing like the framework demos. They are not directed acyclic graphs with seventeen node types. They are not multi-agent swarms coordinating through message buses. They are a prompt, a tool list, and a while loop — and they ship faster, break less, and cost less to maintain than their framework-heavy counterparts.

This is not a contrarian take for its own sake. It is the conclusion that team after team reaches after burning weeks on framework migration, abstraction debugging, and DSL archaeology. The pattern is so consistent it deserves a name: the post-framework era.

Every AI demo starts with a blank slate. A fresh repo, no dependencies, no legacy authentication system, no decade of business logic encoded in stored procedures. The demo works beautifully. Then someone asks: "Can we add this to our actual product?"

That's where brownfield AI begins — and where most teams get stuck. The gap between a working prototype and a production integration inside a ten-year-old monolith is not a matter of scaling up. It's a fundamentally different engineering problem, one that requires adapter patterns, careful boundary design, and a deep respect for the existing system's constraints.