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.
The delivery model#
This is not a traditional software house with autocomplete bolted on. The pipeline is arranged so that generation is cheap and every gate after it is real.
Read it as one sentence: a person decides, machines produce and check, a person stays accountable. The gates in the middle are not ceremony. Each is allowed to stop the change, and a gate that has never stopped anything is either misconfigured or being routed around.
The order is deliberate. Code review runs before the test suite, because a review that happens after a green suite only reviews what the tests failed to notice. The security scan runs before CI/CD rather than after deployment, because a finding in production is an incident and the same finding ten minutes earlier is a task.
Where AI assists, across the whole lifecycle#
| Stage | What it does here |
|---|---|
| Requirements | Turns a conversation into testable statements, and flags the ones that cannot be tested |
| BRDs | Drafts the document. The trade-offs and the exclusions stay human |
| Architecture | Generates options and the argument against each. It does not choose |
| Coding | Writes the change and its tests in the same pass |
| Documentation | Written from the diff, so it is accurate on the day it ships |
| Testing | Cases, fixtures and the edge conditions people skip when tired |
| Debugging | Reproduces first, explains second. A fix without a reproduction is a guess |
| Code review | Every change, immediately, consistently, with no review fatigue |
| Security review | Dependency, secret and pattern scanning on every commit |
| Deployment | Pipelines, rollbacks and release notes |
| Monitoring | Watches behaviour rather than uptime, and ties a regression to the change that caused it |
Eleven stages, and the useful observation is that AI touches all of them while owning none of them. What it contributes is throughput and consistency. What it cannot supply is the judgement that decides whether the system is the right one.
What stays with the human, permanently#
Architecture and critical decisions. Not because a model cannot propose a design, but because choosing between designs is choosing which problems the company lives with for the next three years, and somebody has to be answerable when one of them arrives.
Specifically, and without exception:
- The architecture decision, and the record of what was rejected and why
- Anything irreversible: a schema migration, a data deletion, a public API contract
- What the system is allowed to do unsupervised
- Accepting a release
- Declaring an incident, and deciding to roll back
Cheap generation does not move any of these. It makes them more frequent, which is precisely why they are written down rather than assumed.
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.
Architecture, systems, and the layer everything else assumes is working.
Also in this topic: Enterprise Architecture, Architecture, Linux, DevOps, Software Engineering.
What else is coming for Engineering
Charter Ready
What this department owns and is accountable for.
KPIs Ready
The numbers it is judged on.
AI Agents Ready
What is automated, and what stays human.
SOPs Ready
How the recurring work is done.
Templates Ready
The documents it produces.
Workflows Ready
How work enters, moves and leaves.