AI native engineering workflow 67Verification and software quality 33
Heavy AI use with weak verification
Your answers put AI workflow in the stronger band and verification in the gap band. That combination makes proof of the result a priority.
Summary
Your reported AI workflow is ahead of verification.
Your answers put AI workflow in the stronger band and verification in the gap band. The next steps focus on showing that finished work meets the agreed requirements.
Where you are
Developing
The weighted answers sit in the developing range. Individual capabilities can be stronger or weaker.
- Exploring
- Developing
- Systematizing
- AI native
Indicative 40 of 100, weighted across the six capabilities. Stages are a guide, not a scientific classification.
Risky combinations
Where a strength is being undermined.
A risky combination pairs AI capability with a concern that can undercut it. These are raised from the evidence below whatever the average says. Gaps on their own show as orange bars in the profile.
AI native engineering workflow 67Delivery outcomes 33
AI adoption without better outcomes
Your answers put AI workflow in the stronger band and delivery outcomes in the gap band. Check pace, product quality and releases separately to understand the concern.
What to do next
Your top three opportunities
Ranked by the size of the gap, how much it matters to delivery, and what the other improvements depend on.
1Priority 1
Connect requirements to verification
Business intent and requirements 17Verification and software quality 33
Before expanding AI implementation, make sure every significant piece of work has acceptance criteria the business owner agreed to, and a test that proves each one. Until that exists, faster implementation mostly moves defects downstream.
First steps
- Pick one product area where rework hurts most.
- For new work there, write acceptance criteria before any agent runs, and have the business owner confirm them.
- Release only when each criterion has a passing test that would fail if the behavior were wrong.
2Priority 2
Watch outcomes, not activity
Delivery outcomes 33
No single number captures whether software is valuable and reliable, and every easy metric can be gamed. A few imperfect signals watched together over time still show the direction.
First steps
- For last quarter, note how long requests took to reach users, and which releases needed a fix soon after.
- Keep the same notes for the pilot area from day one.
- Review the trend with the business monthly. Never turn it into a target.
3Priority 3
Keep requirements with the code
Engineering foundations 50
Anyone changing an existing feature, person or agent, should be able to read what it is supposed to do. When they can’t, they guess, and the guesses turn into rework.
First steps
- For the system that changes most, write down what it is supposed to do and how it is built.
- Keep it in the repository next to the code, and update it as part of every change.
- Make sure every agent session reads it before work starts.
Capability profile
Where the organization stands today.
Strong 60 and abovePartial 40 to 59Gap under 40Unknown has no score
What’s working
- Your answers put AI native engineering workflow in the stronger band. Check the individual answers for anything the average hides.
Check your answers
Questions to take to your team this week.
Your answers are one person’s view. These check them against what actually happened, and work well in a team meeting. If the answers surprise you, that gap is itself a finding.
- Pick the last three features that shipped. Can someone show the acceptance criteria for each, and the test that proves it?
- Of the last ten releases, how many needed a fix or rework within a week?
- Which recent feature turned out not to be what the business wanted, and how late did we find out?
- When an agent changes our most important system, where does it learn what that system is supposed to do?
A 90 day plan
Start small, watch the outcome, then decide.
Not a wholesale transformation. One controlled pilot on the biggest bottleneck, judged against where you started.
First 30 days
Find out where you start
Note how long recent requests took to reach users and which releases needed a fix. Then take the first step of priority 1.
- Pick one product area where rework hurts most.
Days 31 to 60
Run the pilot
Carry out the remaining first steps of priority 1 in one area.
- For new work there, write acceptance criteria before any agent runs, and have the business owner confirm them.
- Release only when each criterion has a passing test that would fail if the behavior were wrong.
Days 61 to 90
Compare and decide
Compare against where you started. Write down what worked, drop what didn’t, and decide whether to extend it and start on priority 2.
Optional
A personal read starts with your own answers.
Take the assessment to request a second opinion on your results.
Your answers
Every answer, and the next step up
Your levelNext step upUnknown
Each bar has four levels. The outlined level is the next step, described on the right. It is one level up, not the top, because that is the change you can make next.
Business intent and requirements
Defining success
A ticket with a sentence or two. What done means gets settled in review, or after release.
Next step Larger work has a written spec the business agrees to, but without testable acceptance criteria.
Unclear business decisions
The developer, or the AI, makes a reasonable guess and moves on without telling anyone.
Next step Someone asks in chat or a meeting, and the answer stays in that conversation.
AI native engineering workflow
How much AI does
AI writes nearly all of the code, but requirements and design are still written by hand, or not at all.
Next step AI does the work at every stage, researching and drafting requirements and design, building, testing and reviewing. People decide what to build and approve the results.
A shared way of working
A shared method or skills library exists, but only some teams use it.
Next step The whole team works from one shared method, kept in source control and improved as the team learns, and new people start with it.
Building a large change
The plan is split into pieces an agent can finish confidently in a single session, and someone starts and watches each session by hand.
Next step Once the requirements and design are reviewed and split into pieces, an automated runner builds the whole change largely on its own, stopping only for a problem it cannot resolve.
Verification and software quality
Proving it meets the need
Manual QA or a general test suite checks it, but nobody maps the tests to the original requirements.
Next step Acceptance criteria are written down and many have a test, but some have none, and some tests would still pass if the behavior were wrong.
Checks before production
A person reviews the code, but passing automated tests is not required.
Next step Every change gets a code review, by AI, people or both, and the automated tests must pass.
Engineering foundations
What a feature should do
From the ticket, plus whatever a person points it to for that change, such as wiki pages, old tickets or documents.
Next step From standing requirements documents for that area that the person or agent can find and read on their own, maintained separately from code changes.
Path to production
Most changes go through automated builds, tests and deployments.
Next step Every change takes the same automated path to production, test environments exist for the systems you integrate with, and a bad release is caught and reversed quickly.
Governance and accountability
Security and approved AI use
Everyone uses company accounts on approved tools whose terms keep your code and data out of model training.
Next step Company accounts on approved tools only, and the machines agents run on can’t change production. Production changes go only through the release pipeline.
Holding the build to the ask
It comes down to what people remember from meetings, chats and tickets.
Next step The written requirements usually settle it, though the business owner did not formally approve them.
Delivery outcomes
Pace of delivery
Code gets written faster, but it waits on review, testing or rework before it reaches production, so the business sees little difference.
Next step Noticeably faster, and the business has noticed.
Product quality
Functional. It does what was asked in the most straightforward way, with little attention to the experience.
Next step Well designed. It is pleasant to use and thoughtfully put together.
Releases that break
I don’t know
Find out Count how many of the last ten releases needed a fix soon after they shipped.
Further reading
The Enso Method ↗
Open source skills for writing requirements, recording assumptions and proving acceptance criteria with AI coding agents.
DORA AI Capabilities Model ↗
Independent research on the practices that decide whether AI assisted development pays off.
Case study, the method in practice ↗
Four measured weeks of AI native delivery, including how the tests and acceptance criteria were kept.
About this report
This is a structured self evaluation based on how Enso Dynamics builds and delivers software with AI. It reflects what was reported, by one person, about normal practice. It is not an audit, it has not been academically validated, and it does not compare you with other companies.
Scores come from fixed rules, not an AI model. Each answer maps to a level from 0 to 3, each capability is weighted, and unknown answers lower confidence instead of counting as zero.
If you want help
A questionnaire sees what you report. A diagnostic sees how the work actually happens.
Engineering diagnostic
A short, scoped review of your real workflows, artifacts and constraints, through interviews and evidence, ending in a prioritized roadmap.
AI Native SDLC Transformation
Requirements first, the systems that do the building and the foundations underneath, with your team delivering a real project the new way.
AI Leveraged Technical Leadership
Senior technical leadership embedded in your business, directing AI agents to do the work that used to need a full team.
Results are yours either way.
Get in touch about an engagementAction counts record successfully received actions, not unique people. A network outage can leave an action uncounted.