AI readiness radar: Framework for engineering teams

Skip to content

AI readiness radar

Hot take: AI isn’t going to save your dysfunctional engineering team… it’s going to expose it.

Rather than being a silver bullet that fixes weak engineering practices, it’s going to accelerate what is already there, both the good and the bad. In a mature engineering culture it can help with shipping safely at pace, but for an immature team it’s going to amplify dysfunction meaning you ship more of the wrong thing faster (AI generated slop at scale). The teams that benefit most from AI development workflows aren’t the ones adopting the tooling the quickest, they’re the ones who have the foundations in place that allow it to work!

So before you (or your team) jumps straight into picking up AI coding agents, it’s worth actually asking "are we really ready for AI?"

That’s what my AI readiness radar is for. I’ve created this to help teams self assess their foundations so that they can know whether it’s the right time to add AI or if it’ll just cause a mess.

The five AI readiness signals

1. Codified standards

Has the team expressed what good (and good enough) looks like in the form of meaningful documentation, rather than it living in people’s heads or by convention?

Definition of done

Engineering guidelines

Non-functional requirements

Security standards

Quality statements and philosopies

Coding practices and standards

Testing best practices

System documentation

Architectural decision documentation

Product direction and market fit documentation

User stories

AI needs context in order to produce useful outputs. Without documented standards it has nothing to base work from and the code and product it generates drift away from what you’d intended it to do. In practice that means teams end up hand holding the AI through every single step to compensate for that (slowing them down massively). The goal here isn’t documents for their own sake, but to capture the team’s view of what good looks like enough that it can be consistently applied by a person or an AI agent.

2. Feedback loops

Has the development pipeline got meaningful tests and observability throughout that catch failure and regressions that AI development introduces?

Shift left testing (risk analysis and testing of ideas and user stories or specs)

Inner loop (short feedback loop tests during development)

Outer loop (deployed environment and integrated system tests)

The right tests (and coverage) throughout the stack

Shift right testing (observability and customer feedback tests)

Tests that are trusted and not flakey

"You break it, you fix it" team mentality for managing tests

Automated over manual testing running in a pipeline

Exploratory testing

Non-functional testing

Snapshot and UX tests

KPI and DORA metrics

Faster development only helps when you know when something is going wrong. Without meaningful feedback loops, faster development can easily introduce failures like regressions, bad behaviour changes and unmaintainable code patterns in a way that’s expensive to fix. This can happen at pace with AI causing problems too quickly for anybody to reasonably spot and remediate manually, which is why trusted and deep testing coverage is needed.

3. Trusted reviews

Do teams have the capability and capacity to meaningfully review the outputs of software development, rather than just rubber stamping things?

Mature Pull/Merge request reviews

Engineering capability, knowing what good looks like

Agreed standards and guidelines for coding and engineering

Product team reviews against company needs

Quality evaluations (validation and verification)

Short review lead times and turn around time

Low ego review processes (what works rather than personal preferences)

Team pragmatism to know what good enough is, rather than gold plating

Human review becomes the central control in your AI development process; without it there’s no governance on whether what’s being shipped is good and teams start to lose an understanding of their own code and product. Reviews that are slow, inconsistently applied or ego driven create a bottleneck that cancels out any speed gains from adding AI. From what I’ve seen, the quality of human in the loop reviews matter as much as their existence because a rubber stamp can be pretty much useless for quality when working at pace.

4. Quality ownership

Has the team taken on quality as a whole team concern or is there siloed thinking where quality is thrown over the wall for someone else to think about?

Quality engineering practices

Engineers owning their own testing

No trade offs to other teams

Quality capability, knowing what needs testing

Short turnaround time on fixes

Psychological safety to raise and own quality issues

Pragmatism to avoid gold plating

Team owned test environments

AI development really does remove the traditional QA phase and gatekeeping. If development teams are treating quality as someone...