"Agentic engineering" is often presented as an outcome: agents build the software. In our experience it is a set of practices. Agents take on bounded tasks; people decide what those tasks are, check the results, and stay responsible for what reaches production. Without those practices, speed turns into rework.
This article describes the four practices we apply on every project: specification, shared context, verification and ownership. None of them is new. What changes with agents is how strictly they must be followed.
1. Specification: every task starts in writing
An agent cannot ask the product manager what they meant. So before an agent touches the code, the engineer writes a short task specification.
Task: Add organization invitations by email
Scope: api/invitations/*, web/settings/members/*
Out of scope: billing, SSO
Constraints:
- active organization comes from the session, never the request body
- invitation tokens expire after 7 days
Checks:
- unit tests for expiry and reuse
- an admin of org A cannot invite into org B
- typecheck and lint passThe specification sets a boundary as well as a goal. Files out of scope stay untouched; anything the agent proposes outside the boundary is rejected, however reasonable it looks.
2. Shared context: decisions live in the repository
Agents work from what they can read. If the reasons behind the architecture live in someone's head or an old chat thread, the agent will reinvent them, usually differently. We keep short decision records, architecture notes and coding conventions in the repository, next to the code.
- Decision records explain why: "Tenancy is enforced in the database as well as the API, because…"
- Architecture notes describe the boundaries: which module owns which data.
- Conventions cover error handling, naming and testing patterns.
The same files help a new engineer on day one. Context written for agents turns out to be context written for people.
3. Verification: nothing merges on trust
Every agent change arrives as a normal pull request. Before a person reviews it, automated checks run: type checks, linting and the tests named in the specification. Then an engineer reads the diff line by line.
- 01Spec written
- 02Agent proposes diff
- 03Automated checks
- 04Engineer reviewHuman approval
- 05Merge by a person
We prefer small diffs. A 2,000-line agent change cannot be reviewed properly, so we split the work instead. Critical files such as authentication, billing and migrations get an extra reviewer.
4. Permissions and ownership
Agents get the permissions a task needs and nothing more: read the repository, run tests, open a pull request. They do not get production credentials, deploy rights or access to client data stores.
Every change that reaches production has a named engineer responsible for it. If it fails at 2 a.m., the answer to "who understands this?" is a person, not a tool.
Where agents help most, and where they do not
| Works well | Needs care | Keep with people |
|---|---|---|
| Repetitive changes across many files | Refactors that touch shared boundaries | Architecture and data-model decisions |
| Tests from a clear specification | Performance work without benchmarks | Security-sensitive code paths |
| Boilerplate for well-known patterns | Unfamiliar third-party APIs | Anything that changes production data |
Used this way, agents shorten well-defined work, which is part of how we can commit to a 30-day first release for a fixed scope. The method matters more than the tool. Read more about AI-assisted delivery or, if you want AI inside your own workflows, see AI automation.