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.

My first reaction has been: holy shit, how would that even work?

The pressure is reasonable.

So is my concern.

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.

Sometimes the prototype survives.

Sometimes it teaches me what the product should have been.

Sometimes it deserves a respectful burial and a small marker explaining that the original idea seemed smarter at two in the morning.

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.

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.

The operating model I would propose has three distinct stages:

The lab, where exploration is allowed to move quickly and break its own assumptions.
The checkpoint, where a specific state becomes reproducible, understandable, and available for serious review.
The productization lane, where the development team engineers a durable product from the promoted intent and evidence.

Share the repository early.

Share the chaos honestly.

Collaborate from promoted checkpoints.

That distinction matters because access is not the same thing as legibility, and legibility is not the same thing as readiness for joint development.

CH 01LAB

Both sides are right, which is inconvenient

The engineering concern is valid.

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.

There is also a trust problem.

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.”

That may not be the intent.

It can still be the effect.

My concern is also valid.

Dropping a development team into a branch that changes every few minutes is not collaboration.

It is interruption with Git history.

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.

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)

The mistake is treating this as a choice between secrecy and synchronized editing.

It is neither.

CH 02LAB

AI changed the bottleneck

In many AI-assisted workflows, producing an implementation has become much cheaper and faster.

Human attention, specification, review, and validation have not accelerated at the same rate.

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)

Those numbers are impressive.

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)

The broader lesson is more useful than the headline numbers.

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)

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)

That maps directly to this problem.

Faster code generation does not rescue a weak collaboration model.

It accelerates it.

The useful practice is not simply to commit faster.

It is to make high-speed work understandable at deliberate boundaries.

CH 03LAB

The lab is allowed to be unstable

The lab is where I explore.

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.

That is acceptable because the lab has a different purpose.

Its job is to reduce uncertainty about the product.

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.

This is where otherwise sound development advice can become unhelpful when applied without context.

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)

That does not mean every five-minute AI experiment deserves its own pull request.

A pull request is a collaboration unit.

An experimental commit can simply preserve a meaningful state.

Those are my definitions, not formal Git terminology, but the distinction is operationally important.

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)

That makes draft pull requests useful for visibility.

It does not make them a substitute for a coherent checkpoint.

The lab can remain owner-driven and high-churn, provided it is visible and does not pretend to be production.

CH 04CHECKPOINT

The checkpoint is the missing artifact

A checkpoint is not merely a commit hash.

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.”

Each checkpoint should include:

the problem being solved;
the current product thesis;
what was learned since the prior checkpoint;
what is stable enough to rely on;
what remains deliberately disposable;
the architecture and interface boundaries that now matter;
major decisions and rejected alternatives;
known defects, debt, and unresolved risks;
exact setup and run instructions;
a repeatable development environment;
smoke tests and acceptance criteria;
a short demonstration of the current behavior;
the next decisions where development-team input has leverage.

This is not bureaucratic packaging.

It is the minimum translation layer between rapid individual discovery and shared engineering.

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)

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.

The checkpoint should answer one practical question:

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?

Until the answer is yes, I have shared code.

I have not transferred a prototype.

CH 05CHECKPOINT

Productization should not chase the lab branch

Once a checkpoint is promoted, the development team should not be forced to build directly on top of my live experimental branch.

This resolves most of my concern.

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.

Meanwhile, I can continue exploring in the lab.

The flow should be intentional and mostly one way:

lab exploration -> promoted checkpoint -> productization baseline

New discoveries from the lab can be proposed into the productization lane as bounded changes.

They should not silently overwrite the product team’s foundation.

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.

The product line gets short-lived branches and small, reviewable changes.

The lab gets freedom.

The checkpoint governs movement between them.

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)

The lab, checkpoint, productization model is not a published industry standard.

It is my synthesis of the problem.

It combines the freedom required for discovery with the controls required for shared engineering.

That is more useful than devotion to a branching diagram designed for a different mode of work.

CH 06CHECKPOINT

Decisions must become first-class repository artifacts

Code cannot carry all the meaning.

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.

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)

For AI-heavy prototyping, I would extend that discipline beyond classic architecture decisions.

The repository needs lightweight, versioned records for:

product decisions;
user-experience decisions;
data and trust boundaries;
prompt and agent behavior contracts;
rejected approaches;
acceptance criteria;
technical debt;
experiments and what they proved;
assumptions that have not yet been verified.

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)

That maps directly to my problem.

The development team does not need every thought I had.

It needs the durable decisions, current assumptions, and evidence required to continue the work without guessing.

CH 07PRODUCT

Collaboration should begin before co-development

Another false choice is assuming that involving developers means they must immediately start coding against the prototype.

There are at least three useful levels of involvement.

The first is visibility.

The team can see the authorized repository, checkpoints, current direction, debt log, and unresolved questions.

The second is design participation.

Developers can challenge architecture, identify operational risks, recommend boundaries, and help define what a productization-ready checkpoint must contain.

The third is implementation ownership.

The team begins building from an accepted baseline with clear scope, responsibilities, and acceptance criteria.

This three-level model is also my proposed operating method, not a formal standard.

I should probably move into the first two levels earlier than I have.

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.

A weekly checkpoint review may be more valuable than continuous branch activity.

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.

CH 08PRODUCT

Some of the most dangerous debt is missing context

Prototype code can be replaced.

Missing context is harder to recover.

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.

It produces a more maintainable implementation of something the team still does not fully understand.

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)

I would not claim that context debt is always worse than code debt.

A security vulnerability, corrupt data model, or catastrophic architectural choice can make that comparison look ridiculous very quickly.

But context debt is routinely underestimated because it does not appear in a static analyzer.

