An Engineering Checklist Before You Add Agents
There is no universal checklist for becoming “AI-ready.”
Even practices that feel almost unquestionable today are not universally right. Git dominates source control, but some organizations still have perfectly valid reasons to run SVN, Mercurial, or something more specialized. So don’t treat this as a certification checklist. Treat it as a collection of questions.
Some will be critical for your environment. Some will be irrelevant. The point is not to score 11/11. The point is to discover what your engineering system assumes a human will quietly figure out. Because before we talk about AI, it helps to temporarily remove AI from the picture.
The problem is not new. The consumer changed.
Imagine it is 2021. A developer picks up a ticket. They need to understand the problem, find the relevant code, discover previous decisions, follow the team’s conventions, implement the change, test it, open a pull request, get it reviewed, and eventually see it deployed. Later, someone should ideally be able to trace:
Ticket → Branch → Commit → PR/MR → Build → Release → Deployment
And in the other direction:
Production Deployment → Release → Build → PR → Commit → Ticket
None of this was invented by ChatGPT.
- When the ticket was unclear, a developer asked the product manager.
- When the architecture was undocumented, they asked the senior engineer.
- When nobody knew how to run the service locally, someone messaged the one person whose laptop mysteriously worked.
Humans have always compensated for weak engineering systems with questions, experience, tribal knowledge and educated guessing. Now we have a new consumer of that system: the agent.
That is why AI readiness is often less about AI than it is about engineering maturity. And one important caveat: the following items are not equally weighted. If an agent cannot understand the work or the engineering rules, most of the more sophisticated items below will not save you.
1. Can an agent start from a ticket?
Unclear requirements are not an AI problem. They are one of the oldest problems in software engineering.
Ask:
- Is the ticket reasonably atomic?
- Is the problem clearly stated?
- Are the acceptance criteria testable?
- Are dependencies explicit?
- Are relevant designs, contracts and documentation linked?
- Can the agent access those resources?
- Is the expected ticket structure defined somewhere reusable and versioned?
It does not matter whether the ticket was written by a product manager, generated by AI, or assembled by copy-pasting fragments from five Slack threads.
What matters is whether another actor can execute it without guessing what the author meant.
Bad:
Fix the login issue.
Better:
Login returns 401 when the email contains uppercase characters. Normalize the email before comparison in
AuthService.Login. Acceptance: login must succeed regardless of email casing, and a regression test must cover the scenario.
That is not “writing tickets for AI.” That is writing better tickets.
2. Does a PR explain the change, not just contain the diff?
A pull request is not merely a container for changed lines. A title like:
fix stuff
is bad for humans and nearly useless as organizational context for agents.
A PR or MR should make it easy to answer:
What changed? Why? Which requirement does it address? How was it tested? What is the risk?
Check whether:
- titles follow a meaningful convention;
- descriptions have a standard structure;
- tickets and PRs are linked;
- sections such as What, Why, Testing, Risk and Migration are expected where relevant;
- commit messages follow a convention;
- the agent knows when and how to open a PR;
- these rules live in shared, maintained instructions rather than everyone’s private prompt.
If every developer gives their coding agent a different set of instructions, you have not created an AI development process. You have created several undocumented development processes.
3. Does the agent understand your source-control model?
“We use Git” is not enough.
Do you use GitFlow? GitHub Flow? Trunk-based development? Release branches? Something internal?
An agent needs to know:
- where branches start;
- branch naming rules;
- protected branches;
- merge vs. squash vs. rebase expectations;
- hotfix procedure;
- release strategy;
- commit-message conventions;
- whether generated artifacts belong in source control.
These decisions should exist before the first AI-generated pull request.
4. Have you defined the engineering rules before asking AI to write code?
Give three developers no shared engineering conventions and you will probably get three styles of code. Agents are no different. Before generating code, make sure the system can discover things such as:
- naming conventions;
- repository and project structure;
- dependency-management rules;
- error-handling conventions;
- logging standards;
- preferred architectural patterns;
- prohibited patterns;
- testing conventions;
- approved and disallowed libraries.
I do not particularly care whether your coding guidelines came from Microsoft, Google, an internal architecture group, a book, or were written over a weekend by your most opinionated staff engineer.
I care that they exist, are discoverable, and are consistent.
If you expose them through Agent Skills or another reusable instruction mechanism, treat those assets as engineering artifacts:
owner, version, review, distribution and update process.
A copy of coding-guidelines.md hidden inside five developers’ prompts is not governance.
5. Can you trace a change end to end?
Pick a random ticket.
Can you navigate:
Ticket → Branch → Commit → PR → Build → Release → Deployment
Now reverse it.
If you have to ask someone, “Do you remember what this production change was for?”, the problem is bigger than AI. Ticketing, source control, CI/CD and documentation should form a connected engineering graph wherever practical. Agents simply make broken traceability more visible.
6. Can a machine build and verify the software?
Documentation that effectively says:
Ask Sam. His laptop has the right configuration.
is a problem regardless of whether your engineer is human or artificial.
An agent should be able to discover:
- how to build the project;
- how to run tests;
- required environment setup;
- how dependencies and supporting services are started;
- where test data comes from;
- how migrations are applied;
- which quality gates must pass.
If an agent can generate code but cannot independently validate it, you have a code generator, not an engineering agent.
That distinction matters.
7. Can the agent find the context it needs?
Experienced engineers are often valuable partly because they know where everything is hidden.
The architecture decision is in Confluence.
The API contract is in another repository.
The business rule is in an old Google Doc.
And the reason for that strange if statement lives exclusively in somebody’s memory.
Ask:
- Are architectural decisions discoverable?
- Are ADRs available?
- Is domain terminology documented?
- Is service ownership clear?
- Are API contracts discoverable?
- Can the agent access the required systems?
- Are obsolete documents and code clearly marked or removed?
Having documentation and having discoverable, trustworthy documentation are two different things.
8. What exactly is the agent allowed to do?
An agent that can read a repository is not equivalent to one that can:
- write code;
- create branches;
- execute commands;
- trigger pipelines;
- modify infrastructure;
- access production data;
- deploy software.
Define:
- repository access;
- read/write permissions;
- allowed tools and commands;
- secret handling;
- production-data access;
- PII boundaries;
- actions requiring human approval;
- audit requirements.
Remember that agent-readable content is itself an attack surface. Tickets, documentation, PR comments and external pages can all carry hidden instructions.
Tickets, documentation, PR comments and external content can all become prompt-injection surfaces.
Least privilege is not an optional enterprise feature you add later.
It should be part of the architecture from day one.
9. Is AI cost part of your engineering architecture?
Tokens are resources.
If you do not measure usage, define budgets or establish model-selection rules, your cost strategy can easily become:
Use the expensive model Monday through Wednesday, discover on Thursday that the budget is gone, and finish the feature with whatever is cheapest.
You should understand:
- usage per team;
- usage per repository or workflow;
- which tasks justify expensive models;
- where cheaper models are sufficient;
- budget thresholds and alerts;
- cost per task or change;
- provider and model fallback policies;
- whether changing the model affects quality expectations.
Model routing and token budgets are no longer purely procurement questions.
They are becoming part of development-system architecture.
10. Do you know whether AI is actually helping?
Cost per task from the previous section only means something next to outcomes. Otherwise you just know what you spent, not what you got.
Lines of AI-generated code are not a meaningful productivity metric.
Start with outcomes.
Use established engineering metrics such as DORA as a baseline, then add AI-specific measures where they answer useful questions.
For example:
- Has lead time changed?
- Has deployment frequency changed?
- Has change failure rate changed?
- Has recovery time changed?
- What happened to PR review time?
- Has rework increased?
- Are rollbacks becoming more frequent?
- How much agent-generated code is substantially rewritten?
- What is the AI cost per successful change?
- Which classes of task consistently benefit from agents?
More generated code does not automatically mean more delivered value.
If you did not have a baseline before AI adoption, you may simply be adding another unknown variable to an already unmeasured system.
11. Are your Agent Skills treated like software?
Once agents depend on organizational instructions, those instructions stop being “just prompts.”
If a Skill defines your architecture rules, ticket format, PR conventions or coding standards, ask:
- Who owns it?
- Which version is active?
- Who reviews changes?
- How is it distributed?
- How do clients receive updates?
- Can you roll it back?
- Can you test whether a change improves or degrades agent behavior?
At that point, the Skill is effectively part of your engineering platform.
Treat it accordingly.
The short version
Before buying another AI development tool, ask a different question:
If an extremely fast engineer with zero tribal knowledge joined the team tomorrow, is our engineering system explicit enough for them to work correctly?
If the answer is yes, you may already be much further along in AI readiness than you think.
If the answer is no, AI probably did not create the problem.
It just made the problem much easier to see.
Quick checklist
☐ Can an agent start from a ticket without guessing?
☐ Would a PR/MR make sense to someone outside the immediate team?
☐ Are branching and commit conventions documented?
☐ Can the agent discover your engineering and architecture rules?
☐ Can you trace a ticket all the way to production and back?
☐ Can build and test run without somebody’s special laptop?
☐ Can the agent reliably discover the context it needs?
☐ Do you know exactly what the agent can access and change?
☐ Are AI usage and cost observable?
☐ Do you measure outcomes rather than generated code?
☐ Do your Agent Skills have owners, versions and a release process?
I put together an AI Readiness Checklist for Software Teams, but deliberately avoided making it a checklist of AI tools.
It covers questions like:
- Can an agent start from a ticket without guessing?
- Are your coding and architecture conventions explicit and versioned?
- Can a change be traced from ticket to deployment and back?
- Can build and test run without tribal knowledge?
- Does the agent have the right context, and only the right permissions?
- Are token usage and model cost observable?
- Are you measuring engineering outcomes rather than lines of generated code?
- And if Agent Skills define how your team works, are you managing those Skills like software?
My main takeaway:
AI does not necessarily create weaknesses in your engineering system. It often exposes the ones humans have been quietly compensating for.