Some experiments should stay experiments

AI makes it easier to turn an uncertain idea into something I can inspect. That is one of its most useful qualities, and one of the easiest to misuse.

A prototype can answer a question without being a good foundation. It may choose a convenient data path, ignore lifecycle details, or build its own version of a shared component. Those choices can be reasonable for an experiment and expensive in production.

I want to preserve the freedom to experiment without allowing every experiment to become an architectural commitment.

Write down the question before the implementation

An experiment should have a question it can help answer. Is the interaction understandable? Does the visual approach communicate the intended information? Is a particular technique feasible enough to investigate further?

If I cannot name the question, the experiment can expand indefinitely. Every promising result becomes a reason to add one more feature.

An explicit question gives me a stopping point. Once I have the information, I can decide what belongs in the product and what should remain evidence of something we tried.

It also gives an agent a more useful assignment. A bounded investigation can report a result and its limits. An instruction to explore until something looks impressive has a much less reliable end.

Keep the production contract visible

My repository distinguishes experiments from production work and identifies shared sources of truth. That boundary is deliberate.

If an experiment becomes useful enough to promote, I want to integrate the idea with the established architecture: the owning parser or registry, the shared builders, the normal data path, and the relevant tests. I do not want the quickest experimental path to become a second permanent system by accident.

This is a place where agents benefit from clear rules. Without them, building another small editor or maintaining another list can look like the shortest route to completion. Locally, it may be. Across the product, it can create drift.

Rejecting the code is not rejecting the work

A prototype that reveals a bad assumption has done something valuable. So has one that shows the direction is promising but the implementation should be rebuilt inside the real system.

I try to separate those judgments. The experiment can succeed at producing knowledge while failing to produce code I want to keep.

That is useful for human teams as well. If every experiment must become a shipped feature to count as progress, people have an incentive to defend weak ideas instead of learning from them.

The record should preserve what we learned and what would need to change before trying again. It need not preserve every temporary mechanism as part of the product.

More options increase the value of selection

I like having the ability to try more approaches. I want to use that capacity to improve the decisions I make, not simply increase the number of half-integrated possibilities in the codebase.

Sometimes the right next step is a production task. Sometimes it is a better experiment. Sometimes it is to stop.

AI gives me more material to judge. I still have to decide what deserves to become durable.