Engineering — Charter
What engineering owns in an AI-operated company — build capacity, standards, technical debt, the KPIs that expose delivery health, and where AI genuinely helps versus where it quietly costs.
Engineering builds and runs the systems. In an AI-operated company the interesting change is not that code gets written faster — it is that review, testing and judgement become the constraint, because generation stopped being one.
Teams that treat AI as a way to produce more code get more code. Teams that treat it as a way to spend more time on design and verification get better systems.
What this role owns#
Delivery. Working software in production, not merged branches.
Technical standards. Coding conventions, branching, review rules, API design, logging. Few enough to be remembered; enforced automatically where possible.
The health of the codebase. Technical debt is a business quantity, not an engineering complaint, and this role owns making it visible.
Operational reliability of what it ships, jointly with DevOps.
Honest estimates, including saying when an estimate is a guess.
KPIs#
| Measure | Why this one |
|---|---|
| Lead time for change | Merge → production. The core delivery metric |
| Deployment frequency | Small frequent changes are safer than large rare ones |
| Change failure rate | Share of releases causing a problem |
| Time to restore | How long an incident lasts |
| Review turnaround | A review sitting two days blocks a person and ages the change |
| Escaped defects | Bugs found by customers rather than by us — the honest quality measure |
| AI-assisted change review rate | Share of AI-generated code that received human review before merge. This must be 100% |
The first four are the industry-standard delivery metrics and they are hard to game. The last is specific to an AI-operated company and it is a control, not a target.
Where AI genuinely helps#
First drafts — of code, tests, documentation, migration scripts. Reviewed like any other contribution.
Test generation — turning a requirement into a starting test set. The Test Case Generator is exactly this pattern.
Understanding unfamiliar code — explaining a legacy module is a genuine strength and saves real time.
Boilerplate and translation — mechanical, verifiable, low-risk.
Review assistance — a first pass that catches obvious issues, freeing the human reviewer for design questions.
Where it quietly costs#
Volume without comprehension. Code nobody understands is a liability regardless of who wrote it. If a reviewer cannot explain what a change does, it does not merge.
Confident wrong answers about your specific system. A model has never seen your architecture. It will produce something plausible for a system that is not yours.
Debt accumulating faster. Generation speed applies to shortcuts too.
Skills not forming. A team that never debugs from first principles gradually loses the ability to, and that shows up during an incident.
AI agents in this function#
Code review assistant — first pass on every pull request: obvious defects, missing tests, convention breaches. Advisory, never blocking on its own.
Test generation agent — proposes cases from requirements; a human decides what is missing.
Documentation agent — keeps READMEs and API docs in step with the code.
Dependency and vulnerability watcher — flags known issues and stale versions.
Incident context assembler — during an incident, gathers recent changes, error patterns and related past incidents. Read-only, and genuinely valuable at 3am.
What stays human: architecture decisions, merge approval, anything touching authentication, payments or personal data, and production access.
SOPs#
- Definition of done — reviewed, tested, documented, deployable, observable.
- Code review — small changes, fast turnaround, comments on the code not the person.
- Branching and release — short-lived branches, one artefact promoted through environments.
- AI-assisted contribution rule — disclosed, reviewed by someone who can explain it, and held to exactly the same standard as anything else.
- Incident participation — who joins, who communicates, who writes the incident report.
- Debt log — deliberate compromises recorded when made, not discovered later.
Templates#
BRD · Test Plan · Architecture Diagram Set · Release Checklist · Security Checklist · architecture decision record.
Depth in Software Engineering and Architecture.
Workflows#
In: requirements from BA/PMO · defects from QA and support · incidents · security findings.
Out: working software · architecture decisions with rejected options recorded · estimates with stated assumptions · debt visible to whoever funds it.
Handoffs: QA before release · DevOps for deployment and operations · Security for review of anything sensitive · Support for known issues at release.
FAQ#
Does AI reduce the number of engineers needed?#
It changes what they spend time on more than how many you need. Generation was rarely the bottleneck — understanding the problem, verifying the solution and operating it were, and those still require people.
Should AI-generated code be labelled?#
Internally, yes — it tells a reviewer to look harder at whether it fits this system, which is where models are weakest. It should meet the same bar as any other code, not a lower or a higher one.
How do we stop technical debt accelerating?#
Make it visible and fix it where you are already working. Record deliberate compromises when you make them. The debt that hurts is the accidental kind nobody chose and nobody logged.
What is the most important control in an AI-assisted team?#
Human review by someone who can explain the change. Everything else follows from that one rule — without it, you accumulate code the team cannot maintain, and you find out during an incident.
What else is coming for Engineering
Charter Ready
What this department owns and is accountable for.
KPIs Not yet
The numbers it is judged on.
AI Agents Not yet
What is automated, and what stays human.
SOPs Not yet
How the recurring work is done.
Templates Not yet
The documents it produces.
Workflows Not yet
How work enters, moves and leaves.