From Steering Committees to Steering Code

Introduction

Some principles of good leadership do not change, whether you are leading a team of people or a set of AI agents: Define the strategic direction, establish a clear framework, trust but verify, and focus your own energy on steering outcomes rather than executing tasks. I have spent over two decades doing exactly this across large-scale transformation programs in financial services and mobility. What I did not anticipate was seeing those principles work while building software with coding agents.

This article describes my experience working with Claude Code: how I started, what I learned, and why the required mental shift is less about technical skills and more about structured thinking and a willingness to mostly trust a capable system. It is written for senior IT managers and decision-makers who are evaluating how AI-assisted development can realistically be adopted within their organizations — and what it takes to make that adoption effective.

Although I only have experience with Claude Code, other LLMs like OpenAI Codex and Google Gemini CLI are probably equally capable in most cases.

Starting Point: A Non-Developer Building Software

My background is in program management, customer operations, and digital transformation. I have been accountable for large technology portfolios — overseeing Oracle, SAP, and Genesys implementations, managing multi-million-euro budgets, and steering cross-functional delivery teams. I understand software. However, I have always sat on the business side of the table.

When I began working with Claude Code, I was clear-eyed about the risk. The standard warnings were top of mind: AI systems hallucinate. Prompts must be precise. Outputs must be verified. These are legitimate concerns, and they shaped my initial approach — though not always in a productive direction.

Phase 1: The Over-Specification Trap

I started working with Claude Code for a private project. My first instinct was to compensate for the perceived risk of AI output by providing exhaustive input. I described screens in granular detail. I specified field labels, validation logic, layout structures, and interaction flows before a single line of code was written. The underlying assumption was that more control over the input would mean more predictable output.

The results were functional, but the process was inefficient. Writing detailed UI specifications is time-consuming under any circumstances. The critical insight came when I asked a simple question: how many input forms, data screens, and application interfaces has Claude been trained on? The answer is: millions, at least. I don’t need to tell the model what a search filter looks like, or how pagination behaves, or what the validation message for a date field is. The AI already knows.

Phase 2: Stepping Back and Trusting the Model

I tested a different approach: providing only a high-level description of what I needed, without prescribing implementation details. The outcome was significantly better — not just in the code produced, but in the functionality delivered. Claude surfaced design considerations I had not specified, handled edge cases I had not thought to raise, and produced mostly coherent, well-structured interfaces.

I say “mostly” because, like all LLMs, Claude Code forgets nearly everything and barely learns from its work for me. Which is why it sometimes uses checkboxes and sometimes it puts a switch button there. Having a style guide in the project helps, though not always.

Does the model actually learn from my project?

No. The model is stateless: it remembers nothing between sessions and does not improve on your codebase over time. Consistency does not come from memory — it comes from what you put back into its context and from the standards it is told to follow.

This is a meaningful finding for organisations thinking about how to deploy AI-assisted development. The productivity gain from Claude Code is not just about typing less code. It is also about the AI tool’s capacity to contribute substantively to design decisions when given the freedom to do so. Constraining that capacity through over-specification actively reduces the tool’s value.

Phase 3: Introducing a Multi-Agent Architecture

The next evolution was structural. Rather than using Claude Code as a single generalist tool, I introduced a multi-subagent setup with dedicated subagents for analysis, test design, quality assurance, and coding. Each agent operates within a defined scope and contributes to a coherent delivery pipeline.

What is a subagent?

A narrower brief on top of the same product: its own context window, a defined scope, and a set of rules — all configured in a plain markdown file. By default it shares the main session’s model, but you can assign a different one per type — a smaller, faster model for narrow tasks, a stronger one for hard ones. The specialisation lives in the instructions, not in a separate “frontend” or “backend” engine.

Under the hood, subagents use the same LLM because there is no dedicated “front-end LLM” or a “back-end one”. They are simple markdown files. Still, subagents produce better code faster in my experience: they have their own context window, run in parallel, are better at sticking to their rules and reviewing each other’s code, and recently started to memorize things all by themselves.

