Intent Before Implementation

The first three chapters established what machine coding is, what foundations to build on, and how to configure the intelligence that will do the work. This chapter is about what happens before any of that machinery engages: the moment when I do not yet know exactly what I want to build.

My starting position is deliberately strong:

If you can get it into words, the AI can build it.

That sentence describes my practical conviction after sustained machine coding, not a law of nature. Some ideas remain constrained by physics, by missing information, by permissions, by cost, by feasibility, or by the limits of available models — and producing an implementation is not the same as establishing that it works. Later chapters take up those constraints. But the traditional obstacle has substantially moved: translating an idea into source code is no longer the barrier it was. A developer can now explore an idea with a machine that helps develop the concept and can subsequently help implement it. Increasingly, I have found the ability to say what I want to be a more immediate constraint than the ability to write the code for it.

That changes the creative process. I no longer need to know exactly how to implement something before beginning to explore whether it should exist.

Start with the gap

My starting point is rarely a specification. It is usually a perceived gap: something does not exist, something works badly, something is unnecessarily difficult, two capabilities ought to be combined, or a problem looks solvable in a way that was not practical before.

A gap can take many forms — a repeated frustration, an inefficient workflow, a missing tool, an observation about how people behave, a technical possibility, a question existing software cannot answer, or a desire to make a process substantially better. I do not need to understand the complete solution. I need enough of an idea to start communicating.

There is a useful distinction here between knowing that something should exist and knowing exactly what form it should take. The first can be sufficient to begin. The shape emerges through the work this chapter describes.

Intent is personal

That starting thought comes from my own experience, imagination, interests, knowledge, and priorities — a technical irritation, a business opportunity, an artistic idea, simple curiosity. It does not need to be formalised prematurely as commercial requirements or a product specification, and at this stage it probably should not be.

The machine cannot supply that starting point for me. It can offer possibilities once I have one, but I must decide which possibilities are worth pursuing. The purpose of exploration is not to have the AI decide what ought to exist. It is to enlarge my ability to discover what could exist. My relationship with the problem is the compass; the machine is the means of surveying the terrain.

The AI’s tendency to converge

Anyone who has explored an idea with an assistant will recognise the following behaviour. Presented with an incomplete thought, the model responds with a proposed solution, a recommended architecture, a list of implementation steps, a project plan, a suggested stack — and an offer to begin coding.

Those responses can be useful, but they are often premature. At the start of exploration I may not yet know what problem should be solved or what the product should become, and a quick solution narrows the conversation before the interesting possibilities have been examined. I describe this as an observed tendency in assistant behaviour, not as any kind of deliberate strategy on the machine’s part: assistants are shaped to be helpful, and helpfulness too often takes the form of completion.

The skill is distinguishing exploratory conversation from convergent problem-solving, and knowing which one I am in. In exploration I need to be able to say, in effect: we are not building this yet; we are trying to understand what it could become. Completion is not progress here. Exploration is progress — and premature convergence is its quietest enemy.

Explore widely before narrowing

My preferred approach is to begin with the idea and supply as much relevant context as I can: the surrounding problem, existing solutions, related experiences, constraints, and possibilities. Then I ask the machine to go beyond my description rather than merely to execute it.

The directions I find most productive all interrogate rather than elaborate: What have I overlooked? What am I assuming? Is this the real problem or a symptom? Are there simpler approaches? What connected problems surround it? What could this become if the original limitations were removed? How would a different kind of user approach it? What would make it substantially more useful? What might invalidate the entire concept?

Sometimes the machine should challenge the idea, not extend it. This is a way of thinking and collaborating, not a repertoire of phrases to memorise. The measure of a good exploratory session is how much my understanding moved, not how much text was produced.

The greater of the two

Something distinctive happens in a good session, and it is worth naming. I bring intent, judgement, experience, preferences, and a sense of what matters. The machine brings a capacity to generate alternatives, connect related ideas, organise information, and explore possibilities I had not considered. My original concept may be incomplete; the machine’s first proposal may be unsuitable; and a subsequent exchange may reveal a third approach that neither of us initially expressed.

The desired outcome is something greater than my initial idea and greater than the machine’s initial suggestion — arrived at through interaction, then selected and refined by me. The machine should neither amplify my idea uncritically nor substitute its preferred direction for my judgement. I think of this as dreaming something into being, and I mean it practically: sustained, honest, iterative conversation that ends with a clearer and better conception than it started with.

Context is the raw material

None of this works if the machine does not understand what I am talking about. The raw material of exploration is context: my original motivation, the existing software and workflows, previous unsuccessful approaches, technical constraints, examples of desired behaviour, relevant research, existing project history, non-negotiable principles, and ideas already considered and rejected.

