Category Archives: Specification

The Three Branches of AI-Driven Development: Why Software Engineering Needs Its Own Separation of Powers

by

0


Over the last two years, a quiet revolution has taken hold in how software gets built. Large frontier models from major AI labs have matured to a point where they do not just assist with coding. They reshape the entire lifecycle of how software moves from idea to production. And with this shift comes a question that few enterprise technology leaders are asking loudly enough: if anyone can now generate code, who is responsible for making sure it is the right code?

I have been thinking about this through an unusual lens. The structural principle that democratic societies use to prevent unchecked power applies remarkably well to AI-driven development. Legislative, Executive, Judicial. Specification, Code Generation, Quality Review. Three branches, each essential, none sufficient alone.

The Democratization Nobody Expected

For decades, writing software was a craft reserved for those who understood syntax, compilers, and the particular pain of a misplaced semicolon. Today, state-of-the-art foundation models can generate entire modules from a natural language description. A product manager can describe a feature and get working code within minutes. A domain expert with no programming background can prototype a data pipeline overnight.

This is genuine democratization. But democratization without structure leads to chaos. When everyone can generate code but nobody owns the specification or validates the output, you get “vibe coding” — throwing prompts at an AI and hoping for the best. It works for demos. It fails for production systems.

What the industry needs is not less AI involvement. It needs governance. It needs separation of concerns at the process level.

The Legislative Branch: Specification as Law

In a functioning democracy, the legislature writes the laws. In spec-driven development, the specification is the law. It defines intent, constraints, and architecture decisions before a single line of code is generated.

This is exactly what frameworks like Spec Kit have formalized. The open-source toolkit treats specifications not as disposable documentation that rots the moment code is written, but as living, executable artifacts. Commands like /specify, /plan, and /tasks structure the workflow around intent first, implementation second. Code serves specifications, not the other way around.

The BMAD Method takes this further with its multi-agent approach. Specialized AI agents — an Analyst, a Product Manager, an Architect — collaborate to produce comprehensive requirement documents and architecture specifications before any development agent touches the codebase. The “Agentic Planning” phase is essentially a legislative process: multiple perspectives debating and refining the rules that govern implementation.

The human role here is critical. You are the lawmaker. Advanced reasoning systems help you articulate requirements and stress-test architecture decisions. But the intent, the business logic, the “why” — that remains yours.

The Executive Branch: Code Generation as Implementation

The executive branch implements laws, it does not write them. In our metaphor, this is where advanced coding systems from major AI labs do their most visible work. Given a well-defined specification, new generation reasoning systems produce code with remarkable speed and consistency.

BMAD’s “Context-Engineered Development” phase illustrates this well. The Scrum Master agent breaks the specification into hyper-detailed story files containing full architectural context, implementation guidelines, and testing criteria. The development agent works from these self-contained packages — no context collapse, no re-explaining requirements.

Spec Kit follows a similar philosophy. The specification constrains the generation. Security requirements and compliance rules are baked into the spec from day one, not bolted on after.

The efficiency gain is real. But so is the risk. An executive branch without checks becomes authoritarian. Code generation without validation becomes technical debt at machine speed.

The Judicial Branch: Quality Review as Constitutional Court

The judiciary reviews whether the executive acted within the law. In software, this is the quality gate — code review, testing, validation, compliance checking. This is where current AI-driven development is weakest.

Too many teams generate code with frontier models and then skip meaningful review because the output “looks right.” This is the equivalent of a government without courts. Both BMAD and Spec Kit recognize this gap. BMAD includes rigorous pull-request reviews where humans and AI agents inspect generated artifacts, creating a “continuous compliance ledger” — an auditable trail from requirement to deployment. Spec Kit provides an /analyze command that acts as a quality gate, checking internal consistency of specs and plans.

But tooling alone is insufficient. A model can tell you whether code compiles and passes tests. It cannot tell you whether the code solves the right problem for the right user in the right regulatory context. Validation, critical reasoning, architectural thinking — these are not nice-to-have skills. They are the judiciary of your development process.