So can subagents actually learn now?

Not in the machine-learning sense — the model’s weights never change. What is new is auto memory: an agent, including a subagent, can write notes to a markdown file and reload them at the start of the next session. That is persistence and retrieval, not learning — and the notes are plain text you can read, edit or delete.

This mirrors human software teams: specialists working within clear boundaries, with defined handoffs and quality gates, consistently outperform generalists working in isolation. The same logic applies here. Assigning a dedicated quality agent to review outputs before they are accepted, for instance, introduced a level of systematic rigor that materially improved the consistency of results.

For organizations evaluating how to structure AI-assisted development, this is a key design decision. The architecture of your agent setup functions like an operating model: it determines how work flows, where accountability sits, and how quality is assured.

Phase 4: Custom Skills — Encoding Institutional Knowledge

Setting up agents defines who does what. The next step is defining how they do it — and this is where custom skills become a critical part of the framework.

Custom skills are reusable, predefined instructions that tell Claude how to approach specific tasks: a style guide for your codebase, a standard for structuring user stories, a template for writing tests, or a workflow for moving a feature from epic to deployment. Think of them as your organization’s playbook, made available to every agent, every time.

What is a custom skill?

A reusable instruction — a playbook for one kind of task, written once and stored with the project. Every agent picks it up automatically, so a standard is applied the same way each time instead of being re-decided on the spot.

The practical impact across four dimensions is significant:

Workflow automation. Repetitive decision points — how to handle validation, how to structure API responses, how to name components — are resolved once, encoded in a skill, and applied consistently from that point forward. The agents stop re-inventing and start executing.

Standardisation. The consistency problem I described in Phase 2 — checkboxes in one screen, toggle switches in another — becomes manageable when design and coding standards are embedded in the working environment rather than left to the model’s best judgment on any given day.

Predictable outcomes. When agents work within a defined skill framework, the range of possible outputs narrows. You get more of what you expect, with less correction overhead and fewer surprises in review.

Team ramp-up and onboarding. This is perhaps the most underappreciated benefit. A new developer or BA joining an AI-assisted project can make a productive contribution significantly faster when the standards, patterns, and workflows are already codified and accessible. The skills carry the institutional knowledge; the person does not have to reconstruct it from scratch. What previously took weeks of shadowing and tribal knowledge transfer can be compressed substantially.

In organizational terms, building and maintaining a library of custom skills is not primarily a technical task — it is a knowledge management task. It requires people who understand both the business requirements and the delivery standards well enough to articulate them precisely. That is, in most cases, exactly what experienced BAs and senior developers already do well.

Custom skills also change the economics of scaling. Once a skill is built, it costs nothing to apply. Every new project that inherits your skill library starts from a higher baseline than the one before.

Phase 5: Epic-Driven Development

With confidence in the model’s capabilities, a multi-agent structure, and a set of custom skills established, I took a final, more significant step back. Rather than providing user stories or detailed functional requirements, I began working at the epic level: providing a high-level statement of business intent and allowing Claude to decompose it into user stories, define acceptance criteria, and proceed with development.

The output of this approach has been strong. The decomposition logic is sound. The user stories produced are well-formed and traceable to the originating intent. The development output aligns with what the stories specify. My role shifted from specifying requirements to reviewing, steering and validating — which is precisely where a senior leader’s time should be spent.

In practice, I now operate with what amounts to a full delivery team: a business analyst decomposing requirements, different developers building to specification, a tester validating outputs, and various quality reviewers ensuring consistency. The difference is that this team operates at a speed and cost structure that would not be achievable through conventional resourcing.

The Human Layer: Why Oversight Remains Non-Negotiable

None of the above should be read as an argument for unqualified trust. AI models make mistakes — and Claude Code is no exception. Code can be syntactically correct but logically flawed. A user story decomposition can be structurally sound but miss a critical business rule. An agent can produce output that is internally consistent but misaligned with the broader system architecture. These are not edge cases; they are predictable failure modes that any serious deployment must account for.

