AI Tools Got Better. Your Workflow Didn’t.

AI tooling got dramatically better from late 2025 into early 2026. Agentic IDEs, CLI agents, desktop assistants — the power is real. But one lesson keeps proving itself: great tools don’t fix workflows built for a different socio-technical system.

Starship Command Center, Steamship Coal Chamber

Some days feel like running a starship command center. You orchestrate multiple AI agents across repositories, delegate code generation, let models reason about architecture. Strategic planning, high-level orchestration, global intent — the future of engineering, right there on your screen.

Then you open a pull request.

AI Engineering vs. Traditional Code Management

Suddenly you’re in the coal chamber. Manual resolution of merge conflicts that no model can „reason away.“ Deep dives into diffs that require the full context of why a change was made, not just what changed. PR approvals that demand human judgment about boundaries, risk, and intent. Edge cases handled by hand because no agent understands the organizational politics behind a naming convention.

The contrast isn’t funny — it’s diagnostic. The starship part runs on new infrastructure. The coal chamber part runs on workflows designed before any of these tools existed.

The Workflow Is the Bottleneck, Not the Tool

The instinct is to keep upgrading tools. Better models, better agents, better IDE integration. But the friction isn’t in the tool — it’s in the process the tool plugs into.

GitHub’s pull request model was designed for humans reviewing humans. It assumes one author, one reviewer, sequential context. When an AI agent produces 15 PRs in parallel across 4 repositories, the review model doesn’t scale — not because the reviewer is slow, but because the workflow assumes a pace and a context-loading model that no longer matches reality.

Merge conflicts are the same story. They’re not a model limitation — they’re an artifact of a branching strategy designed for human typing speed. When agents generate code faster than humans can integrate it, the branching model becomes the bottleneck.

This is what „socio-technical system“ means in practice: the tools, the processes, and the human roles evolved together. Change one without changing the others, and the system resists. The resistance shows up as friction — and friction is where redesigning workflows for AI-augmented engineering becomes the actual work, not just adopting better tools.

Models Execute Slices. Humans Own the Whole.

AI agents are excellent at executing defined slices of work. Generate this function. Refactor this module. Write this test. Within a bounded context, they’re fast and often good enough.

But integration — the act of combining slices into a coherent whole — remains a human responsibility. Not because models can’t reason about integration, but because integration decisions carry organizational weight. Which PR lands first? Which breaking change is acceptable this sprint? Which test failure is a real bug versus a flaky assertion?

These aren’t technical questions. They’re judgment calls that depend on context no model has: team agreements, release timelines, customer commitments, political dynamics. The human doesn’t own integration because the model is too dumb. The human owns integration because accountability can’t be delegated to a stochastic system.

What Workflow Design Actually Means Here

„Fix the workflow“ sounds obvious. In practice, it means questioning assumptions that feel like laws of nature:

Does every change need a PR? If an AI agent makes a one-line config fix that passes CI, maybe a post-merge review is enough. The PR ceremony exists to catch human errors in human-authored code. The error model changed — the ceremony should too.

Does branching need to be this complex? If agents produce work faster than it can be merged, maybe trunk-based development with feature flags is less friction than gitflow with long-lived branches. The branching model was optimized for human coordination speed.

Does code review mean reading diffs? When the author is an AI, the reviewer’s job shifts from „is this code correct“ to „does this change serve the intent.“ That’s a different skill, and it needs different tooling — summaries, impact analysis, behavioral diffs rather than line-by-line inspection.

None of these are radical ideas. They’re workflow adaptations that the tooling shift demands but that organizational inertia resists. The tools moved. The processes didn’t. The gap is where the coal shoveling lives.

Tooling Matters. Workflow Design Matters More.

The temptation is to keep investing in better tools and assume the workflow will catch up. It won’t. Workflows are social contracts with technical implementations. They change through deliberate redesign, not through osmosis from better tooling.

The starship command center is real. So is the coal chamber. The difference between organizations that get value from AI tooling and those that just get faster chaos is whether they redesign the workflow — or just upgrade the tools inside the old one.

Boris Heuer

Boris Heuer
AI Engineer & Consultant

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top