Beyond Code: Agents, Decisions, and the Vanishing Middle Layer

This separation of powers extends beyond code. Across the enterprise, AI agents are replacing traditional applications. Instead of building a reporting dashboard, you configure an agent workflow that queries data and delivers insights. Instead of a project management tool with seventeen tabs, you define the outcome and let orchestrated agents handle the rest.

Less management overhead, more focus on core tasks. Decision-making improves because data becomes accessible through natural language rather than complex BI tooling. But the three-branch principle still applies. Someone specifies. The model executes. Someone validates. Without all three, you have automation without accountability.

What Does This Mean for IT Specialists?

If you are a developer today, your value is shifting. Writing code from scratch becomes a smaller part of the job. Specifying what should be built, reviewing what was generated, and understanding why architectural decisions matter — this is where human professionals become irreplaceable.

The psychological impact should not be underestimated. Many engineers built their identity around the craft of writing code. Being told that a model can do this in seconds is unsettling. But the constitutional metaphor offers a reframe. You are not being replaced by the executive branch. You are being promoted to the legislature and the judiciary.

The learning pressure is significant. Writing specifications that frontier models can execute against, developing the critical eye to catch subtly wrong generated code, understanding frameworks like BMAD or Spec Kit — these skills must be learned on the job, now.

For technology leaders, the message is clear. Do not let your teams generate code without specification governance and quality review. Build the three branches into your SDLC. Treat specification as a first-class engineering activity. Invest in your people’s ability to think critically about machine-generated output. The models are capable. The tools exist. What is missing is the governance mindset. It is time to build it.

The Quiet Restructuring: When Frontier Models Meet Legacy Reality and the Rise of the Context Engineer

by

0


Over the last three years, something has shifted in enterprise IT that is harder to name than to feel. It is not one technology, not one framework. It is the slow realization that large frontier models — the advanced reasoning systems from major AI labs — have stopped being an experiment and started being a structural force. They sit now in the middle of how we develop, how we operate, and how we think about the people who do this work.

I have spent thirty-five years in enterprise technology, from mainframes through cloud-native. And I have never seen a shift that touches so many layers simultaneously while being so quietly underestimated in its organizational impact.

From Writing Code to Owning Lifecycles

For most of my career, a developer was someone who wrote code. Good code, hopefully. But the primary measure was always output — features shipped, bugs fixed, lines committed. That model is dissolving.

When advanced coding systems from major AI labs can produce a working function in seconds, typing code loses its weight. What gains weight is everything around it: understanding what should be built, validating that what was generated fits the architecture, and owning the lifecycle from deployment through decommissioning.

I saw this when one of our teams used a state-of-the-art foundation model to refactor a payment processing module. The model produced clean code in minutes. But it took a senior engineer three hours to verify that the refactored logic preserved every edge case from twelve years of business rules. That three hours was the real work.

The Amplification Trap

There is a real danger that I observe in organizations moving fast with these tools. I call it the amplification trap. Because frontier models are so capable at producing plausible output — code, documentation, test cases, infrastructure definitions — there is a tendency to trust without adequate verification.

When I started my career, a junior developer who copied code from a manual without understanding it was considered negligent. Today, a team that accepts AI-generated Terraform configurations without reviewing them against their security baseline is doing the same thing, just faster.

The skill requirement has shifted. We need people who can read generated code critically, who understand architectural patterns deeply enough to spot elegant but wrong choices, and who have the discipline to say “let me verify” instead of “ship it.”

The Context Window Problem as Architecture Constraint

Here is something that few technology leaders discuss publicly but that will define the next wave of enterprise modernization: the context window is an architecture constraint, and a hard one.

There are legacy codebases. Million lines of older languages, like Cobol or Delphi. Built over two decades. It works. It runs critical business processes. And it does not fit into a context window. No frontier model today can ingest that codebase holistically and reason about it as a whole. The model sees fragments. Isolated modules without the web of dependencies that give them meaning.

