--- title: "Working With AI · Inner Atlas" description: "A practical guide to using AI, as valid for beginners as for experienced developers. Insight into the mental models and workflows that lead to reliable results, and common failure modes to avoid." url: "https://www.inneratlas.co.za/field-notes/working-with-ai" author: "Matthew Ryan" published: "2026-04-21" --- *Field Note* # Working With AI Shaping intention, context, verification, and handoff into reliable workflows. 2026-04-21 · Matthew Ryan ## Core Thesis Working well with AI is about learning how to shape context, intention, scope, verification, and handoff so that the model becomes a piece of an intention-driven, adaptive workflow. AI cannot be the whole workflow. AI is a reasoning surface inside a workflow that needs to be continually realigned to your intention. AI does not have your underlying intention. Each interaction only activates a specific slice or lens of perspective. Good work comes from intentionally choosing the right frame/perspective for the current pass, preserving only what matters, and verifying that the output is aligned with the underlying goal. --- ## 1. Mental Model of ‘Context’ With each topic-specific, insightful answer, Ai creates this illusion that it has a comprehensive understanding across every layer of thinking. In reality, each pass is shaped by the framing, keywords, and context present in that moment, so only part of the available structure gets activated. That is how one reply can explain a flawless reasoning process for tackling a problem, what to avoid and how to order it, but the implementation can seemingly ‘forget’ all of that, and make the exact mistakes it just warned against. This mental model is vital when working with AI: You are not speaking to a mind that can hold the entire problem in view while working. The system is capable of very pointed, local reasoning, that only accounts for the context/perspective provided. The common mistake is asking AI to solve the whole problem at once. This creates an over-confident output that mixes research, design, implementation, and validation. Use separate passes for separate perspectives. * Retrieval mode: Find existing approaches, references, prior solutions, comparable patterns, or known constraints. * Design mode: Explore tradeoffs, structure, ownership, assumptions, and system decisions. * Execution mode: Make concrete changes under explicit constraints. * Verification mode: Look for brittleness, incompleteness, drift, regressions, and misalignment with the original intention. Core rule: Do not ask AI to critique, redesign, implement, simplify, and verify in one pass. --- ## 2. Start With Intention, Not Instructions Most weak AI work begins when we instruct before defining our intention. Don’t begin with commands. The intention, and updates to the intention, should be hand-written: “What should become true for the user or system?” ### Then clarify * What should happen? * What should not happen? (Potentially based on additions or proposals from ai research stage) * What existing behavior must be preserved? * What assumption would make this the wrong solution? * What change would make this issue obsolete? Remember: If you CAN’T clearly define the intended behaviour, you don’t actually know what you’re trying to build yet. The current task is then discovery of options, research, and critiquing from various perspectives, defining the depth of changes. AI can help clarify intention, but it should not rewrite it. It will often use similar-sounding words can change the actual goal, as well as bloat and drown the intention with unnecessary verbosity and prose, just to fill out it’s idea of what a ‘full’ document looks like. --- ## 3. Preventing Document Drift Document drift happens when the work starts optimizing for the wording of the plan instead of the underlying intention. Documents often gets longer, but each extra filler word increases the potential for misinterpretation in future work. The plan becomes self-justifying, and the original intention gets lost. “Similar” words get swapped in -due to the nature of LLMs- and mutate the intended goal. ### Prevention * Keep conscious, hand-written intention sections, which shouldn’t be interpreted as verbatim. * Where necessary, hand-write edits to the plan that have been revealed by new perspective passes. * Keep one intention-centred source of truth for the core goal. * Use AI to identify drift, not just improve wording. * Compress after exploration. * Preserve decisions and non-goals. * Update docs only after verification, not during work. ### Useful review prompt Review this from the perspective of the underlying intention. Where has the document drifted, repeated itself, or become loyal to its own wording instead of the underlying intention? Advise what to keep, cut, merge, or upgrade, only if truly necessary at all. --- ## 4. Always Assume 90% Competence When AI produces something flawed, or keeps ‘fixing’ bugs ineffectively, this is actually a helpful signal that some underlying assumption is being overlooked. Often the frame was incomplete, the intention was underspecified or logically flawed, or the task was designed from the wrong perspective. One-shot of a function should never be the goal. The friction of reiteration is fundamentally necessary, you need to keep iterating, steering back to your underlying intention, which is constantly evolving with the project. Assume 90% competence: treat friction as useful signal. Repeated issues in the same area often point to an underlying assumption, unclear ownership, weak contracts, or contradictory desired behaviour. ### Ask * Are we patching symptoms because the desired behaviour is unclear? * Is the issue local, or does it reveal a broken model of the system? * Would the proposed patch make the next change easier or harder to reason about? --- ## 5. Tests Before Code, Docs After Verification Often, tests are overlooked and just added at the end of an implementation. This creates tests that simple re-assert the existing code, even when that code or the underlying logic may be faulty. Tests should have a dedicated, intentional and separate lens from the code/doc. Tests that help cement the underlying intention can come before code, keeping the execution aligned with your intended behaviour. ### Three layers * Pre-code: intention tests. * During-code: implementation tests. * Post-code: reality checks, review and critique, manual smoke paths, then contract and regression tests. ### Recommended sequence 1. Write the intention in plain language. 2. Use workflow and core templates found below. 3. Ai writes intention-aligned tests. 4. Review and edit tests before implementation, realign with intention. 5. Create and implement task doc. 6. Run tests, type checks, lint, and a manual smoke path. 7. Review implementation look for missing edge cases (assume 90% competence) 8. Add post-code regression or integration tests. 9. Update docs according to new reality. --- ## 6. Handoffs and Compression After exploration passes per perspective, compress into only the helpful information that stood out to you. Because of how attention works, each pass is only reasoning against one slice of perspective/scope, but full docs are written or rewritten. The way it is written may make you believe you are missing something, but the ai-written doc only really encodes the new information from this perspective pass, the rest is good-sounding filler that confuses future work and makes it hard to reason about. This also applies to document written for teammates - do not paste the entire ai doc. Hand-write only what stands out as important. Remember, if you can’t clearly identify what matters and is worth keeping, neither can the person or ai that is reading it next. ### A good handoff is * Concise. * Self-contained. * Intention-bearing. * Constraint-aware. * Clear about what not to do. * Clear about what counts as done. --- ## 7. Common Failure Modes These are not isolated mistakes. They compound, becoming the working base for future context, code, docs and tests. ### 1. Unnecessary Confidence Bad pattern: “You are a senior engineer, make no mistakes.” - Actively degrades work, confidence increase hides real uncertainty/gaps. Better: ask for assumptions, gaps, brittle points, and verification paths. ### 2. Treating AI like a search box Bad pattern: asking for answers instead of shaping a reasoning process. Better: choose the mode. Retrieval, design, execution, and verification are different jobs. ### 3. Asking too broadly too early Bad pattern: “Build me an app.” Better: clarify user flow, data flow, constraints, non-goals, and acceptance criteria. ### 4. Letting AI write bloated docs Bad pattern: polished but unnavigable documents. Bloats your and ai’s context-window, unnecessarily. Better: intention first, compression later, docs updated after verification. ### 5. Skipping adversarial review Bad pattern: “Does this look good?” Better: “Where will this fail?” “What fundamental logic gap is being overlooked?” “What underlying structural shift would make this obsolete?” ### 6. Implementing before naming the actual behaviour Bad pattern: coding from vibes, then debugging contradictions. Better: name expected user/system behaviour first. ### 7. Writing tests after implementation and calling it validation Bad pattern: tests preserve mistakes. Better: write tests for intended behaviour BEFORE code. ### 8. Not preserving context, intention or decisions Bad pattern: revisiting the same ambiguity across chats. Better: keep compressed handoffs with decisions, constraints, and non-goals. --- ### 8. Practical AI work playbook The aim is not to have AI one-shot with ‘good’ prompting. The aim is to use AI in narrow, deliberate passes that each examine one layer of the work from one perspective. AI should be used to interrogate specific fields, assumptions, and decisions. The user keeps the governing document small, hand-authored, and updated only with information that has actually been explored and is worth preserving. Ai should fill a field only when it changes the next step, prevents drift, preserves a decision, or supports verification.Empty fields are allowed. Only fill or update a field that has been specifically, intentionally explored. Do not ask AI to complete the whole template in one pass. Use separate passes to clarify different parts of it. When a small, scoped change is clear: (one local surface is affected, preserve constraints are simple, no structural ambiguity and tests or manual verification are obvious). In this case, skip steps 3-7, move straight to implementation. ### This system is designed to reduce * literal misreads of intention * working on the visible, shallow issue instead of the real deeper one * premature structural changes * drift across long chats, documents, and handoffs --- ### 1. Minimal Template (human-authored) Raw Intention Dump (Not to be taken verbatim) What should become true? Current State What is happening now? Desired Behavior What should happen instead? Preserve What must not be changed/affected? Non-goals What should not be solved or reopened right now? --- ### 2. Intention interpretation pass ### Questions * What real change would be applied for this intention, if taken as written? * What user/system outcome is this trying to create? * What surfaces would be affected if implemented as written? * Is the desired outcome already clear enough to implement? * Does this issue actually exist as stated? * What important context may be missing? * What options have not yet been considered? * Is it the real source of pain, or a symptom of something upstream? * What change would make this issue obsolete? * What is the clearest decision-useful restatement? * Will this make future work easier or harder to reason about? ### Output * governing intention * credible target or likely symptom * real pain source, if different * interpretation risks * cheapest safe path * affected surfaces/concepts * recommended mode: one-shot / scoped / structural / discovery * decision-relevant ambiguity * expected effect on future work ### It should not * choose implementation * infer structure changes yet * generate tasks * commit to a local or structural solution yet --- ### 3. Structural Layer Discovery Pass ### Questions * At which layers of change COULD this issue actually be addressed? * What system change would reduce or eliminate this class of issue, and is that proportionate? * Is a related or higher system the true meaningful change-layer? * What alternative interpretations of the desired functionality should be considered? * What surfaces are affected by that layer change? * What adjacent behavior could be affected? * What would each layer make easier or harder in future work? ### Output * candidate structural change layers * mechanism of change at each layer * surfaces affected * regression risk * what each layer makes easier/harder for future work ### It should not * choose the best layer yet * justify the refactor by taste alone --- ### 4. Structural option critique pass ### Questions * What intention would make each structure change the correct decision? * Does this layer simplify future reasoning or make it less clear? * Does it reduce repeated pain or merely relocate it? * What new complexity, coupling, or migration cost does it introduce? ### Output * preferred change layer, if truly clear * why it serves the intention * why alternatives are worse * what must be preserved if this path is chosen Template Updates: - Scope - Constraints - Preserve - Non-goals - Acceptance Criteria --- ### 5. Failure mode pass Purpose: Find the most likely ways the current plan could look correct while still violating the real intention. Flesh out all not-yet-covered aspects into a clear, authoritative plan. ### Questions * How could this implementation satisfy the wording but miss the real outcome? * What existing behavior should not be broken? * What user expectation or experience could become less coherent? * Does this materially increase runtime, infra, complexity, or maintenance cost? * Does it improve or complicate user experience and cohesion? * Does it rely on narrow assumptions likely to fail later? * What shortcuts are tempting but would violate the intention? ### Output * false-success risks * template fields that were under-specified * likely regressions * shortcut failures to avoid * relevant non-goal updates Template Updates: - Scope - Constraints - Preserve - Non-goals - Acceptance Criteria ### It should not * Blindly overwrite existing valuable documentation or context. * Drift the document into this pass’ perspective, forgetting prior work --- Testing and execution ### 6. Intention-based test derivation pass Purpose: Derive checks from the governing intention and preserve constraints, not from the implementation shape. These should remain stable even if the code later changes. It should derive from the current template document, not existing/intended code. Output * intention checks * preserve checks * negative checks * smoke checks * manual verification paths if needed --- ### 7. Task derivation Only create tasks if multiple steps are genuinely needed. Do not create tasks when the work can be completed more clearly as a single coherent edit. AI often prefers creating tasks even when the issue could be solved directly. That creates doc drift and unnecessary management overhead. ### Rule Do not force task breakdown unless one of the following is true: * the work spans multiple surfaces * there are multiple dependent steps * structural change needs staging * verification depends on intermediate outcomes * the issue is large enough that one pass would likely lose coherence If tasks are needed ### Each task should contain * what specific change is made * why it matters * what surfaces it touches * Non-goals * Preserve * what completion looks like * all necessary context -and the overarching intention- must be listed within each individual task. Each task should carry enough context to be executed independently. --- ### 8. Implementation Implement one task at a time. --- ### 9. Review step Purpose: It should not exist as a guaranteed cleanup bucket that excuses weak implementation. It exists to independently check whether the completed work actually satisfied the governing intention. ### It should include * run intention-based tests * smoke pass * manual verification where needed * review pass ### Review pass should ask * Were shortcuts taken that should be addressed now? * Is any logic or testing stubbed, partial, or cosmetic? * Did the implementation drift from the governing intention? * Did it introduce unnecessary complexity? * What caused any failures found here? * unclear intention * new information discovered during execution * a deeper discrepancy than initially understood Output: A concise review summary covering: * shortcuts worth addressing now * stubbed logic or tests * drift from intention * unintended complexity * why these failures were created * recommended next action, if any --- ### 10. Documentation After review, documentation should be updated, aligned with the total current reality, not just the reactive fixes or optimistic intention.