People & leadership
Define engineering responsibilities, coach managers and teams, and build shared ownership across product, development, QA, security and operations. Transformation must change how people collaborate, not only which tools they use.
Head / Director of Engineering · Applied AI Leadership
I can lead your organisation’s AI engineering transformation.
I help engineering organisations turn AI adoption into a dependable way of delivering software. I bring the leadership to change team practices, the technical depth to connect agents with complex platforms, and experience taking a governed AI-DLC workflow through to production releases with human approval.
Strategy
to use casesBuild
with guardrailsMeasure
and improveDeploy
and enablePeople
Process
AI
OutcomesSustainable
AI impact
at scale
to use casesBuild
with guardrailsMeasure
and improveDeploy
and enablePeople
Process
AI
OutcomesSustainable
AI impact
at scale
At a glance
AI transformation, from discovery to delivery.
- Engineering challenge
- Turn individual AI use into a repeatable delivery practice across teams and complex platforms.
- My leadership decisions
- Discover useful work, build reusable skills, define MCP context needs and establish specialist agents for backend and platform development.
- Experience I bring
- An operating L3 AI-DLC workflow spanning specialist-agent development, testing and independent validation through to production releases with human approval. L4 implementation is underway.
- What you can hire me to lead
- AI engineering leadership or a transformation contract connecting team adoption, system context, specialist agents and governed delivery.
02 / AI engineering transformation
Transform the organisation.
Not just the tools.
I can help you choose where AI belongs, prepare the context and platform foundations, and change how your teams plan, implement and verify software. The goal is organisational capability: clear ownership, reusable practices and controlled delivery, not simply more AI-generated code.
Experience behind the capability
From discovering useful work to changing how it is delivered.
I bring experience across the transformation, beyond the choice of AI tools. These are the decisions I have led, from discovering useful work to establishing specialist-agent development and delivery automation.
- 01Use-case discovery
Discover use cases. Build reusable skills.
I started by discovering where AI could support engineering work and developing reusable skills around those use cases.
My leadership decisionStart with the work to be done, then define the skills that support it. A tool rollout alone is not enough.
- 02Context foundations
Identify the context. Define MCP needs.
I identified the MCP servers needed to feed agents the relevant context for those skills and use cases.
My leadership decisionMake context requirements explicit before expanding what agents are asked to do. MCP means Model Context Protocol.
- 03Development practice
Require specialised development subagents.
I began requiring specialised subagents for different areas of development, including backend and platform engineering.
My leadership decisionMove from general-purpose assistance to area-specific agent responsibilities within the development process.
- 04L3 operating · L4 underway
Automate delivery through AI-DLC.
I established an L3 AI-DLC workflow spanning specialist-agent development, testing and independent validation through to production releases with human approval. L4 implementation is underway.
My leadership decisionBring specialist agent work into an operating delivery workflow, then build the next layer of automation on that foundation.
Experience to build onMy operating L3 AI-DLC workflow supports production releases with human approval. I bring that experience to defining the transformation path for your team and systems, with L4 implementation underway.
The organisational scope I can lead
The delivery operating model
Connect intent, planning, implementation, verification and release through shared context and clear decision rights. Replace disconnected AI activity with repeatable, accountable ways of working.
Platforms & engineering foundations
Make repositories, service contracts, environments, permissions and recovery paths usable for controlled agent work. Distributed-system complexity is part of the transformation and must be understood by the agents.
Governance, adoption & value
Establish risk boundaries, evidence gates and cost ownership. Lead a bounded pilot, enable the teams, expand what works and measure accepted outcomes, stability, rework and operating effort.
Maturity journeyHow the team’s operating model evolves.
Delivery workflowHow each change is planned, validated and released.
The framework below helps shape a transformation mandate for your organisation. Select a stage to review its leadership actions, controls and progression criteria. It is a planning lens, not an independently assessed maturity rating.
From personal tool adoption to a shared engineering baseline.
- Leadership work
- Assess where AI is used, where the team loses time, and what work is unsafe to automate. Agree approved tools, data boundaries, ownership and baseline delivery measures.
- Controls and ownership
- Existing code review and CI remain in place. Protect credentials and private data, and make responsibility for generated changes explicit.
- Evidence before progression
- A baseline of lead time, review effort, escaped defects and operating cost, plus a bounded pilot with an accountable owner.
The boundaryAdoption and generated code volume are activity measures, not proof of better delivery.
From faster individuals to a repeatable team practice.
- Leadership work
- Version architecture guidance, commands, acceptance criteria and task context. Train the team on how to specify work, check outputs and capture decisions across repositories.
- Controls and ownership
- Use bounded tasks and approved execution environments. Keep tests, reviews and human release authority connected to the original requirement.
- Evidence before progression
- A pilot that produces traceable changes with reproducible validation, without simply moving the bottleneck into review or QA.
The boundaryGenerating changes faster than the team can verify them creates review debt rather than leverage.
From agent-assisted tasks to an accountable delivery system.
- Leadership work
- Define implementation, validation and operational roles. Establish service contracts, usable system context, sandboxed execution, per-role permissions and evidence-based progression gates.
- Controls and ownership
- Separate implementation from independent validation; agents do not approve their own work. Apply security, quality, cost and compliance checks with explicit human escalation and release decisions.
- Evidence before progression
- A change can be traced from intent through source revision, independent verdict, tests and environment evidence to its release or rollback decision.
The boundaryOrchestration needs a dependable platform foundation. Queues, data ownership, API boundaries, delivery environments and recovery paths must be understandable to both people and agents.
From fixed permission boundaries to evidence-based, risk-specific autonomy.
- Leadership work
- Explore trusted patterns only after the governed workflow is repeatable. Maintain current intent and dependency context, evaluate outcomes and decide where automation adds value rather than risk.
- Controls and ownership
- Constrain autonomy by risk, permissions and proven verification. Keep stop conditions, rollback and human ownership of intent, exceptions and risk acceptance.
- Evidence before progression
- A defined class of low-risk work repeatedly meets acceptance and recovery criteria within a monitored, revocable automation boundary.
The boundaryThis is an implementation direction, not a claim of an autonomous software factory already delivered. High-risk financial, security or regulatory decisions do not automatically become autonomous.
My transformation playbook
Lead adoption from mandate to operating practice.
Align the organisation around a real business constraint, establish the foundation, prove the workflow and grow adoption where the evidence supports it.
- 01
Assess the starting point
Map tools, hand-offs, system constraints and team readiness. A company can have different maturity across teams and kinds of work.
- 02
Prove one bounded workflow
Choose a useful change with a baseline, a sponsor and acceptance criteria. Establish context, validation and recovery before increasing scope.
- 03
Change the operating model
Clarify roles, review capacity, permissions and release ownership. Coach the team and keep product, security and operations involved.
- 04
Scale the pattern, not the hype
Expand where evidence supports it. Compare accepted outcomes, rework, stability and full cost; keep autonomy limited where the controls are not ready.
Platform ownership is the foundation, not a separate story.
Agents working across services need understandable contracts, data ownership, permissions, environments and recovery paths. My ownership of a three-brand distributed platform grounds this transformation approach in real engineering complexity, not only agent tooling.
03 / Operating model
AI needs an operating model.
A useful agent can complete a task. A delivery system must also control context, permissions, validation, deployment, QA, and the final decision.
01
Governed context
The right repository knowledge, commands, and permissions reach the right agent.
02
Independent validation
The agent that changes code never approves its own work.
03
Controlled deployment
Every release returns test, security, deployment, and rollback evidence.
04
Evidence-based decisions
Human authority remains explicit at the final decision gate.
Evidence
Designed for a 30-repository engineering landscape
One cloud workspace. Clear role boundaries. Human authority at the decision gate.
04 / Delivery roadmap
A practical path from assisted coding to governed delivery.
A focused path to real outcomes, with clear separation of agent execution and human judgment at every stage.
Exit evidence
One governed cloud workspace with versioned context and approved commands.
The principle
Agents execute. Humans set intent, risk, and the final GO / NO-GO.
Conceptual architecture
No agent approves its own output.
Intent and risk determine the approved context for a bounded implementation role. A separate validator returns PASS, FAIL, or ESCALATE with evidence. An accountable person keeps the final release decision.
- 01Intent
- 02Classify risk
- 03Approve context
- 04Implement
- 05Validate independently
- 06Deploy + evidence
- 07Human GO / NO-GO
PASSFAIL WITH EVIDENCEESCALATE
05 / Delivery records
Records that make delivery reviewable.
The workflow I can establish makes intent, risk and release decisions reviewable. A delivery contract, risk classification and traceable evidence record give engineering, security and business stakeholders a shared basis for deciding what can move forward.
Delivery contract
Versioned intent, approved context, permissions, acceptance criteria and an accountable human owner.
Requirement · context · permissions · ownerRisk classification
A change-level decision about autonomy, validation depth, escalation and release authority.
Risk tier · controls · validator · decision gateEvidence record
One trace from requirement through implementation, independent verdict, deployment and rollback proof.
Tests · evaluation · security · deploy · rollbackPortfolio source
View source repository The public source includes the Docker build, Cloudflare Worker configuration, Terraform and this portfolio. It is not the implementation source for the organisation’s AI delivery automation.
06 / Direct answers
Questions an AI delivery leader should be able to answer.
Clear definitions make the operating model easier to review, compare and challenge.
What is AI-DLC?
AI-DLC is a human-led operating model for using AI across software delivery. It separates implementation from independent validation and keeps deployment authority, audit evidence and risk acceptance with accountable people.
How is AI-DLC different from a traditional SDLC?
It extends the existing SDLC with governed AI context, generated-change provenance, model and prompt evaluation, independent validation and explicit decision gates. The engineering lifecycle remains; the controls expand for AI-assisted work.
Where does human validation happen?
People define intent and risk boundaries, approve the plan, review independent validation evidence and authorize release. Agents can execute bounded work, but they do not approve their own output or make the final GO / NO-GO decision.
What delivery evidence does AI-DLC produce?
Each change should connect the requirement, implementation, tests, evaluations, security results, reviewer verdict, deployment result and rollback path. That evidence makes speed auditable rather than anecdotal.
How should a company start?
Start with a bounded pilot, baseline lead time and defect measures, define approved context and permissions, separate implementation from validation, then compare evidence before deciding what should scale.
Standards and references
07 / Leadership conversation
If AI is entering your SDLC, I can lead the system around it.
Let’s discuss a permanent engineering or Applied AI leadership role, or a contract to lead your transformation. Based in Switzerland, open to remote teams across Europe. Tell me the delivery challenge, platform complexity and team mandate you need someone to own.
Your leadership prioritySelect the mandate that matters most