More text is not the same as better context. A large pile of irrelevant material obscures the problem rather than clarifying it; I have watched sessions degrade precisely this way. The objective is to enrich the machine’s understanding of the idea, which means curating as well as supplying. And as discoveries accumulate, I preserve the important ones — decisions, rejected alternatives, open questions — so that subsequent sessions do not reconstruct them from nothing. This habit anticipates the later chapters on repository context, workbenches, memory, and experience: exploration produces knowledge worth keeping.

Throw something against the wall

Eventually exploration needs contact with reality. That usually means asking the machine to produce something small and concrete: a sketch of an interface, a prototype, a simple data model, a sample interaction, a technical experiment, a simulation of a proposed workflow, a deliberately limited proof of concept.

The purpose is frequently not to begin final implementation but to discover what I actually want. A prototype can reveal that the original idea is less useful than expected — or that an unexpected corner of it is the valuable part. I distinguish building to learn from building to finish: a prototype may be discarded, and its value lies in the understanding it creates either way.

Exploration still needs decisions. Endless experimentation that never chooses is another failure mode, which I take up below. The prototype earns its keep when it produces enough clarity to select a direction.

Intent is not fixed

Traditional methodologies sometimes treat requirements as something to establish and then preserve. My machine-coding experience suggests a more fluid relationship: intent changes as I learn more about the problem and see what machines can build. The original idea may expand, contract, or change direction. A feature may reveal an entirely different product. An architectural limitation may prompt a better design. A disappointing prototype may expose a false assumption.

Changing intent is not automatically a failure of planning. It can be evidence that the human and the machine are discovering a better product together.

The qualifier matters. Productive evolution must be distinguished from uncontrolled scope drift: an idea should change because new understanding justifies the change, not merely because the machine suggested another feature. That is why preserving the reason for a change matters as much as recording the change itself. I need to know not only what the current intention is, but why earlier intentions were revised or abandoned — otherwise the same discarded directions return wearing new wording.

ALIVE — a changing intention

ALIVE is the example I can document rather than merely remember, because its direction changed in dated, inspectable steps.

The earliest commits, from 26 October 2026, show a persistent runtime with a dashboard and browser integrations, a First Contact qualification, an identity and event log, and a cognitive loop design with attention handling and model-driven investigation, evaluated under frozen comparisons with spending governors. The early emphasis was bounded autonomous cognition, semantic experience, and measured evaluation — an engine for doing work, with the learning question as its stated horizon. The present README still carries that horizon honestly: experience retrieval demonstrated, consistent quality improvement not demonstrated.

What development then taught is also on the record. Independent audit findings required corrections to credential handling and invocation lifecycle; a full adaptation comparison recorded negative results rather than burying them; evaluation limits were written down instead of explained away. None of that was planned, and all of it redirected effort — though I should be precise about what kind of change each item represents.

The genuine change of intention is the shift in what the product was understood to be. The early work emphasised bounded autonomous cognition and measured evaluation: an engine for doing work, judged by what its models could accomplish under governors and frozen comparisons. The 3 November charter reframed the endeavour around a different purpose: a persistent intelligence environment where work and its accumulated understanding endure across conversations, models, and restarts — the work primary, chat secondary, continuity itself the product. I cannot point to a single document as the exact moment that understanding changed; charters ratify thinking that developed during the project’s early work — audit findings, negative results, restart friction compressed into days. But the direction of travel is documented: from what the models can do, towards what the work retains.

The 30 October separation of the production runtime from the research harness belongs in a second category: an architectural decision consistent with the emerging separation of production work from research — one system for real work, another for experiments, each with its own rules. I describe it as consistent with the direction rather than caused by the later charter, since the documents do not establish that causal sequence; it is what the emerging purpose called for in the structure, and it should be read that way round.

The 4 November DEMO-01 correction belongs in a third: an evidence-driven narrowing of what a demonstration could claim. The programme’s protocol (version 2, dated 4 November, explicitly distinguished from an earlier unrelated DEMO-01 series) dropped the claim of producing an improved document, because the implemented route produces review items, not a recoverable revised document — the scope was corrected rather than defended. That is a correction to an acceptance claim under evidence, and the record says so; I do not present it as a change in what the product is for.

I keep these categories separate. What was originally wanted: a persistent place for real work with evidence, and an answer to whether experience improves subsequent work. What was discovered: audit findings, negative results, and the realisation that continuity itself was the product. What changed in stated direction: the work-primary charter with its acceptance demonstration. What followed architecturally: the production–research split. What is implemented: runtime, dashboard, workflows, independent review. What remains ambition: the charter’s destination and the learning proof. The sequence is documented in commits and dated papers, not reconstructed from memory — and additional functionality along the way should not be confused with genuine changes of intention.

A practical exploration session

An abstract account only goes so far, so here is the shape of a session — reconstructed and simplified, not a transcript, and with the machine allowed to be ordinary rather than brilliant.

I begin with a gap: reviewing long documents, I keep losing track of which claims I have already checked and what changed since. “I waste time re-verifying passages in revised reports. I want something that remembers what was checked.”

Premature convergence would reply with an architecture and an offer to build. Collaborative exploration replies with questions: What does “checked” mean — read, verified against a source, or approved? Where do the documents live, and in what format? Is the unit a passage, a claim, or a figure? Would you trust a machine’s verdict, or do you need to see the evidence yourself? What did you try before, and why did it fail?

Suppose I answer: I need the evidence, not the verdict; documents are versioned reports; the unit is the claim; a previous spreadsheet failed because nobody maintained it. The machine’s first instinct is a status ledger: every claim marked checked, pending, or failed. I push back — a status without its supporting evidence is exactly the spreadsheet nobody trusted, and a green badge I cannot audit is worse than no badge at all. The machine reconsiders: what if nothing is ever marked checked, and the system only ever shows the evidence or its absence? From there it offers three interpretations: a claim ledger bound to document revisions; a diff-driven recheck that only surfaces changed claims; a review queue that assigns verification as work. It challenges one assumption — that every claim needs equal scrutiny — and asks which failures would be costly.

The idea that survives is narrower and more valuable than my opening sentence: recheck only what changed, against pinned sources, with the evidence attached — and say plainly when evidence is missing. I did not arrive with that design, and neither did the machine’s first response. The machine supplied alternatives and objections; I supplied the judgement about which failure mattered, including rejecting its own first proposal. Better exploration changed what I chose to build.

The exploration-to-implementation boundary

Exploration earns its keep through understanding, not necessarily through building. A session may end with a better idea, a narrower problem, an informed rejection, an identified uncertainty, a deliberate decision to defer, or a small experiment that reveals what to investigate next. Any of these can be worth more than a hasty implementation. The distinction that matters is not between building and failing to build; it is between accumulating conversation and acquiring useful understanding. When exploration has produced enough clarity to select a direction, that is the moment to choose — and to record the choice: the gap, why it matters, who benefits, the broad desired behaviour, the alternatives considered, the constraints and uncertainties, a provisional direction, and the questions still open. That record is the beginning of an implementation specification — not yet a complete one, but recognisably its ancestor.

The handoff matters in both directions. The designers and implementers who follow should not silently replace my purpose; they work from the recorded intent, and the acceptance criteria trace back to it. Conversely, when implementation reveals new possibilities — and it will — those return to the intent conversation rather than entering the product as unapproved changes. The boundary is permeable to learning and closed to drift.

The Intent Record

I keep this lightweight: a short Markdown document, a thinking aid rather than a bureaucratic gate, cheap enough to revise when I change my mind.

The gap: what problem or opportunity started this?

Why it matters: why do I want to solve it?

Current intention: what is the product expected to become?

Explored possibilities: which alternatives were considered?

Decisions: what was chosen, and why?

Open questions: what remains uncertain?

Changes in intent: what changed, when, and why?

Next exploration: what should be investigated before implementation?

If maintaining it becomes a burden, simplify it; a stale record that nobody trusts is worse than a brief one that stays current.

When exploration goes wrong

The failure modes are recognisable once named. The machine agrees with everything, and flattery replaces challenge. Convergence arrives before understanding. I fall in love with the first workable prototype and stop exploring. Sessions multiply without decisions. Context piles up until the actual problem is buried. Generated suggestions get treated as verified facts. The project expands without regard to cost. The machine’s changes quietly abandon the original purpose. Earlier decisions are forgotten and endlessly relitigated.

Recovery is usually the same movement: return to the gap and ask whether the current direction still addresses it. If the record shows why each turn was taken, that question has an answer; if not, reconstruct it before proceeding. The Intent Record exists for exactly this moment.

Intent keeps moving

This process is not confined to the project’s beginning. A project cycles through exploration, design, implementation, review, and operation — then returns to exploration when new information appears. I have spent weeks discovering better formulations of an original idea long after implementation started, and that is not a defect in the method.

It is also not inconsistent with the Foundation Charter. Foundations provide stability while purpose and behaviour develop: I can reconsider what the product should become without renegotiating the database or the deployment. Sometimes a genuinely new intention justifies revisiting those foundations too — the distinction is between changing a decision deliberately and letting the machine change it accidentally.

Communication becomes creation

Describing something to a sufficiently capable machine is becoming part of creating it. I bring an intention into language; the machine helps explore, challenge, and enlarge it; experiments reveal what works; the intention itself changes; and eventually that intent becomes a design, and the design becomes software.

That is an extraordinary opportunity for people with ideas who do not wish to devote their lives to manually implementing every detail — and its limiting factor is increasingly the quality of the communication, exploration, judgement, and verification surrounding the machine.

If you can get it into words, you have already begun building it.

What remains is turning that discovered intent into information and direction a coding machine can use: the system it must understand, the contracts it must honour, and the evidence it must produce. That is the subject of the next chapter.