This is precisely why the human layer is not optional. The shift I described — from over-specifying inputs to directing at the epic level — only works when paired with rigorous review at every stage. Skilled developers and business analysts remain essential, not as producers of first-draft output, but as the critical quality gate through which AI-generated work must pass.

In practice, this means that the people reviewing Claude’s output need to be more capable, not less. A developer who cannot read and critically assess the generated code cannot work effectively in this model. A BA who cannot distinguish a well-formed user story from a plausible-looking but incomplete one will not catch the gaps that matter. The bar for human judgement goes up, even as the volume of human-generated output goes down.

There is also a directional risk to manage. Individual outputs can be individually acceptable while the overall development trajectory drifts from the intended architecture or business objective. Catching this requires someone with enough context and seniority to evaluate not just whether a given piece of work is correct, but whether the programme as a whole is moving in the right direction. That is a strong steering role — and it cannot be delegated to an agent.

The analogy to team leadership holds here too. A high-performing team still requires active management. Delegation does not mean abdication. The most effective use of Claude Code is one in which experienced professionals set direction, continuously validate the quality of the output, and intervene decisively when the work goes off course.

What about governance and data protection?

In regulated settings the open question is not capability but control: where code and data are processed, what an agent may access, and how decisions stay auditable. None of this is solved by the tool — it belongs in the operating model, alongside the human review gates described above.

Key Lessons for IT Leaders and Decision-Makers

Based on this journey, I would draw out six practical lessons for senior IT managers considering how to integrate Claude Code into their delivery capability:

1. Resist the over-specification instinct. The model carries substantial embedded knowledge about software design patterns. Detailed input constraints often reduce rather than improve output quality. Provide clear intent and context; trust the model to handle implementation.
2. Invest in your agent architecture. The framework you establish — how agents are scoped, how handoffs work, where quality gates sit — is a design decision with significant downstream impact. Treat it with the same seriousness as any operating model design.
3. Build and maintain a custom skills library. Custom skills are how your standards, workflows and institutional knowledge become part of the system — not just documented somewhere. A well-maintained skills library accelerates every subsequent project and dramatically shortens onboarding time for new team members.
4. Work at the right level of abstraction. For experienced business and IT professionals, the highest-value contribution is strategic framing and outcome validation — not task specification. Epic-level direction, combined with structured review, is a more effective way to engage with the tool.
5. Good leadership transfers directly. The skills that make an effective program director — clear direction-setting, structured delegation, rigorous outcome review, and the confidence to trust a capable team — mostly apply without modification to leading an AI-assisted delivery team.
6. Human oversight is a design requirement, not a safety net. AI makes mistakes. Skilled developers and BAs must be embedded in the process as active reviewers — validating output quality, catching logical errors, and ensuring the overall development trajectory remains aligned with business intent. The quality of human oversight determines the quality of the final product.

Implications for Business Analysts and Developers

The impact of this shift is not limited to senior leadership. For business analysts and developers, working effectively with Claude Code requires recalibrating established habits.

Conclusion

AI-assisted development with tools like Claude Code is not a future capability. It is available now and producing real results. The primary barrier to adoption in most organizations is not technical — it is the lack of a structured approach to using the tool effectively.

My experience suggests that the transition is achievable for professionals without a development background, provided they bring structured thinking, a willingness to iterate, and the discipline to establish a solid working framework before scaling output. For organizations with experienced IT and BA teams, the learning curve is shorter still — the skills are already there. They need to be applied in a new context.

The model does the heavy lifting. Your job is to set the direction, establish the framework, and steer the outcomes. That is, in the end, what good leadership has always looked like.

---

Building this capability across a team is its own discipline. We help organisations adopt AI-assisted development effectively — from a one-hour impulse for leadership teams to hands-on training for business analysts and developers. An overview of our formats is on our AI solutions page.