Everything in this series so far has been about the system: the ladders, the gates, the semantic layer. This last piece is about the people. When workflows become software, two structures change at once: the shape of the department, and the shape of the work.
Reconfigure your department
For decades, organisations were built around a split. On one side sat the domain experts — for example, the engineers and analysts who understood the problem and task at hand. On the other sat IT, who built and ran the systems. Domain experts provided ideas and specs and waited in a queue for implementation. That division of labour made sense, because building software was hard.
Now it is easy. Agentic coding collapses the split: a domain expert can now orchestrate a virtual IT team for around a hundred dollars a month. The evidence is everywhere — an explosion of ‘vibe-coded’ tools, built not by software departments but by the analysts and engineers who feel the problem most acutely. The question is no longer whether domain experts can build software; they already are. It’s how to use this power.
The value now sits in two places. The first is domain expertise: knowing what matters, what to do with information and data, how to obtain it, what your customers will actually pay for. The second is the platform that lets domain experts act on that knowledge directly and safely — the service layer, the semantic layer, the gates.
This points to a very different org chart. The domain experts become the agent orchestrators — the software engineers of the future. They have the vision and they no longer need an IT department to implement it for them. The thing they need is a platform that makes their orchestration safe and cheap.
So IT needs to ‘let go’ of software development. But organisations must be aware of the dark side of letting go — tools nobody can maintain, security holes, quality problems and a hard dependency on whichever individual built the thing. Chaos ensues.
IT’s new role should be enabling this transition of power — helping domain experts solve their own problems. IT’s new role is in the service layer: the bullet-proofed, thoroughly tested corporate tools that expose the organisation’s information assets to the experts and agents that consume them — database reads and writes, external APIs, document parsing, quality control, UI patterns, auditing and error logging. Build a discipline once, as a service, and every tool in the organisation inherits it for free. IT stops being the department that builds the solutions and becomes the department that makes solutions buildable — custodians of the rails, not drivers of the train.
Trust is the new bottleneck
The bottleneck has moved from “can we build it” to “should we trust it.”
LLMs are confidently wrong; everyone has learned that. Ask for a project’s delivery date or a specification of some machinery and you will get an extremely convincing answer. The effort moves from producing the answer to checking the answer, and that verification is now the bulk of the work, especially if you wish to constrain costs. If verification is not an explicit part of your workflow, you have a quality issue you haven’t found yet.
Guardrail provision is the role of the IT department — designed-in cross-checks, a deterministic gate behind that, and feeding the human layer to inspect outliers and sore thumbs.
Skills first, then determinism
So how do you actually start codifying a workflow? You can dive straight in, of course, with ReAct loops, MCPs, decision-making criteria and so on. For me it made more sense to follow a gradual codification process:
Step 1: verbalise the workflows with a generic agent like Claude. Walk through them step by step, implementing them, before finally wrapping up as a ‘skill’ — a structured instruction set the agent follows with a human in the loop.
This is deliberately cheap. You are not building software yet; you are capturing the process, with all its checks and judgement calls, to inform the next steps.
Step 2: run the skills with an audit log of all issues that arise (building feedback loops). The agent will also misbehave and skip steps, improvise, navigate failures with soft landings. Record all this. Review each run, or ask your agent to.
Step 3: identify the component steps that can be made deterministic. Push them down the ladder into code, test them and forget them. For more complex flows, break them down into deterministic and non-deterministic sections that need reasoning. See if you can redefine judgements as rules in the service layer — the service gets a test and a gate. Keep pushing for determinism until you are left with the genuinely judgement-bearing steps.
Step 4: now you have factored out the deterministic steps, bring in the agentic flow. There is still scope for centralisation of logic in the service layer, so push everything there. Make generic tools for other agents to use. Keep logs, review logs, tighten the ratchet.
Skills rot too
A warning from hard experience: skills rot as the context grows.
A skill that runs well in a fresh context becomes unreliable the more you run it. I tried running skills in loops in the same context. The agent quickly starts shaving the edges off, skimming its own instructions — it starts following patterns it has discovered during the workflow. Eventually it will skip to the end, merging everything into one step and declare victory! Unless you check, you won’t find out until it’s too late. Caps Lock, exclamation marks, extreme frustration and anger achieve nothing.
Two defences. First, push as much of the skill as you can into code, deterministic or otherwise. Second, reset early: treat context as a consumable that degrades with use, and start a new session at the very earliest opportunity — not because of the limited context but because of the ‘learned shortcuts’. Skills can be launched programmatically in the cloud but it will cost you, hence I ran as many terminals as I could locally under the subscription model.
My 217-day setup, and what I would do differently
For the curious: the actual rig. Windows + VS Code + Claude Code Max 20 + OpenAI + 17 online service providers. I stripped out most plugins to reduce memory, my biggest constraint.
I never made git worktrees stick — the coding agent would end up in the wrong worktree. Instead I ran parallel sessions on different parts of the repo, where a shallow architecture helped reduce collisions.
What I would change: go Linux. Windows fought me — out-of-memory issues and tooling friction. Claude Code assumes Linux/Mac by default, probably due to its training, which meant it was often hunting for syntax fixes on the CLI. I run Linux for a separate project and that is easy.
But the rig barely matters. The leverage is in engineering the rails: a good service layer, a semantic spine and gates that hold. This is the real setup that replaces the productivity of a department and frees people to drive creativity and innovation.
Conclusion
Technology is the easy half. Structural change will be the hard leap for established organisations: domain experts at the surface, experimenting, building and verifying with judgement, and curating and maintaining the semantic layer. IT sits underneath, owning the services and the guardrails that make the whole system trustworthy.
The good news is you don’t have to take a full leap of faith — it can be done in chunks. But if you don’t act, you will be replaced, possibly very quickly.