This is where the pressure from engineering is useful.

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.

Those are real debts.

I do not need to slow the lab until it behaves like a mature development program.

I need to stop using the lab’s speed as an excuse for leaving the rest of the organization blind.

CH 09PRODUCT

The operating agreement I would propose

I would propose a simple agreement with the development team.

The authorized repository becomes visible early.

The lab branch remains explicitly experimental, owner-driven, and separate from the product integration path.

At a defined cadence, or when a meaningful learning threshold is crossed, I promote an immutable checkpoint.

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.

The development team reviews the checkpoint, not every mutation.

When a checkpoint is ready for productization, the team creates or advances a stable product baseline from that snapshot.

Product work uses short-lived branches, small reviewable changes, protected integration, and automated validation.

Further experimental discoveries enter the product line through bounded proposals.

The product line never has to merge the entire future history of the lab.

Significant technical and product decisions remain in the repository.

Chat can discuss them.

The repository must remember them.

That gives the engineering team what it actually needs: visibility, influence, shared ownership, and an earlier path to engineering discipline.

It gives me what I need: enough freedom to discover what the product is before every experiment becomes a team event.

CH 10PRODUCT

The prototype does not need to be finished

My original instinct was to wait until the prototype stopped changing so quickly.

That threshold may never arrive.

A better threshold is legibility.

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.

The development team does not need to keep up with every move.

It needs a reliable place to meet the work.

The answer is not to freeze the prototype.

It is not to put the whole team inside the blender.

Build quickly in the lab.

Promote deliberately.

Engineer together from checkpoints.

That is how individual speed begins becoming an organizational capability instead of a private talent with a bus factor of one.

Atomic Claim Ledger

Governing thesis

Rapid AI-assisted prototyping should become visible to the development team early, while active engineering collaboration should occur through stable, reproducible checkpoints rather than against a continuously changing experimental branch.

Claims

ID	Claim	Classification	Evidence posture	Public-copy treatment
C-01	AI-assisted implementation can move faster than conventional collaboration and review rhythms.	Factual, bounded	Supported by OpenAI case study; not universal	Qualified as “many AI-assisted workflows”
C-02	Repository access does not automatically create collaboration or legibility.	Inference	Supported by repository-knowledge and context evidence	Retained
C-03	Waiting for a prototype to be finished can defer collaboration indefinitely.	Judgment	No universal threshold established	Retained as first-person judgment
C-04	Lab, checkpoint, productization is a practical operating model.	Original synthesis	Components supported; taxonomy is Tony’s	Explicitly labeled as proposed model
C-05	Private prototyping creates knowledge concentration and delayed challenge.	Inference	Supported	Retained
C-06	Co-development against a rapidly moving branch increases divergence and review friction.	Engineering claim	Supported by Google review guidance	Retained
C-07	AI shifts constraints toward attention, specification, environment design, and validation.	Factual, bounded	Supported by OpenAI case study	Case-study limitation stated
C-08	AI amplifies existing organizational strengths and weaknesses.	Research finding	Supported by DORA 2025	Retained
C-09	Experimental commits and pull requests serve different operational purposes.	Tony framing	GitHub semantics support distinction	Explicitly identified as Tony’s definitions
C-10	The lab may remain unstable while preserving decisions and recoverability.	Recommendation	Supported in principle	Retained
C-11	A checkpoint must contain context, reproducibility, debt, and decisions, not only a commit hash.	Recommendation	Supported in principle	Retained as proposed standard
C-12	Productization should begin from an immutable checkpoint or clean baseline.	Recommendation	Supported by engineering logic	Retained as “should,” not universal law
C-13	Product work benefits from short-lived branches and small reviewable changes.	Established practice	Supported by Google and DORA	Limited to productization lane
C-14	Significant decisions should be durable repository artifacts.	Established recommendation	Supported by AWS and OpenAI	Retained
C-15	Collaboration can begin through visibility and design participation before co-development.	Original synthesis	Directionally supported	Explicitly labeled as proposed model
C-16	Context debt can be highly consequential.	Judgment and inference	Mechanism supported; ranking not proven	Narrowed to “some of the most dangerous debt”
C-17	Checkpoint-based collaboration balances exploration speed and shared engineering.	Conclusion and recommendation	Supported by full evidence architecture	Retained as Tony’s proposal

Caveat register

OpenAI’s harness-engineering results are a vendor-authored case study from an unusually engineered greenfield environment.
The lab, checkpoint, productization model is original synthesis, not a published industry standard.
The three levels of collaboration are a proposed operating model.
Context debt is not categorically worse than all code or security debt.
Development containers support reproducibility but do not create legibility by themselves.
Google and DORA guidance applies most directly to the productization lane, not unrestricted discovery work.

Share the Prototype, Not Every Mutation

AI-era collaboration needs checkpoints, legible intent, and a clean boundary between exploration and product engineering

Both sides are right, which is inconvenient

AI changed the bottleneck

The lab is allowed to be unstable

The checkpoint is the missing artifact

Productization should not chase the lab branch

Decisions must become first-class repository artifacts

Collaboration should begin before co-development

Some of the most dangerous debt is missing context

The operating agreement I would propose

The prototype does not need to be finished

Reader-facing receipt

Atomic Claim Ledger

Governing thesis

Claims

Caveat register

Source Dossier

S-01: DORA, State of AI-assisted Software Development 2025

S-02: OpenAI, Harness Engineering

S-03: Google Engineering Practices, Small CLs

S-04: DORA, Trunk-based Development

S-05: GitHub, About Pull Requests

S-06: AWS, Architectural Decision Record Process

S-07: Development Container Specification