Category Archives: People

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 Rewiring: How Advanced AI Systems Are Reshaping the Fabric of Enterprise IT

by

0


Over the last three years, something fundamental has shifted beneath the surface of enterprise technology. It did not arrive with a press release or a migration deadline. It came through the daily work of developers, platform engineers, and IT specialists who started to notice that their tools had become collaborators. After thirty-five years in this industry, from mainframes through client-server, from virtualization through cloud-native, I can say with some confidence: this shift is different. Not because the technology is louder, but because it is quieter and deeper than anything before.

From Writing Code to Owning the Lifecycle

For decades, the developer’s identity was built around writing code. Good code. Clean code. Clever code. But the role has been expanding for a while now, and large frontier models have accelerated that expansion dramatically. Today, a developer who only writes code is already behind. The expectation has moved toward lifecycle ownership — from initial design through deployment, observability, and incident response.

I remember when we introduced CI/CD pipelines in our organization around 2015. It took almost two years before the development teams truly owned them. Now, advanced coding systems from major AI labs generate not just the application logic but also the pipeline definitions, the infrastructure-as-code templates, and the test scaffolding. The developer’s job is no longer to produce all of this. It is to understand, validate, and take responsibility for it.

This is a cultural shift, not a tooling upgrade. And it puts enormous learning pressure on people who were already stretched thin.

AI as a Reasoning Partner, Not a Magic Box

State-of-the-art foundation models today can refactor legacy code, generate comprehensive test suites, produce documentation that is actually readable, and suggest architectural patterns that would have taken a senior engineer hours to draft. I have seen this firsthand — a platform team in one of my previous engagements reduced their infrastructure documentation backlog by seventy percent in three months, using new generation reasoning systems as their drafting partner.

But here is the part that gets lost in the excitement: these systems do not understand your business context. They do not know why that particular microservice has a strange retry logic that was added after a production incident in 2019. They do not carry the institutional memory. The risk of over-reliance is real and already visible. I have reviewed pull requests where the generated code was syntactically perfect and architecturally wrong. The skill that matters now is not prompting. It is critical reasoning, validation, and the ability to say “this looks correct but it is not right for us.”

AI amplifies capability. It does not replace responsibility.

Prompt Engineering Dies — System Design Lives

There was a brief period, maybe eighteen months, where everyone talked about prompt engineering as if it were a new discipline. People wrote courses about it, built careers around it. I was skeptical then, and the trajectory has proven that skepticism right. The single-prompt optimization is becoming irrelevant at a speed that should concern anyone who invested heavily in that narrow skill.

What replaces it is far more interesting and far more demanding. Multi-agent orchestration, workflow design, memory architectures, context management across complex reasoning chains — this is system design, not prompt crafting. The prompt engineer is becoming the AI system architect, and that requires a fundamentally different skillset. You need to understand how state flows through distributed reasoning processes, how to design fallback strategies when one agent produces unreliable output, and how to build guardrails that are structural rather than textual.

In my own work, I have moved from asking “how do I phrase this better” to asking “how do I design this workflow so that the output is reliable regardless of how each individual step performs.” That is an engineering mindset, not a linguistics exercise.

The Enterprise Beyond Applications

Something else is happening in the enterprise that deserves attention. The traditional model of building or buying applications for every business function is dissolving. In its place, AI agents and intelligent workflows are emerging — , Software Development Lifecycleot as fancy automation scripts, but as genuine decision-support systems that operate on massive amounts of data that no human team could process manually.

I spent years in organizations where middle management existed primarily to aggregate information from below and pass summarized decisions upward. Large frontier models are compressing that chain. Not by eliminating people, but by removing the friction of information synthesis. A security operations team that used to spend four hours triaging alerts before making a decision can now have an AI agent pre-analyze, correlate, and present a recommended action path within minutes. The human still decides. But the human decides faster and with better data.

Less management overhead. More focus on the core of the task at hand. This is not a slogan — it is what I am observing in real organizations right now.

The Psychological Weight of Constant Adaptation

What I do not see discussed enough is the psychological impact on the people living through this transformation. Every six months, the capabilities of advanced reasoning systems take another leap. Every six months, the baseline expectation for what a single engineer should be able to deliver shifts upward. This is exhausting. I know because I feel it myself, and I have been adapting to technology shifts for three and a half decades.

The pressure to continuously learn, to re-evaluate what you thought was a stable skill, to accept that your hard-won expertise in a specific area might be commoditized within a year — this is not trivial. Organizations that ignore this human dimension while chasing productivity gains from AI will find themselves with burned-out teams and high attrition. The technology is only as good as the people who guide it, and those people need support, time, and psychological safety to adapt.

So What Changes for People?