This led me to what I consider a genuinely new role in enterprise IT: the Context Engineer. This is the person who fragments, indexes, and prepares legacy code so that AI systems can consume it meaningfully. They decide which 40,000 lines of a 300,000-line module matter for a specific modernization task. They build the retrieval layer that feeds right context to the model at the right time.

Your modernization speed is no longer limited primarily by AI capability. It is limited by how well you have organized your legacy knowledge for AI consumption. The Context Engineer determines the modernization velocity. I have not seen this role in any job description yet, but it will be there within two years.

Less Applications, More Agents — The Enterprise Shift

Something equally fundamental is happening on the business application side. For decades, enterprise IT meant buying or building applications — ERP systems, CRM platforms, reporting tools — each a monolith of screens and workflows that humans navigated manually.

What I see emerging is different. Advanced AI systems enable a shift from applications to agents and workflows. Instead of a procurement officer navigating seven screens to approve a purchase order, an AI agent reviews the request against policy, checks budget, flags anomalies, and presents only the decision point. The human still decides. The cognitive overhead is gone.

This means less management overhead. Not because managers are replaced, but because information preparation — collecting data, formatting reports, chasing updates — is increasingly handled by intelligent workflows operating on massive amounts of data. What remains is the core: judgment, decision, accountability.

I see operations, where it was moved three reporting processes from manual Excel assembly to AI-driven data pipelines. The time saving was significant. But the real gain was that our team leads could focus on interpreting data instead of compiling it.

The Psychological Dimension

What concerns me most is not the technology. It will get better. What concerns me is the psychological impact on people who have built their professional identity around skills that are visibly changing.

A senior Delphi developer with twenty years of experience watches a frontier model generate code in a language they do not fully know. A system administrator who spent years mastering infrastructure sees an AI system propose a complete IaC deployment. These moments touch professional identity.

The honest answer is this: the experience of those professionals is more valuable now, not less, but in a different way. Their deep understanding of how systems behave in production, of what breaks at scale, of where business logic hides — this is exactly what models cannot learn from training data alone. The challenge is helping people see that shift as an elevation, not a loss.

So What Changes for People?

Everything and nothing. The tools change. The speed changes. But the fundamental truth remains: someone has to understand what the business needs, someone has to ensure systems are reliable and secure, and someone has to be accountable when things go wrong.

What changes is the shape of the skills. Validation over generation. Architecture thinking over implementation speed. Context engineering over raw coding. Critical reasoning over mechanical execution. And the willingness to learn continuously in an environment where the ground shifts every few months.

After thirty-five years, I still learn something new every week. The learning curve is steeper, the tools more powerful, and the margin for complacency smaller than ever. But the people — the developers, the platform engineers, the security specialists — they remain at the center. Not because it is comforting to say. But because it is true.

The 10x Developer Myth Is Over – And AI Killed It

by

0


Every industry has its mythology. In software development, the most persistent one is the 10x developer. The idea that certain individuals produce ten times the output of an average engineer. That somewhere out there is a person who, given the same problem and the same tools, simply delivers an order of magnitude more than everyone else. I have been in this industry for over thirty years. I have hired hundreds of engineers. I have worked alongside many extraordinary ones. And I want to make an argument that most people are not yet ready to hear: the 10x developer, as a concept and as a hiring strategy, is over.

Was the myth ever real?

To be fair, there was something to it. The original research goes back to a 1968 study by Sackman, Erikson and Grant that found dramatic variance in programming performance across individuals. Later studies confirmed that top performers could indeed outpace average ones by significant multiples on certain tasks. The variance was real. It came from a combination of deep domain knowledge, fast pattern recognition, intimate familiarity with the codebase, and the kind of instinct that only accumulates over years of hard-won experience.

