← Donecraft, the book ← Donecraft for AI

The complete map

21 ways AI coding creates risk — and the Donecraft response to each

Grouped into six categories. Expand any item for the problem, the response, and where to read more.

These responses are implemented in OPIR, Donecraft’s open-source project runtime.

View OPIR on Codeberg →

Context loss

Large prompts and long autonomous runs bury requirements, mix old and new decisions and encourage agents to guess what is missing.

01Context grows until the agent loses what matters

The problem

As a session lengthens, the prompt fills with earlier exploration, discarded approaches and restated instructions. The agent has no reliable way to tell which parts still matter, so relevant constraints quietly lose weight against noise.

The Donecraft response

Outcome loops are scoped narrowly and re-briefed for each attempt, so an agent works from a fresh, bounded context instead of an ever-growing transcript.

See how OPIR addresses this →
02Small errors accumulate during long autonomous runs

The problem

An agent left running unattended builds on its own earlier mistakes: a wrong assumption in step three quietly shapes steps four through forty, and nobody catches it until the output is reviewed as a whole.

The Donecraft response

Donecraft caps how much an agent can do before a human-checkable outcome is due, so errors surface after one small step rather than after a long unsupervised run.

See how OPIR addresses this →
03Missing inputs are silently converted into assumptions

The problem

When a requirement, credential or design decision is missing, an agent under pressure to produce output will often invent a plausible substitute rather than stopping to ask.

The Donecraft response

Donecraft requires inputs to be explicit before an outcome loop starts; a genuinely missing input becomes a blocked, visible gap instead of a silent guess buried in the code.

See how OPIR addresses this →

Comprehension debt

A codebase can grow faster than the responsible humans’ ability to explain, diagnose and safely modify it.

04Comprehension debt grows invisibly

The problem

Every AI-generated file that nobody on the team fully reads adds to a balance of code the organisation cannot explain. Unlike technical debt, it rarely shows up in metrics until something breaks.

The Donecraft response

Each outcome loop requires a named owner who can account for the result, keeping comprehension distributed across the team as the codebase grows rather than concentrated in a transcript nobody re-reads.

See how OPIR addresses this →
05Senior developers become cleanup systems

The problem

As more code arrives faster than it can be understood, experienced engineers spend their time untangling agent output instead of designing systems — their judgement used reactively instead of up front.

The Donecraft response

Donecraft puts senior judgement into defining the result and the boundaries before generation starts, so review confirms known-good work rather than reverse-engineering what happened.

See how OPIR addresses this →
06Junior developers become prompt operators

The problem

Without a structured way to break down work, junior developers default to relaying prompts back and forth to an agent, gaining fluency with a tool but not with the system they are supposedly learning.

The Donecraft response

Bounded outcome loops give junior developers a real unit of ownership — defining a result, checking evidence, accepting or revising — building judgement, not just prompting habits.

See how OPIR addresses this →
07Small changes require rediscovering the whole project

The problem

When context and rationale are not preserved, even a one-line change can require an agent — or a human — to re-explore the entire codebase to figure out what is safe to touch.

The Donecraft response

Traceable outcomes and linked decisions mean a change can be scoped against recorded intent, not rediscovered from scratch every time.

See how OPIR addresses this →

Tests that prove the same mistake

When one agent writes both code and tests, both may validate the same incorrect interpretation.

08Code can be syntactically correct but semantically wrong

The problem

Generated code can compile, run and pass a shallow check while still doing the wrong thing — the failure is in meaning, not syntax, and syntax-level checks cannot see it.

The Donecraft response

Donecraft defines the result in terms of observable outcomes, not code shape, so acceptance is checked against what the system should do, not whether it merely runs.

See how OPIR addresses this →
09Tests can validate the same misunderstanding as the code

The problem

When the same agent produces both implementation and tests from the same prompt, the tests encode the same misreading of the requirement — green tests, wrong software.

The Donecraft response

Verification is assigned independently of implementation, so a second interpretation has to agree with the first before an outcome is accepted.

See how OPIR addresses this →
10Human review becomes ceremonial

The problem

Faced with a large, fast-arriving stream of generated code, reviewers rubber-stamp pull requests they cannot realistically re-derive, and review turns into a formality rather than a check.

The Donecraft response

Small, bounded outcome loops with explicit evidence keep each review scoped to something a human can actually verify in the time available.

See how OPIR addresses this →