Everything and nothing. The fundamental truth of enterprise IT remains: humans build systems for other humans, and someone must be accountable when things go wrong. What changes is the layer between intention and execution. That layer is now filled with powerful reasoning systems that can draft, suggest, generate, and analyze at a scale we never had before.

For developers, the path forward is clear: become the person who understands why, not just how. For platform engineers, it means designing systems where AI agents and human operators work in well-defined boundaries. For security engineers, it means building Zero Trust not just for networks but for AI-generated outputs. And for IT leaders, it means accepting that the most important investment right now is not in technology. It is in the people who must learn to work alongside it.

After thirty-five years, I have learned that technology always promises more than it delivers in the short term, and delivers more than we imagined in the long term. The frontier models we see today are no exception. But the transition — the human transition — that is where the real work happens. And that work is happening right now, in every team, in every organization, whether we acknowledge it or not.

The Specification Is the Product Now — And Your Developers Better Know It

by

0


How we ended up here

Over the last three years, something has shifted in enterprise IT that I did not fully anticipate, even after thirty-five years in this industry. The tools we use to build software have not just improved — they have fundamentally changed what it means to be a developer, an architect, or a platform engineer. Large frontier models from major AI laboratories have moved from impressive demonstrations to daily production instruments. And with that shift, the center of gravity in software development is moving from code to specification.

From Writing Code to Owning the Lifecycle

When I started in this business, a good developer was someone who could write tight, efficient code. Over the decades, the role expanded — version control, testing, deployment, monitoring. DevOps made developers responsible for the full lifecycle. CI/CD pipelines, Infrastructure as Code, observability — all of this became part of what a software professional must understand.

Now another expansion is happening. Advanced coding systems from major AI labs can generate, refactor, test, and document code at a speed and consistency that no human can match on pure throughput. I have seen this in my own teams. A task that took a senior developer two days — writing integration tests for a legacy API — was drafted in twenty minutes by a reasoning system, reviewed and adjusted by the developer in another hour.

The developer did not become unnecessary. The developer became the person who decided what the tests should validate, how edge cases map to business logic, and whether the generated output was actually correct. The skill shifted from typing to thinking.

Specification-Driven Development: The Real Asset Is Not the Code

This is where something genuinely new is emerging. If state-of-the-art foundation models can produce working code from well-written instructions, then the quality of those instructions becomes the competitive advantage. Not the code. The specification.

I have started calling this Specification-Driven Development, and I am not alone. Methodologies like BMAD and OpenSpec are formalizing what many of us felt intuitively: the person who writes the best specification wins. Not the person who types the fastest. Not the person who memorizes the most framework APIs.

In my own practice, I have seen projects where a precise, well-structured specification document — describing behavior, constraints, interfaces, error handling, and security boundaries — produced better results through AI-assisted generation than a team of four developers working from a vague user story. The specification became the actual product asset. The code became a derivative. Reproducible, replaceable, regeneratable.

This is a profound change in how we must think about software ownership. Configuration management, version control, review processes — all of these must now apply to specifications with the same rigor we applied to source code for decades.

The Risk of Letting the Machine Think for You

I would be dishonest if I did not address the danger. Over-reliance on new generation reasoning systems is real and I have witnessed it. Junior developers accepting generated code without understanding what it does. Architects letting AI propose system boundaries without questioning whether the decomposition fits the organizational reality. Security engineers trusting AI-generated policies without tracing them back to actual threat models.

AI amplifies capability. It does not replace responsibility. Every generated artifact needs a human who understands why it exists, what it should do, and what happens when it fails. The moment we lose that, we do not have automation — we have negligence with extra steps.

The skill requirements are shifting hard toward validation, architectural reasoning, and critical thinking. These are not new skills. They are the skills we always said mattered most but rarely prioritized in hiring because we were too busy looking for people who knew specific frameworks.

AI Agents in the Enterprise: Less Applications, More Workflows

Beyond development, the transformation is reshaping how enterprises operate at every level. In my current environment, I see a clear pattern: traditional applications are being decomposed into AI-driven agent workflows. Instead of a monolithic reporting tool, we now have intelligent agents that collect data across systems, apply contextual reasoning, and surface decisions — not dashboards.

The result is less management overhead and more focus on the actual core of the task. A procurement specialist no longer spends hours consolidating supplier data from three systems. An agent does that. The specialist spends time on negotiation strategy, relationship assessment, risk evaluation — the things that require human judgment and experience.

Better decisions through data is not a new promise. What is new is that the massive amount of data enterprises sit on can now actually be processed contextually by frontier models, not just aggregated into charts that nobody reads. The data becomes actionable because the reasoning layer between raw information and human decision has become genuinely capable.

