From Automating Tasks to Delegating Intent


The next abstraction layer: machines no longer execute only our steps. They begin to execute our intent.*

In various discussions with CIOs and platform teams over the last months, I keep hearing the same concern: we automated almost everything, and still we are drowning in operational work. More pipelines. More scripts. More dashboards. More tickets generated by the systems that were supposed to remove tickets.

How can that be?

Because automation was never the destination. It was the first step of a much longer journey. For more than a decade, we taught machines to repeat what we do. Agentic AI now introduces a different contract: the machine does not only repeat a task. It interprets an objective, decides between possible actions, and adapts when reality does not follow the expected path.

This sounds like a technical evolution. I believe it is mainly a leadership evolution.

Did automation solve the problem?

Automation solved an important class of problems. Infrastructure as Code made environments reproducible. CI/CD removed many manual handovers. Policy engines, secret rotation, autoscaling and observability moved operational work from documents into systems. This was a great achievement.

But traditional automation has a hard boundary. It executes the procedure we already know. A script does exactly what you wrote, at machine speed, including your mistakes. When the environment changes, the exception moves back to a human. When two policies conflict, the workflow stops. When the goal is clear but the path is not, the ticket lands again in the platform team.

We automated the known path and created specialists for everything outside the path. The result is a strange paradox: highly automated organizations can still require enormous coordination. The machine handles the steps, while humans spend their time connecting the steps, interpreting exceptions and deciding what should happen next.

The bottleneck moved. It did not disappear.

What has changed?

Agentic AI raises the abstraction level from task to intent. Instead of saying, “run this pipeline, apply this configuration and restart that node,” we can formulate an outcome: keep this service compliant, keep its cost inside an agreed corridor, and remediate drift before it becomes an incident.

The difference is fundamental. A task describes the how. Intent describes the what and the why, together with the boundaries that must not be crossed.

History offers a useful analogy: mission command. In the nineteenth century, military organizations discovered that detailed orders collapse the moment reality disagrees with the plan. Communication was slow, conditions changed, and the person closest to the situation often had better information than the commander far away. The answer was not less discipline. It was a different form of discipline: communicate a clear objective, define constraints, and allow trained officers to decide the execution on the ground.

You have seen both models in your own career. Micromanagement is task-based. The manager prescribes every step, checks every result and becomes the bottleneck of the team. Leadership is intent-based. The leader defines the objective and the boundaries, then trusts people to find the path.

For a decade we micromanaged our machines. Agentic AI asks us to lead them.

Autonomy without boundaries is not delegation. It is uncontrolled execution.

Where is the catch?

The catch is that delegation only works on a disciplined foundation. An officer without doctrine is not empowered; he is dangerous. The same is true for an autonomous agent operating on enterprise infrastructure.

Three foundations are non-negotiable.

First, the agent needs a declarative source of truth. It must know the desired state, not only the current state. Architecture decisions, service ownership, compliance requirements and operational limits cannot remain distributed across outdated wiki pages and the memory of a few senior engineers.

Second, every action needs identity. An agent should never inherit a broad technical account simply because this is convenient. Human and machine actions must be authenticated, scoped and traceable. If an autonomous system can change production, we need to know which identity acted, against which objective, with which permissions and based on which context.

Third, constraints must become executable. A statement such as “do not create unnecessary risk” is good leadership language but bad machine policy. The boundary has to be explicit: which environments may be changed, which cost threshold applies, which data is sensitive, which action requires approval, and when the agent must stop.

Without these foundations, we are not delegating intent. We are automating chaos at a higher level of abstraction.

Can responsibility be delegated as well?

This is the question I feel most strongly about. Mission command never removed the commander’s accountability. It sharpened it. The officer decides on the ground, but the commander owns the outcome.

The same principle must apply to AI agents. A system can plan, execute, evaluate results and change its approach. It can operate faster and across more information than any individual. But it cannot be responsible. Responsibility is not a workload we can schedule, and accountability is not metadata we attach after an incident.

This also changes the role of platform teams. Their value moves away from processing every operational task and toward designing the environment in which decisions can safely be delegated. They become authors of intent, boundaries and escalation paths. They define the operating model for human and machine actors together.

That is not less engineering. It is engineering one abstraction layer higher.

Where should CIOs start?

Do not start with the agent. Start with the intent.

Most organizations I talk to cannot describe on one page what “good” looks like for their infrastructure. Which risks are acceptable? Which costs are tolerable? Which changes need a human decision? Which business outcome has priority when reliability, speed and cost conflict?

If you cannot express the intent clearly to a colleague, you cannot delegate it to a machine.

My advice to CIOs is simple: treat the next two years as officer training for your platform. Select low-risk operational domains where the outcome is measurable. Write down the objective and the constraints. Give the agent only the identity and authority it needs. Observe every decision. Improve the doctrine before you expand the autonomy.

Do not measure success only by tasks eliminated. Measure how many decisions can be made safely without coordination overhead, how often the system escalates correctly, and whether humans can still explain why an action happened.

The journey from automation to delegation is not primarily about smarter machines. It is about clearer organizations. The quality of the outcome will depend on the quality of the intent, the discipline of the guardrails and the willingness of leaders to remain accountable.

The machine can execute the mission. You remain the commander.

Written by human, curated by AI, pictures by OpenAI

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


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.

People lead the Digital World


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: