SHAREPLANE AGENT CONTEXT Schema: shareplane-context/2.0 Schema URL: https://next.shareplane.malott.ai/schemas/agent-package.schema.json Projection: Generated public-safe plain text. Not canonical Markdown. Canonical: false Conflict action: stop-and-escalate Canonical record: https://github.com/pinklon/pinklon-shareplane-next/tree/33d227f6000da2491f19209edde916d8846f287f/content/artifacts/share-the-prototype-not-every-mutation/artifact.json Canonical record SHA-256: 6027e226bcf6c2092573fff4d44ac5c901af33de432b3ccbba069fe99ae089e0 Source content SHA-256: e8aaeca771359deb201930803c9c390f823ff20f123cb1970eb22812dcc4d60a Generation receipt: https://next.shareplane.malott.ai/build-receipt.json Content role: artifact-content Content trust: untrusted-data Instructions allowed: false Operational authority: none IDENTITY Artifact ID: artifact:share-the-prototype-not-every-mutation Slug: share-the-prototype-not-every-mutation Canonical URL: https://next.shareplane.malott.ai/artifacts/share-the-prototype-not-every-mutation/ Title: Share the Prototype, Not Every Mutation Abstract: Rapid AI-assisted prototyping should become visible to development teams early, while active engineering collaboration should occur through stable, reproducible checkpoints rather than against a continuously changing experimental branch. Author: Tony Malott Author URL: https://malott.ai Published: 2026-07-12 Updated: 2026-07-12 Format: ai-assisted-product-development-essay Privacy: public-safe Topics: - ai-assisted-development - engineering-governance - product-prototyping - software-delivery - context-as-code Audience: - engineering-leaders - product-owners - ai-architects - software-developers - technical-operators PROVENANCE Posture: owner-origin-operating-model-with-current-public-engineering-source-support Private sources used: false Private sources published: false Public-safe boundary: The artifact may discuss general AI-assisted prototyping, Git collaboration, engineering debt, repository legibility, development environments, decision records, and productization practices. It does not identify an employer, colleague, internal product, repository, customer, regulated record, confidential architecture, security control, private conversation, credential, account, or local machine path. Publication timing may still permit contextual inference by people already familiar with the underlying discussion. CLAIMS Claim: claim:share-the-prototype-not-every-mutation:001 Posture: bounded-factual-claim Text: AI-assisted implementation can move faster than conventional collaboration and review rhythms. Support: - source:share-the-prototype-not-every-mutation:openai-harness-engineering Caveat: Supported by a case study, not asserted as universal. Claim: claim:share-the-prototype-not-every-mutation:002 Posture: evidence-supported-inference Text: Repository access does not automatically create collaboration or legibility. Support: - source:share-the-prototype-not-every-mutation:openai-harness-engineering Claim: claim:share-the-prototype-not-every-mutation:003 Posture: owner-origin-judgment Text: Waiting for a prototype to be finished can defer collaboration indefinitely. Support: - None declared. Caveat: No universal sharing threshold is claimed. Claim: claim:share-the-prototype-not-every-mutation:004 Posture: owner-origin-operating-model-synthesis Text: Lab, checkpoint, and productization form a practical operating model for high-velocity AI prototyping. Support: - source:share-the-prototype-not-every-mutation:dora-ai-2025 - source:share-the-prototype-not-every-mutation:openai-harness-engineering - source:share-the-prototype-not-every-mutation:google-small-cls Caveat: The taxonomy is Tony Malott's proposed model, not a published industry standard. Claim: claim:share-the-prototype-not-every-mutation:005 Posture: evidence-supported-inference Text: Private prototyping can create knowledge concentration and delayed challenge. Support: - source:share-the-prototype-not-every-mutation:openai-harness-engineering - source:share-the-prototype-not-every-mutation:aws-adr-process Claim: claim:share-the-prototype-not-every-mutation:006 Posture: supported-engineering-claim Text: Co-development against a rapidly moving branch increases divergence and review friction. Support: - source:share-the-prototype-not-every-mutation:google-small-cls Claim: claim:share-the-prototype-not-every-mutation:007 Posture: bounded-factual-claim Text: AI-assisted development can shift constraints toward attention, specification, environment design, and validation. Support: - source:share-the-prototype-not-every-mutation:openai-harness-engineering Caveat: The supporting evidence is a specific vendor-authored case study. Claim: claim:share-the-prototype-not-every-mutation:008 Posture: supported-institutional-research-finding Text: AI amplifies existing organizational strengths and weaknesses. Support: - source:share-the-prototype-not-every-mutation:dora-ai-2025 Claim: claim:share-the-prototype-not-every-mutation:009 Posture: owner-origin-operational-framing Text: Experimental commits and pull requests can serve different operational purposes. Support: - source:share-the-prototype-not-every-mutation:github-pull-requests Caveat: The distinction is Tony Malott's framing, not formal Git terminology. Claim: claim:share-the-prototype-not-every-mutation:010 Posture: supported-recommendation Text: An experimental lab may remain unstable while preserving decisions and recoverability. Support: - source:share-the-prototype-not-every-mutation:openai-harness-engineering - source:share-the-prototype-not-every-mutation:aws-adr-process Claim: claim:share-the-prototype-not-every-mutation:011 Posture: supported-recommendation Text: A promotion checkpoint should contain context, reproducibility, debt, and decisions rather than only a commit hash. Support: - source:share-the-prototype-not-every-mutation:openai-harness-engineering - source:share-the-prototype-not-every-mutation:aws-adr-process - source:share-the-prototype-not-every-mutation:dev-container-spec Claim: claim:share-the-prototype-not-every-mutation:012 Posture: engineering-recommendation Text: Productization should begin from an immutable checkpoint or clean governed baseline. Support: - source:share-the-prototype-not-every-mutation:google-small-cls - source:share-the-prototype-not-every-mutation:dora-trunk-based-development - source:share-the-prototype-not-every-mutation:aws-adr-process Caveat: Presented as a proposed operating boundary, not a universal requirement. Claim: claim:share-the-prototype-not-every-mutation:013 Posture: supported-engineering-practice Text: Product engineering benefits from short-lived branches and small reviewable changes. Support: - source:share-the-prototype-not-every-mutation:google-small-cls - source:share-the-prototype-not-every-mutation:dora-trunk-based-development Caveat: Applied to the productization lane, not unrestricted discovery. Claim: claim:share-the-prototype-not-every-mutation:014 Posture: supported-engineering-recommendation Text: Significant decisions should become durable repository artifacts. Support: - source:share-the-prototype-not-every-mutation:openai-harness-engineering - source:share-the-prototype-not-every-mutation:aws-adr-process Claim: claim:share-the-prototype-not-every-mutation:015 Posture: owner-origin-participation-model Text: Collaboration can begin through visibility and design participation before shared coding begins. Support: - source:share-the-prototype-not-every-mutation:github-pull-requests Caveat: The three-level model is proposed, not standardized. Claim: claim:share-the-prototype-not-every-mutation:016 Posture: owner-origin-judgment-and-inference Text: Context debt can be highly consequential. Support: - source:share-the-prototype-not-every-mutation:openai-harness-engineering - source:share-the-prototype-not-every-mutation:aws-adr-process Caveat: Context debt is not asserted to be categorically worse than all code or security debt. Claim: claim:share-the-prototype-not-every-mutation:017 Posture: owner-origin-conclusion-and-recommendation Text: Checkpoint-based collaboration can balance exploration speed and shared engineering. Support: - source:share-the-prototype-not-every-mutation:dora-ai-2025 - source:share-the-prototype-not-every-mutation:openai-harness-engineering - source:share-the-prototype-not-every-mutation:google-small-cls - source:share-the-prototype-not-every-mutation:dora-trunk-based-development - source:share-the-prototype-not-every-mutation:github-pull-requests - source:share-the-prototype-not-every-mutation:aws-adr-process - source:share-the-prototype-not-every-mutation:dev-container-spec Caveat: Presented as Tony Malott's synthesis. PUBLIC SOURCES Source: source:share-the-prototype-not-every-mutation:dora-ai-2025 Title: DORA, State of AI-assisted Software Development 2025 Type: institutional-research Role: Establishes AI as an organizational amplifier. Description: Supports the claim that AI magnifies existing organizational strengths and weaknesses. The public summary does not replace the full methodology and report package. Locator: https://dora.dev/research/2025/dora-report/ Source: source:share-the-prototype-not-every-mutation:openai-harness-engineering Title: OpenAI, Harness Engineering Type: vendor-engineering-case-study Role: Supports human-attention scarcity, repository legibility, environment design, and feedback systems. Description: A February 11, 2026 case study from an unusual greenfield project with extensive agent infrastructure. It is not treated as an industry baseline. Locator: https://openai.com/index/harness-engineering/ Source: source:share-the-prototype-not-every-mutation:google-small-cls Title: Google Engineering Practices, Small CLs Type: first-party-engineering-guidance Role: Supports small, understandable review units and the conflict costs of large changes. Description: Applies to reviewed product changes, not every exploratory experiment. Locator: https://google.github.io/eng-practices/review/developer/small-cls.html Source: source:share-the-prototype-not-every-mutation:dora-trunk-based-development Title: DORA, Trunk-based Development Type: institutional-engineering-guidance Role: Supports small batches, frequent integration, short-lived branches, and automated tests. Description: Applies most directly to the productization lane. Locator: https://dora.dev/capabilities/trunk-based-development/ Source: source:share-the-prototype-not-every-mutation:github-pull-requests Title: GitHub, About Pull Requests Type: official-platform-documentation Role: Defines pull-request purpose and draft-pull-request behavior. Description: Platform capability does not by itself establish organizational effectiveness. Locator: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests Source: source:share-the-prototype-not-every-mutation:aws-adr-process Title: AWS, Architectural Decision Record Process Type: official-prescriptive-guidance Role: Supports preserving significant decisions, context, consequences, and supersession history. Description: Extending ADR discipline to product, UX, prompt, and experiment decisions is Tony Malott's recommendation. Locator: https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html Source: source:share-the-prototype-not-every-mutation:dev-container-spec Title: Development Container Specification Type: open-technical-specification Role: Supports repeatable development environments. Description: Reproducibility alone does not make a prototype transferable. Locator: https://containers.dev/implementors/spec/ RELATIONSHIPS Relationship: relatedTo Target: artifact:demo-debt Label: Demo Debt Display posture: Related operating-model analysis Description: Explores how prototype success can conceal production debt and why a working demonstration is not equivalent to a durable product. Posture: declared-conceptual-relationship Evidence: Both artifacts examine how rapid demonstrations and temporary implementation choices become durable engineering obligations. Relationship: relatedTo Target: artifact:your-second-brain-is-not-a-production-architecture Label: Your Second Brain Is Not a Production Architecture Display posture: Related architecture boundary Description: Examines why useful personal AI workflows do not automatically become production-grade organizational systems. Posture: declared-conceptual-relationship Evidence: Both artifacts distinguish exploratory personal systems from governed production architecture. Relationship: relatedTo Target: artifact:how-shareplane-works Label: How SharePlane Works Display posture: Related context-as-code architecture Description: Shows how explicit authority, role boundaries, validation, and receipts convert high-velocity work into durable public artifacts. Posture: declared-operating-model-relationship Evidence: The article's checkpoint and repository-legibility model aligns with SharePlane's broader context-as-code, authority, and bounded-implementation architecture. ARTIFACT CONTENT [PARAGRAPH] I have been pushed, reasonably, to hand some of my prototypes to the development team so we can work on them together and begin dealing with the engineering debt before it compounds into one of those organizational mortgages nobody remembers signing. [PARAGRAPH] My first reaction has been: holy shit, how would that even work? [PARAGRAPH] The pressure is reasonable. [PARAGRAPH] So is my concern. [PARAGRAPH] I am not a software developer in the traditional sense. I am building prototypes with AI, often at a speed that makes the normal development rhythm feel almost geological. I may change the product structure, user experience, data model, workflow, and underlying assumption several times in the same session. [PARAGRAPH] Sometimes the prototype survives. [PARAGRAPH] Sometimes it teaches me what the product should have been. [PARAGRAPH] Sometimes it deserves a respectful burial and a small marker explaining that the original idea seemed smarter at two in the morning. [PARAGRAPH] Giving someone access to the repository does not automatically make that process collaborative. It may simply give another person a front-row seat to controlled chaos. [PARAGRAPH] The answer, however, cannot be to keep the work private until I decide it is finished. Prototypes like these are rarely finished in any meaningful sense. They cross a threshold where the learning becomes valuable enough, the direction becomes stable enough, and the cost of continuing alone becomes higher than the cost of involving other people. [PARAGRAPH] The operating model I would propose has three distinct stages: [LIST ITEM] The lab, where exploration is allowed to move quickly and break its own assumptions. [LIST ITEM] The checkpoint, where a specific state becomes reproducible, understandable, and available for serious review. [LIST ITEM] The productization lane, where the development team engineers a durable product from the promoted intent and evidence. [PARAGRAPH] Share the repository early. [PARAGRAPH] Share the chaos honestly. [PARAGRAPH] Collaborate from promoted checkpoints. [PARAGRAPH] That distinction matters because access is not the same thing as legibility, and legibility is not the same thing as readiness for joint development. [HEADING 2] Both sides are right, which is inconvenient [PARAGRAPH] The engineering concern is valid. [PARAGRAPH] The longer the reasoning, decisions, constraints, and product intent remain only in my head, the more the prototype becomes dependent on me. The team cannot challenge weak assumptions it cannot see. Developers cannot identify architectural traps while I am cheerfully building toward them. Security, operability, supportability, and maintainability arrive late, usually carrying invoices. [PARAGRAPH] There is also a trust problem. [PARAGRAPH] When one person repeatedly says, “I will share it when it is ready,” the organization may eventually hear, “I will share it when nobody can meaningfully influence it.” [PARAGRAPH] That may not be the intent. [PARAGRAPH] It can still be the effect. [PARAGRAPH] My concern is also valid. [PARAGRAPH] Dropping a development team into a branch that changes every few minutes is not collaboration. [PARAGRAPH] It is interruption with Git history. [PARAGRAPH] Conventional team development assumes that a branch represents a bounded change moving toward integration. My experimental branch may represent a moving theory of the product. If a developer branches from it on Monday and I replace half the structure by Tuesday, we have not created parallel progress. We have created two increasingly unrelated interpretations that somebody will later be asked to merge because human civilization still enjoys avoidable suffering. [PARAGRAPH] Google’s code-review guidance explains why large changes become difficult to review and merge. They can produce more conflicts, make it harder for reviewers to reason about the impact, increase wasted work when the overall direction is rejected, and complicate rollback. It also points out something authors routinely forget: the reviewer does not possess the context accumulated while the change was being created. (google.github.io) [PARAGRAPH] The mistake is treating this as a choice between secrecy and synchronized editing. [PARAGRAPH] It is neither. [HEADING 2] AI changed the bottleneck [PARAGRAPH] In many AI-assisted workflows, producing an implementation has become much cheaper and faster. [PARAGRAPH] Human attention, specification, review, and validation have not accelerated at the same rate. [PARAGRAPH] OpenAI recently described an internal experiment in which a small engineering team built a product with Codex generating the application code, tests, continuous-integration configuration, documentation, observability, and internal tooling. OpenAI estimated that the product was built in about one-tenth of the time required to write the code by hand. The repository accumulated roughly 1,500 merged pull requests during its first five months. (openai.com) [PARAGRAPH] Those numbers are impressive. [PARAGRAPH] They are also a case study from an unusual greenfield environment with substantial investment in agent tooling, structural controls, automated validation, and repository design. OpenAI explicitly cautions that the resulting autonomy depends heavily on that environment and should not be assumed to generalize without similar investment. (openai.com) [PARAGRAPH] The broader lesson is more useful than the headline numbers. [PARAGRAPH] The team found that early progress was constrained not by the model’s ability to produce code, but by an underspecified environment. The agents lacked the tools, abstractions, internal structure, and feedback loops required to complete higher-level work reliably. Human time and attention became the scarce resources. (openai.com) [PARAGRAPH] DORA’s 2025 research reaches a compatible conclusion at the organizational level. It describes AI primarily as an amplifier that magnifies the strengths and weaknesses of the organization already using it. The greatest returns come from improving the underlying organizational system, not merely adopting the tools. (dora.dev) [PARAGRAPH] That maps directly to this problem. [PARAGRAPH] Faster code generation does not rescue a weak collaboration model. [PARAGRAPH] It accelerates it. [PARAGRAPH] The useful practice is not simply to commit faster. [PARAGRAPH] It is to make high-speed work understandable at deliberate boundaries. [HEADING 2] The lab is allowed to be unstable [PARAGRAPH] The lab is where I explore. [PARAGRAPH] It can contain failed directions, temporary architecture, generated code, duplicated components, ugly names, discarded prompts, and implementation choices that would make a senior developer stare silently at the ceiling. [PARAGRAPH] That is acceptable because the lab has a different purpose. [PARAGRAPH] Its job is to reduce uncertainty about the product. [PARAGRAPH] The lab should still be versioned. I should commit meaningful states, preserve important decisions, record experiments, and avoid losing work. But those commits are experimental telemetry. They are not all requests for engineering review. [PARAGRAPH] This is where otherwise sound development advice can become unhelpful when applied without context. [PARAGRAPH] Small pull requests are excellent guidance once multiple people are integrating changes into a shared product line. Google recommends self-contained changes because they are easier to understand, review, merge, test, reject, and roll back. (google.github.io) [PARAGRAPH] That does not mean every five-minute AI experiment deserves its own pull request. [PARAGRAPH] A pull request is a collaboration unit. [PARAGRAPH] An experimental commit can simply preserve a meaningful state. [PARAGRAPH] Those are my definitions, not formal Git terminology, but the distinction is operationally important. [PARAGRAPH] GitHub defines a pull request as a proposal to discuss, review, and merge changes. It also supports draft pull requests so unfinished work can be shared without becoming mergeable or automatically requesting review from code owners. (docs.github.com) [PARAGRAPH] That makes draft pull requests useful for visibility. [PARAGRAPH] It does not make them a substitute for a coherent checkpoint. [PARAGRAPH] The lab can remain owner-driven and high-churn, provided it is visible and does not pretend to be production. [HEADING 2] The checkpoint is the missing artifact [PARAGRAPH] A checkpoint is not merely a commit hash. [PARAGRAPH] It is a promoted state that another person can understand without reconstructing my week from commit messages such as “fix,” “actual fix,” and “this should finally work.” [PARAGRAPH] Each checkpoint should include: [LIST ITEM] the problem being solved; [LIST ITEM] the current product thesis; [LIST ITEM] what was learned since the prior checkpoint; [LIST ITEM] what is stable enough to rely on; [LIST ITEM] what remains deliberately disposable; [LIST ITEM] the architecture and interface boundaries that now matter; [LIST ITEM] major decisions and rejected alternatives; [LIST ITEM] known defects, debt, and unresolved risks; [LIST ITEM] exact setup and run instructions; [LIST ITEM] a repeatable development environment; [LIST ITEM] smoke tests and acceptance criteria; [LIST ITEM] a short demonstration of the current behavior; [LIST ITEM] the next decisions where development-team input has leverage. [PARAGRAPH] This is not bureaucratic packaging. [PARAGRAPH] It is the minimum translation layer between rapid individual discovery and shared engineering. [PARAGRAPH] The Development Container Specification provides one useful mechanism for the reproducibility part. It allows teams to define a repeatable development environment, including the execution environment and supporting metadata needed to develop the application. The configuration can deterministically recreate the required containers. (containers.dev) [PARAGRAPH] A development container does not make a prototype understandable by itself. It does remove the charming ritual in which three engineers spend half a day discovering that the prototype depends on a specific runtime, an undocumented environment variable, and something installed globally on my machine six months ago. [PARAGRAPH] The checkpoint should answer one practical question: [PARAGRAPH] Can a competent developer clone this state, run it, understand its purpose, see its boundaries, and identify where to contribute without needing me to narrate every file? [PARAGRAPH] Until the answer is yes, I have shared code. [PARAGRAPH] I have not transferred a prototype. [HEADING 2] Productization should not chase the lab branch [PARAGRAPH] Once a checkpoint is promoted, the development team should not be forced to build directly on top of my live experimental branch. [PARAGRAPH] This resolves most of my concern. [PARAGRAPH] The productization lane should begin from an immutable checkpoint, tag, or clean product baseline derived from that checkpoint. The team can then establish the durable architecture, tests, security controls, deployment model, observability, support boundaries, and code standards that a real product requires. [PARAGRAPH] Meanwhile, I can continue exploring in the lab. [PARAGRAPH] The flow should be intentional and mostly one way: [PARAGRAPH] lab exploration -> promoted checkpoint -> productization baseline [PARAGRAPH] New discoveries from the lab can be proposed into the productization lane as bounded changes. [PARAGRAPH] They should not silently overwrite the product team’s foundation. [PARAGRAPH] This avoids the nightmare scenario where a developer branches from Monday’s prototype and returns Friday to discover that I have replaced the floor, moved the walls, and decided the building is now a boat. [PARAGRAPH] The product line gets short-lived branches and small, reviewable changes. [PARAGRAPH] The lab gets freedom. [PARAGRAPH] The checkpoint governs movement between them. [PARAGRAPH] DORA’s guidance on trunk-based development and continuous integration supports small batches, frequent integration, short-lived branches, and fast automated tests. Those disciplines belong in the productization lane, where the objective has shifted from discovering the product to changing and operating it safely. (dora.dev) [PARAGRAPH] The lab, checkpoint, productization model is not a published industry standard. [PARAGRAPH] It is my synthesis of the problem. [PARAGRAPH] It combines the freedom required for discovery with the controls required for shared engineering. [PARAGRAPH] That is more useful than devotion to a branching diagram designed for a different mode of work. [HEADING 2] Decisions must become first-class repository artifacts [PARAGRAPH] Code cannot carry all the meaning. [PARAGRAPH] A developer reading the implementation can see what the system currently does. That does not reliably reveal why I chose that behavior, what alternatives I rejected, which constraints are immovable, or which parts exist only because I was testing an idea. [PARAGRAPH] Architecture decision records are useful because they preserve a significant decision, its context, and its consequences. AWS recommends maintaining the resulting records as a decision log and treating accepted decisions as immutable, with later records superseding rather than silently rewriting them. (docs.aws.amazon.com) [PARAGRAPH] For AI-heavy prototyping, I would extend that discipline beyond classic architecture decisions. [PARAGRAPH] The repository needs lightweight, versioned records for: [LIST ITEM] product decisions; [LIST ITEM] user-experience decisions; [LIST ITEM] data and trust boundaries; [LIST ITEM] prompt and agent behavior contracts; [LIST ITEM] rejected approaches; [LIST ITEM] acceptance criteria; [LIST ITEM] technical debt; [LIST ITEM] experiments and what they proved; [LIST ITEM] assumptions that have not yet been verified. [PARAGRAPH] OpenAI reached a similar conclusion in its agent-first project. It used a structured repository knowledge base containing architecture documents, product specifications, execution plans, completed plans, decision logs, and a technical-debt tracker. Information left in chat, external documents, or individual memory was unavailable to the agent and would also be unavailable to a new engineer joining later. (openai.com) [PARAGRAPH] That maps directly to my problem. [PARAGRAPH] The development team does not need every thought I had. [PARAGRAPH] It needs the durable decisions, current assumptions, and evidence required to continue the work without guessing. [HEADING 2] Collaboration should begin before co-development [PARAGRAPH] Another false choice is assuming that involving developers means they must immediately start coding against the prototype. [PARAGRAPH] There are at least three useful levels of involvement. [PARAGRAPH] The first is visibility. [PARAGRAPH] The team can see the authorized repository, checkpoints, current direction, debt log, and unresolved questions. [PARAGRAPH] The second is design participation. [PARAGRAPH] Developers can challenge architecture, identify operational risks, recommend boundaries, and help define what a productization-ready checkpoint must contain. [PARAGRAPH] The third is implementation ownership. [PARAGRAPH] The team begins building from an accepted baseline with clear scope, responsibilities, and acceptance criteria. [PARAGRAPH] This three-level model is also my proposed operating method, not a formal standard. [PARAGRAPH] I should probably move into the first two levels earlier than I have. [PARAGRAPH] That would give the team influence while the cost of changing direction is low, without forcing anyone to chase every experimental commit. It would also make the organization less dependent on faith, a governance model with a famously uneven record. [PARAGRAPH] A weekly checkpoint review may be more valuable than continuous branch activity. [PARAGRAPH] Thirty minutes spent on what changed, what was learned, what is now stable, and what needs engineering judgment can create more collaboration than fifty noisy pull requests. [HEADING 2] Some of the most dangerous debt is missing context [PARAGRAPH] Prototype code can be replaced. [PARAGRAPH] Missing context is harder to recover. [PARAGRAPH] If nobody else understands the product thesis, decision history, constraints, user need, data boundaries, acceptance criteria, or reasons behind the current design, cleaning the code does not solve the underlying problem. [PARAGRAPH] It produces a more maintainable implementation of something the team still does not fully understand. [PARAGRAPH] OpenAI’s experience illustrates how strongly missing context and weak environmental structure can constrain otherwise capable coding agents. AWS’s decision-record guidance addresses the same underlying problem from a conventional team perspective: decisions become reusable only when their context and consequences are preserved. (openai.com) [PARAGRAPH] I would not claim that context debt is always worse than code debt. [PARAGRAPH] A security vulnerability, corrupt data model, or catastrophic architectural choice can make that comparison look ridiculous very quickly. [PARAGRAPH] But context debt is routinely underestimated because it does not appear in a static analyzer. [PARAGRAPH] This is where the pressure from engineering is useful. [PARAGRAPH] The organization may be calling it engineering debt because that is the bucket available. Part of what it is seeing is knowledge concentration, delayed challenge, product risk, and an unclear ownership transition. [PARAGRAPH] Those are real debts. [PARAGRAPH] I do not need to slow the lab until it behaves like a mature development program. [PARAGRAPH] I need to stop using the lab’s speed as an excuse for leaving the rest of the organization blind. [HEADING 2] The operating agreement I would propose [PARAGRAPH] I would propose a simple agreement with the development team. [PARAGRAPH] The authorized repository becomes visible early. [PARAGRAPH] The lab branch remains explicitly experimental, owner-driven, and separate from the product integration path. [PARAGRAPH] At a defined cadence, or when a meaningful learning threshold is crossed, I promote an immutable checkpoint. [PARAGRAPH] Each checkpoint includes the product thesis, decision log, known debt, repeatable environment, setup instructions, demonstration, acceptance tests, current architecture, unstable areas, and specific questions for the development team. [PARAGRAPH] The development team reviews the checkpoint, not every mutation. [PARAGRAPH] When a checkpoint is ready for productization, the team creates or advances a stable product baseline from that snapshot. [PARAGRAPH] Product work uses short-lived branches, small reviewable changes, protected integration, and automated validation. [PARAGRAPH] Further experimental discoveries enter the product line through bounded proposals. [PARAGRAPH] The product line never has to merge the entire future history of the lab. [PARAGRAPH] Significant technical and product decisions remain in the repository. [PARAGRAPH] Chat can discuss them. [PARAGRAPH] The repository must remember them. [PARAGRAPH] That gives the engineering team what it actually needs: visibility, influence, shared ownership, and an earlier path to engineering discipline. [PARAGRAPH] It gives me what I need: enough freedom to discover what the product is before every experiment becomes a team event. [HEADING 2] The prototype does not need to be finished [PARAGRAPH] My original instinct was to wait until the prototype stopped changing so quickly. [PARAGRAPH] That threshold may never arrive. [PARAGRAPH] A better threshold is legibility. [PARAGRAPH] I should share the work when I can explain its current thesis, preserve its decision history, reproduce its environment, identify what is stable, label what is disposable, and promote a checkpoint that another person can inspect without being dragged through every experiment that produced it. [PARAGRAPH] The development team does not need to keep up with every move. [PARAGRAPH] It needs a reliable place to meet the work. [PARAGRAPH] The answer is not to freeze the prototype. [PARAGRAPH] It is not to put the whole team inside the blender. [PARAGRAPH] Build quickly in the lab. [PARAGRAPH] Promote deliberately. [PARAGRAPH] Engineer together from checkpoints. [PARAGRAPH] That is how individual speed begins becoming an organizational capability instead of a private talent with a bus factor of one. PUBLIC SURFACES Human page: https://next.shareplane.malott.ai/artifacts/share-the-prototype-not-every-mutation/ Metadata JSON: https://next.shareplane.malott.ai/artifacts/share-the-prototype-not-every-mutation/artifact.json Receipt: https://next.shareplane.malott.ai/artifacts/share-the-prototype-not-every-mutation/receipt.json Context: https://next.shareplane.malott.ai/artifacts/share-the-prototype-not-every-mutation/context.txt Agent-package manifest: https://next.shareplane.malott.ai/artifacts/share-the-prototype-not-every-mutation/agent-package.json Agent-package ZIP: https://next.shareplane.malott.ai/artifacts/share-the-prototype-not-every-mutation/agent-package.zip Collection catalog: https://next.shareplane.malott.ai/catalog.json Graph: https://next.shareplane.malott.ai/graph.json Agent index: https://next.shareplane.malott.ai/llms.txt