Structured AI workflows: your team doesn't need better prompts – it needs structure
Marc GasserSoftware Entrepreneur · GTM & MarketingConnects AI with revenue operations and builds autonomous GTM systems for predictable growth.
TL;DR
- AI is an amplifier, not a magic fix: the 2025 DORA report shows AI magnifies the strengths of well-organised teams – and the dysfunctions of poorly organised ones. The difference isn't the tool, it's the structure around it.
- Three structures decide the payoff: curated context instead of ad-hoc prompts (input), an agreed division of labour between human and AI (process), and checkpoints with evidence (output).
- Unstructured AI use costs speed instead of adding it: METR measured developers 19 per cent slower, Stack Overflow 46 per cent distrust in AI output, DORA falling delivery stability. Automate bad input and you just ship the mess faster.
Key findings
- 84 per cent of developers use or plan to use AI tools – while 46 per cent distrust the accuracy of the output (Stack Overflow 2025). Adoption is solved; structure isn't.
- Structure doesn't mean bureaucracy: one page of context, one agreed spec and one defined checkpoint are enough to turn a private hobby into a system.
- The amplifier logic holds across the whole cycle: scattered context in discover, vague specs in define, unreviewed diffs in build and silent regressions in operate all get faster – not better.
Why does so little arrive despite all the AI tools?
Because most teams have introduced tools, but no structured AI workflows. The licences are there, the demos were impressive – and yet the quarterly report looks like before. The answer to “why isn't this working?” rarely sits in the model. It sits in the structure around it.
The numbers draw the picture precisely. 84 per cent of developers use or plan to use AI tools, reports the Stack Overflow Developer Survey 2025 with around 49,000 respondents. At the same time, 46 per cent distrust the accuracy of the output – more than trust it (33 per cent). Two thirds say AI answers are “almost right, but not quite”, and 45 per cent lose noticeable time debugging AI code.6
Maybe you know the everyday version of this: everyone on the team prompts alone. The same question yields three different answers depending on who asks. The good prompts live in private notes. And the coding agents deliver faster than they can be fed cleanly. The tools are there – a system is not.
The software consultancy Atomic Object has boiled this gap down to a simple formula: to get more out of AI, you need structure – not better tricks. This article takes that thesis seriously and shows what the structure looks like in practice.1
The thesis: AI amplifies your structure – or your chaos
This article's thesis in one sentence: AI doesn't make your team better, it makes it more of what it already is – which is why structure is the lever, not the next tool.
The 2025 DORA report (“State of AI-assisted Software Development”, close to 5,000 respondents plus over 100 hours of qualitative interviews) reaches exactly this conclusion: AI acts primarily as an amplifier. It magnifies the strengths of well-run organisations and the dysfunctions of the rest. Teams with mature processes deliver value faster with AI; teams mired in technical debt and process bottlenecks often get worse with AI, not better.3
That may sound sobering, but it is good news. It means the AI payoff is neither a lottery nor a question of the model. It is a function of decisions your team makes itself – about input, process and output. Or, put sharply: automate bad input and you just ship the mess faster.
Three structures decide which way the amplifier points. Structure in the input: what context does the AI get? Structure in the process: who leads, who decides? Structure in the output: how do you know a result is right? The next three sections work through them in order – from the lightest lever to the strongest.
Structure the input: give the AI curated context, not ad-hoc prompts
The first lever is the input. An AI without context guesses – politely, eloquently and often wrongly. Structured input means: the knowledge the AI needs for a task is curated and ready, instead of being improvised anew in every prompt.
Atomic Object shows what this looks like in practice in its own work: for technical due diligence engagements, the consultants deliberately feed their AI tools internal checklists, client documentation and example reports – it is this rich context that makes the answers relevant and usable. The prompt is short, the context is large. In most teams it is the other way round.2
The reusable form of this is skill files – one-page operating manuals an AI follows without follow-up questions: glossary, conventions, boundaries, desired output format. Written once, used by the whole team and versioned like code. Prompt quality moves from private notes into shared infrastructure.
The effect: answers become reproducible. The same question yields the same quality, no matter who asks. And the most expensive part of using AI – explaining the same context over and over – disappears.
Structure the process: agree where the AI leads and where humans decide
The second lever is the division of labour. Structured AI workflows define per type of task who leads: the AI drafts and the human decides – or the AI executes against a spec agreed up front. What never works: leaving both open.
That missing process structure genuinely costs speed has been measured. The 2025 METR study – a randomised controlled trial with 16 experienced open-source developers across 246 real tasks – found: with freely used AI tools, the developers were 19 per cent slower while believing they were 20 per cent faster. Without a defined division of labour, the good feeling replaces the effect.5
For the biggest type of task – software changes – the agreed spec already exists as a discipline: a spec locked down before the agent run. Discovery stays human, execution runs against the spec. When the rules are clear up front, the implementation doesn't drift – and logic bugs can be checked against the original intent instead of against guesses.
The same logic applies outside the code: who decides whether an AI answer may go into a customer email? From what size does a change need a review? Agreements like these take an hour of team time – and they are what separates a system from an experiment.
How such a division of labour is set up concretely in a PM's day-to-day – context files, plan mode, two-layer review – is shown step by step in the Claude Code setup for product managers.
Structure the output: demand evidence, not trust
The third lever is the checkpoint. An AI result only counts as done when it comes with evidence: tests that ran, sources that were checked, a review by the person who carries the consequences. Not because AI is bad – but because it can be convincingly wrong.
The Stack Overflow numbers explain why this is the most critical point: 66 per cent of developers say AI answers are almost right, but not quite – and it is exactly this almost-rightness that slips through without a checkpoint. The 45 per cent who lose time debugging AI code pay for the missing output structure afterwards, with interest.6
The checkpoint has to match the stakes. A text draft needs a read-through, a migration script needs a real review with tests. What matters is only this: the checkpoint is defined beforehand, not negotiated afterwards. “Looks good” is not a checkpoint.
How much of these three structures your team has today, you can check right below in two minutes.
Structure check: does AI amplify your strengths or your chaos?
AI is a private hobby in your team: everyone prompts alone, results vary. Start with one page of context per initiative and an agreed spec step.
Tick what genuinely holds in your team today – not what the playbook says. The result shows where your AI usage loses structure.
Where Teklens comes in
Teklens is built around exactly these three structures – as a layer on top of the tools you already use, not a replacement. The Context Engine reads Jira, Confluence and your real code and maintains a persistent product context from them: structured input that isn't recreated per prompt. It sends the AI only the relevant slice – more precision, lower AI costs.
In the process, Teklens works against agreed specs instead of shouted requests: decisions become specs and Jira tickets, and every specification is proven against your real code. In the output, quality gates provide the evidence – spec verified, PR checked, risk surfaced, with an approval trail. Whether that fits your setup is best checked honestly in a trial run on your own repo.
The strongest argument: what DORA measured across thousands of practitioners
Finally, the argument that carries the thesis. The 2024 DORA report (over 39,000 respondents) measured what happens when AI adoption grows without structure: for every 25 per cent more adoption, delivery stability dropped by 7.2 per cent and throughput by 1.5 per cent. Not because AI code is rubbish – but because AI makes larger change sets easy, and large changes without discipline mean more risk.4
A year later, the same research line delivers the resolution. The 2025 DORA report names seven foundations that turn the AI effect positive – among them a clear AI policy, a healthy data ecosystem, working in small batches and a user-centric focus. All structure, no model magic. Teams that work this way turn individual AI speed into organisational performance; the rest turn it into instability.3
And that closes the loop to the beginning. That so little arrives despite all the tools is not an AI problem but a structure problem – and therefore solvable without a single new tool. The difference between the teams where AI delivers and the others was never the model. It was always the structure it works into.
Frequently asked questions
What does “AI is an amplifier” mean concretely?
That AI magnifies existing patterns instead of replacing them: good specs get implemented faster, vague specs get implemented wrongly faster. The 2025 DORA report describes exactly this – AI magnifies the strengths of well-organised teams and the dysfunctions of the rest.
Where do we start if everyone currently prompts alone?
With the input: one page of curated context per initiative, shared and versioned. Then agree the division of labour per type of task, then define checkpoints. Keep the order – checkpoints without context only produce arguments.
Doesn't the structure slow us down?
The data says the opposite: METR measured developers 19 per cent slower with unstructured AI use, DORA falling stability as adoption grows without discipline. Structure costs minutes and saves the hours that otherwise flow into rework.
Do we need new tools for this?
No. All three structures – context, division of labour, checkpoints – can be built with what you have: a shared document, a team agreement, a definition of “done”. Tools like Teklens automate these structures afterwards; they don't replace them.
How do we measure whether the structure works?
By rework and stability, not output volume: rework rate, change-failure rate, time to first usable result. If stability rises at the same or higher speed, the amplifier points in the right direction.
Recommendations
- Start with one page of context per initiative. Collect glossary, conventions, boundaries and desired format in one shared document every AI session reads along. One hour of effort, immediately noticeable.
- Agree the division of labour in writing. Per type of task: AI drafts and the human decides, or the AI executes against an agreed spec. Put the agreement where the work happens – in the repo, not the wiki.
- Define checkpoints before the first run. Define per type of result which evidence means “done”: tests, sources, review. “Looks good” doesn't count.
- Share prompts and skills like code. Versioned, with an owner, visible to everyone. What stays private doesn't scale.
- Measure rework, not output. If rework or change-failure rate rises with AI usage, structure is missing – tighten the checkpoints. If they fall, you can open more classes of work to the AI.
- Start small, but start as a team. One pilot initiative with all three structures beats ten solo experiments. The amplifier works per system, not per person.
Scope & caveats
- The DORA results (2024: over 39,000 respondents; 2025: close to 5,000 respondents plus over 100 hours of qualitative interviews) are survey correlations and industry aggregates, not causal proof and not statements about your specific team. Use them as a warning signal and orientation, not a forecast.
- The METR study covered 16 experienced developers in large, mature open-source repositories using early-2025 models. The authors themselves stress that the result doesn't generalise to every context and that newer models may perform differently.
- The Stack Overflow figures are self-reports from around 49,000 respondents, skewed towards active community members – good for orders of magnitude, not for precision.
- Atomic Object is a software consultancy; the observations cited are practice experience from client projects, not a controlled study.
- The Teklens statements describe product capabilities, not measured customer results; pilot metrics are still pending.
Sources
Every external figure and quote in this piece – linked so you can verify it.
- 1.Atomic Object, Atomic Spin (2026) – spin.atomicobject.com/ai-you-need-structure ↗ – The piece that inspired this article: to get more out of AI, you need structure.
- 2.Atomic Object, «Leverage AI in Technical Due Diligence Engagements» (Atomic Spin) ↗ – Rich context – checklists, client documentation, example reports – makes AI answers usable in due diligence engagements.
- 3.DORA, «State of AI-assisted Software Development Report 2025» (Google Cloud) ↗ – Close to 5,000 respondents, over 100 hours of qualitative interviews; AI acts as an amplifier – of strengths and dysfunctions alike.
- 4.DORA, «Accelerate State of DevOps Report 2024» (Google Cloud) ↗ – 39,000+ respondents; delivery stability −7.2 per cent per 25 per cent more AI adoption.
- 5.METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity» (2025), arXiv:2507.09089 ↗ – RCT with 16 developers across 246 tasks: 19 per cent slower with AI tools.
- 6.Stack Overflow, «2025 Developer Survey» – AI-Sektion ↗ – 84 per cent usage, 46 per cent distrust in accuracy, 66 per cent “almost right, but not quite”.
The takeaway
Structure is the define work behind every AI payoff: curate the context, agree the division of labour, set the checkpoints. Build these three structures and your AI tools become a system – with the amplifier pointing in the right direction.
Keep reading in the PM Lab
Related deep dives – from the same pillar and the adjacent phases.
Matching use cases from the library
From the article straight into practice: these use cases put the concepts to work with Teklens.
No new piece without you.
New articles, new interactive tools, new evidence – in your inbox first. And when you reply, we reply: you write directly with the authors, not with a no-reply.
No spam, no sharing, unsubscribe any time.