ENABLEMENT · 4–6 WEEKS · FIXED FEE
AI Enablement
People outside engineering make their own changes to real systems, inside guardrails that hold the architecture. No development environment to provision, and nothing to unpick afterwards.
THE PROBLEM THIS SOLVES
The problem this solves
The pipeline from an idea to something deployed runs through a small number of engineers, and everyone else waits. The obvious response is to put AI tools in front of more people, and it half works: someone without a programming background can get working output from a model within an afternoon.
What they cannot see is the architecture they are changing. A suggestion that looks reasonable on screen breaks something three layers down, and nobody notices until the person who maintains that layer opens it weeks later. The work shipped, and the cost moved downstream where it is harder to attribute.
There is a second cost, and it is the one that decides who gets to take part. Handing someone a development environment means a laptop with an editor, a runtime, a repository checkout and the weeks of support that follow when any of it drifts. At six hours of setup per person, you only onboard people who will contribute a lot. Everyone with one change to make stays in the queue.
WHAT IT COVERS
What it covers
- No development environment per person. People work in the tool itself, so onboarding is immediate rather than six hours plus weeks of follow-up support
- A constraint surface for your codebase: which patterns are allowed, which are refused, and which parts are off limits, enforced inside the workflow rather than at review
- Agents scoped to one layer each, coordinated, so an interface change cannot quietly reshape the database
- Working sessions with the people who will use it, because the constraints only settle against real attempts
- Handover to your engineers, who own the constraint surface afterwards and change it as the codebase moves
WHAT THIS IS NOT
What this is not
This is not a course, and it does not turn anyone into a developer. It is also not a licence for a platform: what gets built runs on your stack and your engineers own it when the work ends. The constraints are written for your codebase, so they are worth what your codebase is, and they need maintaining as it changes.
FIT
Fit
This fits when
- People outside engineering are already building with AI, with or without permission
- Your engineers are the bottleneck for changes that are small but constant
- There is a codebase worth protecting, and someone who will own the guardrails afterwards
This does not fit when
- What you need is the software itself built — that is an AI Automation Sprint
- Nobody on the engineering side will maintain the constraints once the work ends
- You want general AI literacy training rather than people shipping into a real system
WHAT HAS BEEN MEASURED
What has been measured
The mechanism above holds whether three people use it or thirty. The numbers below do not carry that weight: they come from one early pilot, and the sample is small enough that it is printed alongside them.
Over three months, three people outside engineering submitted 20 pull requests. Rework by the senior developers reviewing them fell from 80% of those requests to 30%, measured by the developers doing the reviewing rather than reported by the people whose work was under review. Onboarding a new person went from six hours of setup plus weeks of intermittent support to immediate.
What that changes is not the hours. It is who is allowed to take part: at six hours a head you invite the people who will contribute often, and at zero you can invite anyone with a single change to make.
ENGAGEMENT
Engagement
- Duration
- 4–6 weeks
- Format
- Architecture review + environment build + onboarding sessions
- Output
- A controlled build environment on your stack, your architecture rules enforced inside the workflow, and up to five non-developers onboarded and shipping changes
- Best for
- Teams where people outside engineering keep needing small changes, and the engineering queue is the bottleneck
The people are part of the engagement, not something that follows it. Building the environment and leaving it there produces a tool nobody uses, so the onboarding sessions are inside the scope and the work is not finished until people are shipping through it.
Five people are included. Beyond that, each additional person is onboarded at a per-person rate, so a team of twelve is a different conversation from a team of five.
Thirty days of support after handover, the same window as the AI Automation Sprint. It matters more here: what is left running is people still learning a way of working, not a system that has settled.
FAQ
Common questions.
Does this turn our non-developers into developers?
No, and that is the point. They stay in their own domain and describe what they need in their own language. The guardrails decide what the model may touch and what it may not, so the output stays inside the shape your engineers already maintain.
What stops the output becoming unmaintainable?
A constraint surface written before anyone starts: which patterns are allowed, which are refused, and which parts of the system are off limits. Work is planned before it is written and carried out by agents scoped to one layer each, so a change to the interface cannot quietly reshape the database.
Do our engineers get anything out of this?
They tend to be the heavier users. The same environment that keeps a non-developer inside the guardrails removes the routine work an engineer would otherwise do by hand, and it is their review that the plan step exists to serve.
How long before people are productive?
The model is capable from the first day. What takes time is tuning the constraints, because a first version is either permissive enough to let something break or strict enough to block legitimate work, and finding that line takes cycles with the people who will use it.