GRAIL · Function papers
What does an AI-augmented engineering organisation look like?
By Johan Grönstedt · Last reviewed
Execution runs in parallel. Judgment stays with the engineer. This free, nine-page position paper sets out what that operating model looks like.
An AI-augmented engineering organisation has engineers supervising several bounded execution threads instead of carrying every task from first draft to finished change. The agent produces and checks. The engineer defines, judges and remains accountable.
A day in
The engineer's day, 2028
The day starts with a brief built from overnight incidents, customer signals, dependency alerts and failed pipelines. The engineer specifies the work, several bounded changes run, and the resulting pull requests return for review before release checks.
BRIEF
Combining overnight incidents, customer signals, dependency alerts, failed pipelines.
SPECIFY
Inspect the relevant code, propose a plan.
RUN
Create branches, write tests and prepare small pull requests.
REVIEW
Challenge correctness, maintainability, security and missing documentation.
RELEASE
Check tests, dependencies, secrets and licences.
The operating split
What runs, and what stays with the person
The agent layer takes on bounded work that can be inspected, tested and returned with evidence. It searches repositories and standards, drafts alternatives, writes code and tests, runs checks, prepares small pull requests, and assembles release material. Several of those threads can move at once. In maintenance work it can build incident timelines, correlate telemetry with recent changes, propose tested fixes and prepare bounded refactors. In supplier work it can reconcile contracts, issues, pull requests, review findings and accepted outcomes.
The person sets the conditions around that work. Priority, scope, architecture, test policy, risk acceptance and approval remain human judgments. The split keeps implementation moving while preserving a clear owner for choices that shape the product and its operation. During an incident, mitigation and incident command stay with the person. For customer-impacting or high-risk releases, so does approval. Physical design, tolerances, safety judgments, testing and certification stay human in hardware and embedded research.
The same pattern holds from discovery through deployment. Agents turn curated inputs into a proposed artifact and supporting evidence. People decide whether the proposal is desirable, sound, safe and ready to enter production. In architecture work, the agent drafts alternatives, dependency effects, security implications and a decision record. The person owns the architecture choice, its rationale and the migration judgment. In discovery, the agent prepares disposable prototypes, while the person owns priority, scope, desirability and production intake. The agent can derive test cases, generate fixtures, expand regression coverage and trace findings to deployed components. The person owns test architecture, security policy, risk acceptance and serious findings. The agent can draft rollout and rollback steps and monitor production health, while the person remains accountable for the release decision.
| Process | What the agent layer does | What stays with the person |
|---|---|---|
| Discovery, specification, backlog and planning | Turns curated research, strategy and examples into user flows, acceptance criteria, edge cases and open questions; prepares disposable prototypes in an approved sandbox. | Priority, scope, desirability and production intake. |
| Architecture and technical decisions | Searches repositories, standards and prior decisions; drafts alternatives, dependency effects, security implications and a decision record. | The architecture choice, its rationale and the migration judgment. |
| Coding, code review and documentation | Inspects the codebase, plans bounded changes, writes code and tests, runs checks, opens small pull requests and flags review issues. | The specification, review of material changes and ownership of the merge. |
| Testing, QA, security and dependencies | Derives test cases, generates fixtures, expands regression coverage and traces findings to deployed components. | Test architecture, security policy, risk acceptance and serious findings. |
| Release and deployment | Assembles test evidence and approvals; drafts release notes, rollout steps and rollback steps; monitors production health. | Approval for customer-impacting or high-risk releases. |
Positions on the operating model
Six things GRAIL believes
The floor is faster code. The ceiling is better engineering decisions.
Drafting speed is visible, so every rollout notices it first.
Implementation stops being scarce before judgment does.
Agents can inspect, draft and test several bounded changes at once.
A prototype proves the question, not the product.
Business teams should test customer problems before joining the production queue.
The engineering system amplifies whatever is already there.
Strong specifications, modular architecture, automated tests and protected pipelines turn agent output into validated change.
Augment execution, never automate accountability.
Agents can create branches, tests, evidence and proposed remediations.
The apprenticeship must be redesigned on purpose.
Senior engineers gain time for systems design and evidence review, but future senior judgment cannot appear by itself.
These six beliefs are not positions on tools. They are positions about how a company turns intent into dependable products, and every agent inherits them.
Get the paper
Read the full position paper on how execution, evidence, judgment and accountability fit together.