But the myth also generated consequences that were never healthy. Star developer worship. Knowledge hoarding as job security. Teams with a bus factor of one. Engineering cultures where a handful of individuals became irreplaceable and knew it, and occasionally leveraged that position in ways that were damaging to everyone around them. I have seen this pattern destroy more than one team. The 10x developer was real, but the culture built around chasing that individual was often toxic.

The lone genius model of software development is being replaced by something more interesting: distributed capability, amplified by AI.

What AI actually does to the productivity distribution

When I look at data from teams that have genuinely adopted AI coding tools – not as a toy, not as a demo, but as a core part of their daily workflow – the productivity distribution changes in a way that is structurally important. The bottom of the distribution rises significantly. Developers who previously struggled with boilerplate, with unfamiliar frameworks, with the cognitive overhead of context switching, now have a capable assistant closing those gaps in real time.

The top of the distribution also rises, but proportionally less. The senior developer who already moved fast moves faster. But the gap between the senior and the junior – the gap that the 10x myth was built on – narrows considerably. A developer with two years of experience, working with a well-configured AI coding environment and a clear specification, is producing work today that three years ago would have required five years of experience to produce. I have observed this directly, and the numbers are not subtle.

This is the democratization of execution. And it is happening faster than most organizations have internalized.

What still differentiates? The things AI cannot compress.

I want to be precise here, because the argument is sometimes misread as “all developers are now equal.” That is not what I am saying. What I am saying is that the dimensions that previously drove the 10x differential – typing speed, syntax recall, knowledge of obscure APIs, ability to hold large amounts of code in working memory – are being compressed by AI. Those were always somewhat accidental measures of value anyway.

What remains genuinely scarce, and what AI does not currently compress, is judgment. The ability to recognize that the technically correct solution is wrong for this business at this moment. Domain knowledge deep enough to spot when the AI-generated code is plausible but wrong in a way that will only manifest six months later under production conditions. System thinking that understands how a change in one component propagates to parts of the architecture that are not immediately visible. The ability to write a specification that is precise enough to drive correct AI output on the first attempt rather than the fifth.

These are the dimensions that matter now. They are also, interestingly, dimensions that were always present in the best senior developers but were often obscured by the noise of raw execution speed.

Speed of typing versus clarity of thinking. The second is now the bottleneck

So what does this mean for hiring?

It means the interview process most companies still run is measuring the wrong things. Whiteboard coding under time pressure tests a form of performance that is becoming commoditized. LeetCode exercises optimize for pattern recall that AI can now provide on demand. These processes were always a proxy for what we actually wanted – problem solving ability, communication clarity, system intuition. They were proxies because we had no better measurement. We should replace the proxy, not defend it out of habit.

What I would measure instead: How does this candidate think through an ambiguous problem? Can they write a precise specification from an imprecise requirement? How do they evaluate AI-generated output – do they review it thoughtfully, or do they accept it uncritically? How deep is their domain knowledge in the areas that matter for your product? How do they communicate technical decisions to non-technical stakeholders?

These questions do not fit well into a two-hour coding interview. But they predict performance in an AI-assisted development world far better than any algorithm challenge.

And compensation? And team design?

Compensation models built around the 10x mythology created enormous salary variance in engineering. Some of that variance reflected genuine scarcity of specific knowledge. Much of it reflected the leverage that star performers held in organizations that had allowed single-point dependencies to develop. As AI redistributes execution capacity, the leverage shifts. The knowledge hoarder loses power. The system thinker and domain expert gain it.

For team design, the implications are significant. The argument for large engineering headcounts was always partly about raw implementation capacity. If AI increases per-developer output substantially, the optimal team size for a given amount of work changes. But the answer is not simply to run the same team smaller. It is to run a different kind of team. Fewer people doing pure implementation. More people doing specification, review, domain modeling, and AI orchestration. The roles look different. The skills required are different. The management model is different.

