Team Enablement for Agentic Software Development
I take engineering teams from Level 1 to Level 4 — and close to Level 5. Verified instead of trusted.
Almost every engineering team has AI licenses by now — and most still get stuck at Level 1 or 2: autocomplete in the editor, code snippets from a chat window. The real productivity jump only starts above that, when agents take on entire tasks and features. And it doesn't come from yet another tool, but from changed ways of working and the right verification infrastructure.
That is exactly what my enablement is: I guide your team from AI assistance to agentic software development — from Level 1 to Level 4 and, where it is defensible, close to Level 5. Not as off-the-shelf training, but as work on your real codebase, your pipelines, and your reviews.
The path: from Level 1 to Level 4 — and close to 5
My AI Coding Levels model serves as the shared language — five stages from autocomplete to autonomous agent teams. For enablement, what matters most is where your team stands today and which jump comes next. This is what the path typically looks like:
Where most teams start
Autocomplete and chat assistance: AI speeds up typing and research, but every line passes through human hands. This stage is about fundamentals — working cleanly with context, first agentic single tasks in the repository, and a test suite you can trust.
The critical jump
Agents implement entire features spec-driven; humans define contracts and review results instead of every step. This jump rarely fails because of the model — it fails on missing infrastructure: prompt contracts, verification loops, hooks and guard-rails in CI/CD. That is exactly what we build together.
Agent teams with human oversight
Multiple agents plan, implement, and verify in parallel; the team sets goals and owns the results. How far a team can responsibly go here depends on domain, risk, and governance — the goal is not maximum autonomy, but the highest level that remains verifiable.
What we work on
Agentic workflows in daily practice
Plan mode, delegating tasks to agents, working with context and skills: the habits that turn one-off prompts into reproducible development workflows.
Verification infrastructure
Prompt contracts that make expectations machine-checkable; verification loops that validate agent output against the spec; hooks and guard-rails in CI/CD that stop misbehavior before it reaches production.
Spec-driven development
From requirement to machine-readable specification: how teams phrase tasks so agents can implement them reliably — and reviews run against the spec instead of gut feeling.
Review culture & changing roles
When agents write code, the work shifts: from typing lines to specifying, verifying, and owning outcomes. How reviews, pairing, and the growth of junior developers work in an AI-native team.
Governance & the EU AI Act
Traceability, auditability, cost control: which guard-rails agentic development needs in an enterprise context — and how to anchor them in an EU-AI-Act-compliant way.
Working together — deliberately no standard program
There is deliberately no package with fixed weeks and modules here. Every team starts from a different place — different stack, different maturity, different risks. So it begins with a first conversation and an honest assessment: where does your team stand in the Levels model, what slows it down, and what is the next defensible jump?
From that, a tailored path emerges — hands-on, along your real codebase and your pipeline, not on toy examples. Formats like workshops, in-team pairing, and building the verification infrastructure are combined to fit the team and the goal.
From lived practice, not from slides
I don't teach theory I don't apply myself: my own development work runs at Level 5 — I set goals, agent teams deliver, secured by the same prompt contracts, verification loops, and guard-rails your team adopts during the enablement.
Add to that ten-plus years of software architecture and experience as a tech lead and mentor. For me, enablement doesn't mean showing tooling — it means changing engineering practice without sacrificing quality.
Frequently Asked Questions about Team Enablement
What engineering leads and CTOs want to know before starting.
Does code quality suffer when agents take on more responsibility?
Not if autonomy and safeguards grow together — that is the core of the enablement. Every level gets matching controls: prompt contracts, verification loops, guard-rails in CI/CD. An agent whose output is systematically checked against the spec delivers more consistently than unchecked copy-paste usage at Level 2.
What about security, IP, and compliance?
Part of the enablement is a governance layer: clear rules about which data and repositories agents may see, traceable audit trails, and cost controls. The patterns can be anchored in an EU-AI-Act-compliant way and adapted to your existing security policies.
What happens to junior developers — do they unlearn the craft?
The risk is real if you ignore it — which is why roles and learning culture are their own topic. In an AI-native team, juniors learn differently, not less: specifying, verifying results, understanding architecture. Set up properly, agents accelerate learning because feedback loops get shorter.
How do we know the enablement is working?
By the changed way of working, not by an invented metric: tasks are delegated spec-driven instead of typed line by line, agent output runs through automated verification, reviews check contracts instead of diffs. In Levels-model terms: your team demonstrably works at Level 4 — with the controls that belong to it.
Are we locking ourselves into a specific tool?
No. I prefer working with Claude Code because it carries agentic workflows furthest today — but the patterns (specs, verification, guard-rails, review culture) are tool-agnostic and transferable. What stays is the way of working, not the license.