Architecture and coupling drift

Locally plausible changes can create hidden dependencies, duplicated rules, incompatible interfaces and system-wide fragility.

Read the full coupling guide →
11AI coding is local, while software is systemic

The problem

An agent reasons about the file, function or prompt in front of it. Software behaves as a system of dependencies that extends far beyond that boundary, so a locally correct change can be a systemically wrong one.

The Donecraft response

Donecraft scopes each attempt to a controlled code surface and verifies integration separately, so local plausibility is checked against system-level effects before acceptance.

See how OPIR addresses this →
12Multiple agents can multiply inconsistency

The problem

Different agents — or the same agent in different sessions — reach for different patterns, names and interfaces for the same concept, and each choice looks reasonable in isolation.

The Donecraft response

Donecraft treats architectural boundaries as part of the outcome definition, so agents are told which interfaces and concepts are already fixed instead of reinventing them.

See how OPIR addresses this →
13AI encourages duplication and unnecessary abstraction

The problem

Generating new code is cheaper than finding and reusing existing code, so agents default to writing a new version instead of extending what already exists, quietly multiplying near-duplicate logic.

The Donecraft response

Bounded code surfaces force an explicit decision about what an outcome may touch, making reuse of existing, stable code the visible default rather than an afterthought.

See how OPIR addresses this →

Security and supply-chain exposure

Generated code may introduce insecure patterns, unverified packages, stale APIs, excessive permissions or prompt-injection paths.

14Security defects can look professionally implemented

The problem

An agent can produce code that looks idiomatic and well-structured while still containing a real vulnerability — confident style is not evidence of secure design.

The Donecraft response

Security verification is a distinct, required check in the acceptance evidence, not an assumption inferred from how polished the code looks.

See how OPIR addresses this →
15Hallucinated packages and stale APIs create supply-chain risk

The problem

Agents sometimes reference packages that do not exist, or call an API the way an older version worked, introducing dependency-confusion risk or silent breakage.

The Donecraft response

Dependency and API changes are part of what gets verified before an outcome is accepted, catching non-existent packages and version drift before they ship.

See how OPIR addresses this →
16Repository content can become prompt injection

The problem

Text inside issues, comments, files or third-party content that an agent reads can contain instructions aimed at the agent itself, not at the human user.

The Donecraft response

Donecraft limits what authority an agent carries into any given task and treats repository content as data to verify, not instructions to trust.

See how OPIR addresses this →
17Safety-critical code cannot rely on plausible output

The problem

For code where a mistake has real consequences, “the output looks right” is not a sufficient basis for trust — plausibility and correctness are different properties.

The Donecraft response

Donecraft requires independent evidence before acceptance for every outcome, so safety-critical work is held to the same verified standard regardless of how confident the output looks.

See how OPIR addresses this →

Weak traceability

Without links between outcomes, decisions, evidence, commits and files, nobody can reliably explain why generated code exists or rerun only the affected work.

18Models, tools and APIs change over time

The problem

The model, tool version or API behind a piece of generated code keeps changing after the code is written, and without a record of what produced it, nobody can tell what might now be stale.

The Donecraft response

Every outcome is linked to the decisions and inputs behind it, so when an underlying model or API changes, the affected work can be identified and re-verified instead of guessed at.

See how OPIR addresses this →
19Generated code becomes detached from its rationale

The problem

Code can survive long after the reasoning that produced it is forgotten, leaving future maintainers unable to tell whether a given line is a deliberate decision or an artifact of a prompt.

The Donecraft response

Donecraft links commits and files back to the outcome and decision that produced them, so rationale stays attached to the code instead of evaporating with the chat session.

See how OPIR addresses this →
20Activity metrics create a productivity illusion

The problem

Lines written, commits pushed and tasks closed all rise sharply with AI assistance, creating an impression of progress that is not the same as verified, working capability.

The Donecraft response

Donecraft governs against whether outcomes are accepted with evidence, not against how much activity occurred, so the productivity signal reflects real progress.

See how OPIR addresses this →
21Governance arrives after the dangerous decisions

The problem

By the time a generated change reaches formal review, the consequential decisions — what to build, which interfaces to use, what to assume — were already made inside the agent’s run, often invisibly.

The Donecraft response

Donecraft puts definition and boundaries before generation, so governance applies to the decisions that matter while they are still open, not after the fact.

See how OPIR addresses this →