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
