How do you get a development team using AI coding tools well, not just using them?
Build the harness before you scale the tools. That means repo-level rules, review gates that know which changes need a human, tests that run before an agent's work can merge, and a policy saying what AI may touch and what it may not. Then measure: lead time and change failure rate before and after, plus the revert rate of AI-authored changes. Teams that skip the harness get faster for about two months.
- Baseline firsttwo weeksNinety days of delivery data: the four DORA metrics, plus where reviewer time actually goes.
- Rules the agent can readRepository context describing the architecture, the conventions, and the things that look wrong but are deliberate.
- Gates keyed to riskWhat merges on green CI, what always needs a named human, what nobody automates. Enforced in branch protection, not left to judgment.
- Tests that mean somethingSeparate the code from the tests that prove it, so an agent cannot write both and mark its own work.
- Fix the real constraintIf the pipeline is slow or the suite is flaky, faster authoring changes nothing. That is delivery practice, and it is in scope.
- Measure and hand overCommit marking, the six metrics, an onboarding runbook, and a team that can change the harness without us.
Measurement starts in step one, not after. Without a baseline there is no result, only an impression.
Engineering Enablement
The two-month problem
A team turns on AI coding tools. Throughput rises immediately, and everyone is pleased. Around month three the incident rate starts climbing, senior engineers are spending their days reviewing code they did not write and do not trust, and someone suggests the tools were a mistake.
The tools were not the mistake. The missing harness was. Authoring got faster and review did not, so the bottleneck moved to the most expensive people on the team and nobody noticed until it hurt.
What we build
Rules the agent can read. Repository-level context describing the architecture, the conventions, the things that look wrong but are deliberate, and the boundaries. An agent with good context produces changes a reviewer can approve in a minute; an agent without it produces plausible code that takes twenty minutes to evaluate.
Gates keyed to risk, not to volume. Tests, documentation, and scaffolding can merge on green CI. Anything touching authentication, payments, data migration, or infrastructure gets a named human. The list is written down and enforced in branch protection, not left to judgment at 6pm on a Friday.
Tests that mean something. If an agent can write code and the tests for it in the same change, the tests prove nothing. We separate them: characterization tests for existing behavior, review requirements for new test files, and CI that runs the real suite rather than the one the agent just wrote.
Measurement from week one. Commit marking so AI-assisted changes are identifiable, then the four DORA metrics plus the two AI-specific ones. Team level, never individual. We have written up how to measure whether AI is helping in more detail.
The delivery practice
This service area absorbed what used to be a separate offering, because the two were always sold together. DevOps, CI/CD, QA strategy, and the working agreements that move a change from idea to production.
The reason is simple. A harness improves how a change is authored. If the constraint is that your pipeline is slow, your test suite is flaky, or three people have to be in a meeting before anything merges, the harness will not help and we would be taking your money. We find the actual constraint during the assessment and fix that one.
Where the gains land
The largest field study of an AI assistant at work found a 13.8% average productivity gain, 35% for the least experienced workers, and minimal effect on the most experienced. It measured support agents rather than engineers, but the shape holds in the engineering teams we have worked with: the tools compress the ramp for newer people more than they speed up your principals.
Plan for that. The senior engineers’ gain is fewer interruptions and a shorter review queue, not more lines of code, and the mid-level engineers’ gain is reaching senior judgment faster. Those are the outcomes worth measuring.
What we will argue with you about
Individual productivity dashboards. Some leadership teams want AI telemetry broken down per developer, and we will decline to build it. It measures activity rather than outcome, it is trivially gamed, and it converts a team that was curious about the tools into a team that is careful around them. The team-level metrics answer the real question and cost you nothing in trust.
What you get
- A harness in your repositories: agent rules, context files, and the boundaries of what may be changed without review
- Review gates keyed to risk: what merges on tests alone, what always needs a named human, what nobody automates
- Test and CI requirements that AI-authored changes must clear before merge
- Security boundaries: credentials, infrastructure, data migrations, and everything else an agent may not touch
- An engineering appendix to the AI policy, written for people who ship code
- Commit marking so AI-assisted changes can be measured separately from the rest
- Baselines and a dashboard: the four DORA metrics plus revert rate and reviewer time per change
- Onboarding runbook, so the next engineer inherits the practice rather than rediscovering it
- Delivery practice where it is the constraint: build and release pipelines, deployment automation, QA automation strategy, and the working agreements around them
- Shorter lead time from commit to production, measured before and after, which is the number that decides whether any of this worked
Questions we get
- Which AI coding tool should we standardize on?
- Standardize the workflow, not the tool. The pattern that holds up in 2026 is agentic tools for autonomous and scripted work, an inline editor for day-to-day changes, and broad completion coverage across the rest. Teams that picked one tool and forbade the others spent the next year fighting shadow usage.
- Our developers already use AI. Is it too late to put rules around it?
- No, and this is the normal starting point. It is easier to govern a practice people are already invested in than to introduce one. The work is naming what is already happening, deciding which parts are fine, and drawing the line where it matters.
- What does the harness actually consist of?
- Files in your repository that tell an agent the conventions, the architecture, and the boundaries; CI checks that run on every AI-assisted change; review rules in your pull-request template and branch protection; and a written policy appendix. It is configuration and process, not a product we sell you.
- How do we know it worked?
- Lead time for changes and deployment frequency should improve while change failure rate and time to restore hold. The revert rate of AI-authored changes should be no worse than the rest, and reviewer time per change should not climb. If throughput rises and reverts rise with it, you bought speed with quality and the gates need tightening.
- Why is DevOps and QA part of this service area?
- Because a harness without the delivery practice around it is a tool nobody uses. If your pipeline takes forty minutes and flakes twice a day, faster authoring changes nothing. We fix the constraint wherever it actually is.
How it starts
Two-week assessment, then six to ten weeks per team group. You keep everything produced, whether or not there is a next part.