Overview
A set of lightweight, account-agnostic AI Native Engineering (AINE) plays that individuals and teams can adopt to improve their AINE processes or overcome common problems. They come from interviews with Nearform accounts that have AINE embedded in day-to-day delivery, varying in size, type of transformation and how long they had been running. It is not a complete list.
How to use it. Go straight to the plays, or use Frequent challenges to find the plays that match what you're experiencing. Each play gives an overview and the challenge it addresses, then its benefits, costs and points for consideration where relevant.
Six plays at a glance
Where the plays sit in the flow
From intent arriving to a change published for review. Four plays sit on the flow. One governs the size of what moves through it, and is decided at planning, before the spec is written. One sits outside the flow entirely, feeding back into how the team runs the whole thing.
Human in the loop. The loop above each handoff marks a point where a person can step in: check, correct or redirect the work before it moves on. People are not only at human review; they can input at every stage.
Frequent challenges
These are challenges frequently raised during the interviews and playback sessions. If any sound familiar, the plays beside them may help.
| Challenge | Plays |
|---|---|
| 🌫️It isn't clear what's in scope or the value the work is meant to deliver, and AI frequently makes its own assumptions about scope. | Define intent for its audience |
| 🪨Changes arrive too large to review properly, and key information gets missed. | Size work with review in mind |
| 🤔Engineers can't explain what was built a few weeks later. | Size work with review in mind |
| 🔀What gets built doesn't match the scope agreed in planning. | Capture work as a spec |
| ✏️Requirements change unexpectedly during build, test or review. | Capture work as a spec |
| 🔁You keep making the same corrections to AI output to match your team's standards. | Establish the right context |
| 🎯The code you review doesn't match expectations, and more time goes on rewriting than reviewing. | Establish adversarial responsibilities |
| 🙈Good practice stays with one person, and others end up rediscovering it. | Surface what the team is using to build |
| 🎲Output varies noticeably depending on who did the work. | Establish the right contextTeam operational considerations |
Plays in detail
👥Define intent for its audience
The play. Capture intent in a format that is readable, consumable and appropriate for each audience. Where work has more than one audience, such as people and AI, tailor the intent to each one's needs.
The challenge. It isn't clear what is in scope or the value the work is meant to deliver, and what AI produces isn't what was expected. Often the intent was written for only one audience. Written only for the AI, it becomes a wall of detail people can't follow. Written only for people, it carries the value and the why but not the specifics, so the AI fills the gaps with its own assumptions.
🧱Size work with review in mind
The play. When sizing a piece of work to hand to AI, consider the effort to review it, not just the effort to build it. Keep each piece small enough for a person to review and understand, and if a piece can't be split, build and review it in parts. Sizing is the mechanism; understanding what you are shipping is the point.
The challenge. Changes are arriving faster and larger than anyone can review properly. What would have taken days to build now takes hours, but it is still days of change to be reviewed. Key information gets missed, or the review gets left to AI instead. Over time, engineers become unfamiliar with their own work, and both knowledge and quality suffer.
📋Capture work as a spec
The play. At the end of planning, before moving to build, capture the agreed scope as a spec: a durable artefact written as AI intent. Hand it to the build phase so it builds what is expected, then pass it on to test and review so they can check the work against the intended scope.
The challenge. Planning with AI often means long conversations full of back and forth, where assumptions are made quietly and details get muddled. When that conversation is carried into the build, AI builds on those assumptions and misunderstandings. AI is also focused on finishing the task, so requirements can end up being changed to match what was built or tested, rather than the other way round. What you can end up with is AI output that doesn't match what was expected, with no clear understanding of why.
🗺️Establish the right context
The play. Before AI starts work, give it a shared set of your conventions, rules, decisions and best practices. Keep it short and focused on what matters most, share it across the team so everyone works from the same base, and review it as AI models improve, since guidance written for an older model can hold a newer one back.
The challenge. You find yourself making the same corrections to AI output again and again to match your team's standards, and the output varies depending on the prompt and details it was given. Across a team, the effect multiplies: each person gets noticeably different results, and more and more time is spent fixing the output. Usually it's because AI doesn't have your conventions, rules, decisions and best practices.
🕵️Establish adversarial responsibilities
The play. Limit the information shared between each stage: plan, build, test and review. Give each stage clear responsibilities, so it focuses on what it needs to do and isn't influenced by the stages around it. This can be done by hand, at individual scale or at team scale, as the Levels below describe.
The challenge. The code you're reviewing doesn't match your expectations, and more time goes on rewriting than reviewing. Assumptions made at each stage of plan, build, test and review have compounded, often because information, or misinformation, was carried from one stage to the next in the same AI conversation. The conversation that planned the work is the worst place to build it, and the conversation that built the work is the worst place to test it.
Three levels of implementation:
How it works. Start a new AI conversation for each stage, passing on only the key information. Take the agreed scope and criteria from planning (ideally a spec) into a new conversation focused on building it. Then take the build output into a new conversation focused on testing, and so on. Give each conversation a clear responsibility so it stays focused on its own role: the build conversation builds to the agreed requirements, and the test conversation makes sure every criterion is fully met.
How it works. Build on Level 1 by automating it. Instead of starting each fresh conversation by hand, set up an agentic workflow where a separate sub-agent handles each stage. Each starts with fresh context and has its own defined responsibility, and the key information is passed between them automatically, so nothing relies on someone remembering to hand it over.
How it works. Scale Level 2 to the whole team. Define one shared agentic flow, with a sub-agent for each stage, that everyone runs the same way, typically triggered automatically. It gives the team the same process whoever is working.
🔦Surface what the team is using to build
The play. Give the team a way to see what its members have made and are using, fitted into a ceremony that already exists, such as a retro or a show-and-tell, and/or a shared repo where people store what they've built so others can easily find and adapt it. The aim is visibility, not forcing everyone to work the same way.
The challenge. Someone on the team has worked out a better way of using AI, but nobody else knows about it. Their prompts, reusable instructions, context and harness optimisations live on their own machine, so good practice gets rediscovered rather than shared, and the team misses out on what is already working.
Team operational considerations
An emerging insight, with limited data behind it. This came out of the playback sessions rather than being tested across the interviews, so the evidence is thin. It is aimed at Tech Leads, not at everyone. Treat it as a direction worth trying, not a settled practice.
AI can be tailored in many ways: the choice of model or model family, skills, prompts, context and harness optimisations. For individuals this brings real benefits, but across a team, a difference in any one of these can cause large differences in output. For example, a small number of findings from the playback sessions showed team members using different model families, such as Anthropic and OpenAI, producing specs structured differently and code in different styles. Individual optimisations like these can produce output that affects the rest of the team.
The consideration. If output starts to vary across the team, these are areas that should be assessed:
- The models. Different models, or model families, produce different output.
- The harness. Different AI tools and setups shape output in different ways.
- How specs are created. A defined, shared format and content standard keeps specs consistent across the team.
Was this useful?
If you can spare two or three minutes, feedback on whether this has been informative, and whether the plays are practical for your work, would be really helpful in shaping the next steps. Responses are anonymous, but you'll need to be signed in with your Nearform account to open the form.
Give feedback ↗