11 Learn through real applications
A useful product can also be a place to investigate an uncertain idea. Those roles should be distinguished without reducing the product to an experiment.
A model-management application can provide a practical service while also letting engineers evaluate how different inference backends might work through a common API. A workflow or ledger component may be useful on its own while its lessons inform other work. Beginning experimentally does not make every current responsibility provisional.
This matters because product users and researchers need different kinds of confidence. A user needs to know what works and what is supported. An investigation needs to know which hypothesis a particular observation addresses.
Name the question inside the product
Suppose a model-management application adds a second inference backend. The product outcome might be the ability to run a supported model through either backend. The research question might be whether a shared request representation can cover both without hiding important differences.
Success for the product does not automatically answer the architectural question. The integration might work because of backend-specific exceptions that make the proposed common API unhelpful. Conversely, an unsuccessful prototype might still reveal a valuable boundary: generation parameters can be shared, while lifecycle or adapter dependencies need separate treatment.
Write the product commitment and the investigative question separately. This lets the team learn without quietly weakening what users were promised.
Transfer a lesson at the right level
A workflow ledger that works for one application may demonstrate durable event recording but not the right information model for every application. An early conflict detector may demonstrate one guarded edit path without establishing reliable massive parallelism. A graph view may help answer one navigation question without replacing all text-based development.
When transferring a lesson, identify what remained constant and what changed. The new system may have different concurrency, authority, latency, or retention requirements. A pattern is transferable only to the extent that its assumptions still hold.
A proposed adaptation between systems is not a delivered integration. The systems may have different responsibilities and constraints; a diagram connecting them does not establish that the connection works.
Make a prototype disposable in the right way
Disposable does not mean careless. A prototype should preserve enough evidence to explain what was learned. It need not retain production-quality infrastructure that was irrelevant to the question.
If the question is whether people understand a workflow without a node editor, a lightweight interface may be enough. If the question is whether a ledger can support deterministic reconstruction, a visual prototype alone is inadequate. Match the implementation effort to the uncertainty.
Hashimoto's earlier account of building Ghostty emphasizes testable increments, frequent demonstrations, disposable scaffolding, and using the product to discover necessities. It offers a useful pre-agent comparison: many of these habits are durable engineering practice rather than new consequences of language models. My Approach to Building Large Technical Projects.
Keep research from swallowing delivery
An application can become a perpetual source of interesting foundational work. Each new requirement reveals another abstraction that could serve future products. The exploration may be valuable and still postpone the original usable outcome indefinitely.
Define the next end-to-end result. What can a person do with the system after this slice that they cannot do now? Which unresolved idea blocks that result, and which can remain an experiment alongside it?
The answer need not always favor the smallest demo. Some infrastructure is necessary for a dependable product. The important point is to make the tradeoff explicit rather than let architectural interest silently choose the priority.
For a project containing research, create a two-column account: current product promises and open investigative questions. Take one proposed change and place its obligations in the appropriate column. If it belongs in both, explain how the product remains usable while the hypothesis is tested. That separation protects both honest learning and reliable delivery.