I have seen this reduce decision latency in operational contexts by days. Not because people were slow before, but because the data preparation work that preceded every decision was slow. That bottleneck is dissolving.

The Psychological Weight of Constant Adaptation

What I do not see discussed enough is the pressure this puts on people. Every six months, the capabilities of these systems leap forward. What was impossible last year is routine today. For a forty-year-old platform engineer who spent a decade mastering Kubernetes and Terraform, being told that the next generation of infrastructure management might look entirely different is not exciting. It is exhausting.

I feel this myself. After thirty-five years, I still spend evenings reading, testing, adjusting my mental models. Not because I enjoy the pressure, but because the alternative — becoming irrelevant — is worse. And I say this as someone who genuinely finds this technology fascinating. For colleagues who are less enthusiastic about constant change, the psychological burden is real.

Organizations that do not acknowledge this — that simply announce the next AI initiative without investing in their people’s learning capacity and emotional resilience — will lose their best engineers. Not to competitors. To burnout.

So What Changes for People?

The honest answer is: almost everything about the daily work, but nothing about what makes a good professional. Critical thinking, accountability, the ability to translate business needs into precise technical requirements — these have always been the core. They just were hidden behind the noise of implementation details.

What changes is that the implementation layer is increasingly handled by advanced AI systems. The human role moves upstream — to specification, validation, architectural decision-making, and ethical judgment. Developers become specification authors and quality gatekeepers. Platform engineers become orchestrators of AI-augmented infrastructure. Security engineers become the last line of reasoning before automated systems act on sensitive boundaries.

The code is becoming a byproduct. The specification is becoming the asset. And the people who understand this shift — who invest in learning how to instruct, constrain, and validate machine-generated output — will define the next era of enterprise technology. Not the machines alone. Never the machines alone.

People lead the Digital World

by

0


In the recent years more and more discussions have been arisen around Internet of Things and the professional version Industry 4.0. Mainly it is a consequent step from the cloud approach the IT Industry currently pushing and before that the first iteration which was called ASP(Application Service Provider).Funny enough all these concepts and implementations are sold under the umbrella of more efficiency and productivity of men or women.

Does this really lead to more productivity ?

Chillyd49b949f2dIt depends… There is not true answer and time will tell. Based on various studies the productivity is real existing, but was consumed by the more complex integration of the digital world. Have the early digital assistants like electronic mail, the Internet and electronic calendar, u.o. led to more productivity of individuals. The recent adding of more and more decisions on „not experts“ led to less productivity at all. Was in the late 90’s an admin which organized many parts of the business, now more and more high paid employees are doing this by themselves. Of course there are a lot of supporting tools. However it is obvious that experts are much better handling the right processes, individuals can du this when more seldom are they do that.

Companies add more software to improve, means optimize the cost further, to support this evolution, but end of the day the often individuals take more time to get the process done with they think have the best benefit from. This leads in less productivity. Maybe not for the company, since a lot of this are taken by extra hours, prior the digital revolution, it was called privat time. Always on and Always available means less productive for the individual.

How about the society ?

Evolution requires education, revolution requires new thinking and more education as well as new processes and procedures. With the current pace IT and the other business change the models many peo- ple could not keep up, so they where often lost and productivity is going down. Does it matter. Yes ! We have to start to justify the productivity no more on one or a group of individuals, more on the impact in economics. Only this way we can inno- vate further.

Evolution or revolution ?

If enough people adopt to a total new change, we speak from a revolution. Evolu- tion happens every day and is a constant we see since the the early days of mankind. My opinion is that a revolution in society can be good if this is than taken with the majority of people and nobody is left behind by purpose. This is a tricky process. However in the past the revolution and evolution where centered around man kind. In the younger history more and more voices you will hear that talk about a revolution in robotics and artificial intelligence. This will lead that mankind will no longer sit in the driver seat, maybe some minor believe that they can control that revolution.

 

Do we than need still humanity

The question more would follow the „Why“. Algorithm can do things without „error“, robots can work day and night. This will lead for the ultimative questions, for whom? If more and more humans are replaced by smart machines or algorithms, what will than happen with humanity? There is a simple answer from the history they will not survive, maybe some in the first iteration, but end state is with out mankind.Tomatoes Dream

Productivity around humans

Taken this thought, it will take you to the ultima ratio that we have to focus on the man and woman, child and parents, old and young as the center and pole to drive productivity gains. All efforts have to bing the productivity to increase the personal life of people not replace them in the first place. To make this quite right, there will be some duties, work or other stuff which will benefit from removing humans out of the center. the goal seams to me to upskill the starting with the children for a better productivity paired with the skills mankind has to offer as complement.

 

See also

Machines Can`t Flow:

Race Against The Machine: