Where is your team stuck with AI agents? Twelve answers tell you.
Find out where your team stands with AI coding agents and which gaps are holding it back.
- Twelve yes or no questions
- three minutes
- instant result
- free, no account
Next steps for your product practice
- Give an agent the notes from your last five customer interviews to synthesise, and check its summary against what you actually heard.
- Build your next idea as a prototype with a tool such as Lovable or v0, and show it to two users before you write the ticket.
- Add edge cases and checkable acceptance criteria to your next requirement, so an agent can verify its own result against them.
- Refine continuously in small slices rather than in one big planning round, so the next validated spec is always waiting.
Your result
This result describes one of your teams. Ask each team lead to take the check for their own team and send you the link to their result. On a call, we compare them with you.
- What holds you here
- Where agents are used, each developer works out their own approach. Context, review and habits stay personal, and the team has no agreed tools, time or guardrails yet.
- Your next move
- Train the whole team together on its own code, so everyone works with agents the same way.
- What holds you here
- Agents do real work, but gaps in context, harness or habits mean people still do much of the checking.
- Your next move
- Put the first step under priority 1 into your next sprint, then work down the list.
- What holds you here
- The practice lives in one team. Taking it to more teams and showing its impact are the open questions.
- Your next move
- Set a baseline across your teams, then take the practice to the next one.
Your top priorities
Every answer is yes. Take the check again after the next big model release: the bar will have moved.
-
What your agents deliver
Do your coding agents implement and ship routine tickets? (not sure, to check) Do you use AI across the whole software development lifecycle? (not sure, to check)
Start with this: Pick one ticket type your team handles often and let an agent take it all the way from ticket to merged change, with a person reviewing. List the steps from refinement to operations where agents never show up, and try one of them on real work.
Delivery is where the time agents save reaches your customers. Without it, faster code changes nothing they would notice.
-
What your agents can see and run
Do your agents get the context automatically? (not sure, to check) Do you maintain a shared agent harness? (not sure, to check) Can your agents run your system and improve it from feedback? (not sure, to check)
Start with this: Write down what a new developer needs to know about your codebase, and put it where the agent loads it at the start of every session. Move the prompts, rules and tools each developer keeps privately into one repository the whole team maintains. Give the agent a way to start the system, run the tests and read the logs, so it checks its own work before a person does.
An agent is only as good as the context it gets and the system it can run. Without both, it guesses, and people end up checking.
TrainingsAgentic Engineering for Developers and QATrainingsAgentic Software Factory: Advanced Team TrainingTrainingsAgentic Engineering for DevOps and Platform Teams
-
How your people work with agents
Can you write agent-ready tasks? (not sure, to check) Do you have quality and review standards for agent code? (not sure, to check) Does your team own what agents produce? (not sure, to check) Does the whole team experiment and share? (not sure, to check)
Start with this: Rewrite your next ticket so an agent could do it without coming back with questions: goal, constraints, acceptance criteria and how to verify it. Agree as a team what agent code has to pass before review, and automate as much of that check as you can. Whoever started the agent is responsible for its change, exactly as if they had written the code themselves. Set up a short weekly slot where the team shows what worked with agents and what didn't.
Agent code needs a clear task, a review standard and a person who owns it. Without these habits, review becomes a rubber stamp and speed turns into rework.
TrainingsAgentic Engineering for Developers and QATrainingsAgentic Engineering for Product Managers and Product Owners
-
What leadership provides
Does your team have the best AI tools and time to learn? (not sure, to check) Do your agents have autonomy within enforced guardrails? (not sure, to check) Do you measure AI's impact? (not sure, to check)
Start with this: Give the team current tools, and build learning time into the plan instead of adding it on top. Decide which actions agents may take on their own, and enforce those limits technically through permissions and gates, not a policy document. Pick two or three measures you already collect, such as lead time from idea to first users and rework rate, and record a baseline now.
Tools, time and guardrails are decisions a team can't make for itself. Without them, adoption stalls on approvals, visibility and fear.
TrainingsAgentic Engineering for Engineering and Product LeadersTrainingsAgentic Engineering Security for Development Teams
Area by area
What your agents deliver
What already works
- Do your coding agents implement and ship routine tickets?
- Do you use AI across the whole software development lifecycle?
No yes in this area yet.
Your next step
- Pick one ticket type your team handles often and let an agent take it all the way from ticket to merged change, with a person reviewing.
- List the steps from refinement to operations where agents never show up, and try one of them on real work.
Nothing open here.
Why it matters
Delivery is where the time agents save reaches your customers. Without it, faster code changes nothing they would notice.
What your agents can see and run
What already works
- Do your agents get the context automatically?
- Do you maintain a shared agent harness?
- Can your agents run your system and improve it from feedback?
No yes in this area yet.
Your next step
- Write down what a new developer needs to know about your codebase, and put it where the agent loads it at the start of every session.
- Move the prompts, rules and tools each developer keeps privately into one repository the whole team maintains.
- Give the agent a way to start the system, run the tests and read the logs, so it checks its own work before a person does.
Nothing open here.
Why it matters
An agent is only as good as the context it gets and the system it can run. Without both, it guesses, and people end up checking.
How your people work with agents
What already works
- Can you write agent-ready tasks?
- Do you have quality and review standards for agent code?
- Does your team own what agents produce?
- Does the whole team experiment and share?
No yes in this area yet.
Your next step
- Rewrite your next ticket so an agent could do it without coming back with questions: goal, constraints, acceptance criteria and how to verify it.
- Agree as a team what agent code has to pass before review, and automate as much of that check as you can.
- Whoever started the agent is responsible for its change, exactly as if they had written the code themselves.
- Set up a short weekly slot where the team shows what worked with agents and what didn't.
Nothing open here.
Why it matters
Agent code needs a clear task, a review standard and a person who owns it. Without these habits, review becomes a rubber stamp and speed turns into rework.
What leadership provides
What already works
- Does your team have the best AI tools and time to learn?
- Do your agents have autonomy within enforced guardrails?
- Do you measure AI's impact?
No yes in this area yet.
Your next step
- Give the team current tools, and build learning time into the plan instead of adding it on top.
- Decide which actions agents may take on their own, and enforce those limits technically through permissions and gates, not a policy document.
- Pick two or three measures you already collect, such as lead time from idea to first users and rework rate, and record a baseline now.
Nothing open here.
Why it matters
Tools, time and guardrails are decisions a team can't make for itself. Without them, adoption stalls on approvals, visibility and fear.
Trainings for your priorities
-
Your whole team working with coding agents the same way.
- Software Engineers
- QA
- Analysts
-
From each engineer's own setup to one pipeline the team shares.
- Software Engineers
- QA
-
Specs your engineers' agents can build from.
- Product Managers
- Product Owners
- UX
-
Routine platform work goes to agents, and your team approves every change.
- DevOps
- SRE
- Platform Engineers
-
What to steer, what to measure, and what to leave alone.
- CTOs
- VPs
- Engineering Managers
-
Teams outside engineering hand recurring work to agents, and a person still makes the call.
- Marketing
- Finance
- Sales
- HR
- Service
-
Harden your agents, then use them to harden your code.
- AppSec
- Architects
- Software Engineers
Want a detailed evaluation from us?
Email us your result and we'll reply with our reading of your answers. Your result above is already complete.
Email us your resultYour next steps
- 1. Pick one ticket type your team handles often and let an agent take it all the way from ticket to merged change, with a person reviewing.
- 2. List the steps from refinement to operations where agents never show up, and try one of them on real work.
- 3. Write down what a new developer needs to know about your codebase, and put it where the agent loads it at the start of every session.
- 4. Move the prompts, rules and tools each developer keeps privately into one repository the whole team maintains.
- 5. Give the agent a way to start the system, run the tests and read the logs, so it checks its own work before a person does.
- 6. Rewrite your next ticket so an agent could do it without coming back with questions: goal, constraints, acceptance criteria and how to verify it.
- 7. Agree as a team what agent code has to pass before review, and automate as much of that check as you can.
- 8. Whoever started the agent is responsible for its change, exactly as if they had written the code themselves.
- 9. Set up a short weekly slot where the team shows what worked with agents and what didn't.
- 10. Give the team current tools, and build learning time into the plan instead of adding it on top.
- 11. Decide which actions agents may take on their own, and enforce those limits technically through permissions and gates, not a policy document.
- 12. Pick two or three measures you already collect, such as lead time from idea to first users and rework rate, and record a baseline now.
All your answers
| # | Question | Answer |
|---|---|---|
| 1 | Do your coding agents implement and ship routine tickets? | |
| 2 | Do you use AI across the whole software development lifecycle? | |
| 3 | Do your agents get the context automatically? | |
| 4 | Do you maintain a shared agent harness? | |
| 5 | Can your agents run your system and improve it from feedback? | |
| 6 | Can you write agent-ready tasks? | |
| 7 | Do you have quality and review standards for agent code? | |
| 8 | Does your team own what agents produce? | |
| 9 | Does the whole team experiment and share? | |
| 10 | Does your team have the best AI tools and time to learn? | |
| 11 | Do your agents have autonomy within enforced guardrails? | |
| 12 | Do you measure AI's impact? |
How the score works
-
0 to 6
Your team is at the start of agentic engineering
-
7 to 10
Your team works with agents
-
11 to 12
Agentic engineering is how your team works
Each yes scores one point, and not sure counts as no. The total is a rough guide; the individual answers tell you more.
Based on Semjon Mössinger's Agentic Joel Test (opens in a new tab), twelve yes-or-no questions on how ready a team's engineering practice is for agents, after Joel Spolsky's Joel Test. The questions are his.