Organizations that reduce headcount as their only response to AI productivity gains will discover they have also reduced the judgment capacity they need to direct the AI effectively. The teams that will win are those that redesign around the new bottleneck, which is not implementation anymore.

The end of a mythology, and what replaces it

Mythologies exist for a reason. The 10x developer myth gave organizations a simple mental model for why some teams were dramatically more productive than others. It gave individual developers an aspiration and a career ladder. It gave the industry a way to justify enormous compensation variance. All of these are real needs, and they do not disappear when the myth dissolves.

What replaces it, I think, is something more honest and in some ways more interesting. The most valuable developer in the next five years is not the fastest coder. It is the clearest thinker who also knows how to direct machines. That is a combination of human skills – domain knowledge, communication, judgment, systems thinking – with a new technical competency: the ability to work effectively with AI as a collaborator rather than a tool.

That developer exists in every organization today, often not in the role you would expect. Sometimes it is a domain expert who never wrote much code but now, with AI assistance, is producing remarkably precise and useful software. Sometimes it is the thoughtful mid-level engineer who was always slower than the star performers but whose output had fewer bugs and required less rework. These people are about to become significantly more valuable, and the organizations that recognize this early will build better teams for the next decade.

The 10x developer had a good run. What comes next is more interesting, and more human.

The Next Abstraction Layer: From Procedural to AI-Driven Development

by

0


Since the early days of computing, software development has followed a very consistent pattern: every decade or two, a new paradigm emerges that raises the abstraction level by one significant step. We moved from punch cards to assembler, from assembler to C, from C to object-oriented languages like Java and C++, and then from there to higher-level scripting and systems languages like Python and Rust. Each of these transitions shared the same fundamental characteristic — they allowed developers to think less about how the machine does something, and more about what needs to be done.

Does AI break this pattern, or does it continue it?

In my view, it continues it — but at a scale and speed we have not seen before.

Generated with Google Gemini

When C appeared in the early 1970’s, it was a revolution. Programmers could abstract over registers and memory addresses with structured control flow. With Java and C++ in the 1990’s the next step happened: objects, encapsulation, inheritance. The programmer could now model the world in concepts rather than instructions. A Car object had methods and state. The machine details where moved even further down. Python and its contemporaries took this further, removing memory management entirely and allowing rapid prototyping that would have taken weeks in C to be done in hours.

Each of these epochs shared one common denominator — the developer still wrote every line, still translated intention into instruction, just at a higher level.

This is exactly the step AI is taking now.

The translation from intention to implementation was always the developer’s core job. You had an idea, you had a requirement, and your skill was to bridge that gap in code. LLMs are now beginning to perform this translation automatically. Not perfectly, not without oversight, but in a direction that is unmistakable.

We are moving from imperative thinking — tell the machine step by step what to do — to intentional thinking — tell the system what outcome you want. The shift is profound. It is not about writing less code, it is about changing who writes it and at what level of abstraction humans need to operate.

Is this the end of the developer?

I would argue no, but the role will shift dramatically. The same way the introduction of C did not eliminate hardware engineers, but changed what skills were needed and where the value was created. The developers of the next decade will be architects of intent, not writers of loops. The skill set moves from syntax mastery and algorithmic thinking towards domain expertise, system design, and the ability to validate and guide AI-generated output.

Generated with Google Gemini

From my personal experience leading large engineering teams, I already see this shift in practice. The question is no longer “can you write the code?” but “do you understand the system well enough to judge the code that was generated?” Quality, correctness, security and maintainability remain a human responsibility. The generation part is moving to the machine.

Where are we today?

We are probably in the MS-DOS phase of this transition. The tools are real, the output is impressive, but the workflow, the standards, the guardrails and the enterprise-grade reliability are still being developed. Companies that understand the abstraction shift happening now will be the ones architecting the platforms of the next decade. The others will be the ones migrating legacy prompt-less codebases in 2035.

The lesson from history is clear: abstraction always wins. The only question is how fast you adapt.