Experiment · EXP-012

Should the agent start from a blank repository?

Greenfield generation versus a TypeScript boilerplate that already encodes product decisions.

I have used a personal boilerplate — TypeScript, Tailwind, shadcn, zod, linting, domain folders — for MVP work for years. Agents asked to invent a stack and a house style spent time on decisions the product did not need. Bootstrapping reduced that waste. This is engineering practice recorded as an experiment because it keeps getting ignored.

Hypothesis: A coding agent should generate the stack from scratch so the result is modern.

Research question

When using a coding agent to ship an MVP, should the agent begin from a blank repository and make every technical decision itself?

Existing system

For repeated product work I already had a preferred TypeScript foundation with conventions around styling, validation, linting, components, and domain organisation. Starting from a blank repository forced the agent to repeatedly make decisions that were already settled for my engineering workflow.

Comparison

Greenfield generation created unnecessary variability in stack choice, project structure, naming, and implementation style. Bootstrapping from an opinionated foundation reduced the decision space and let the agent spend more effort on the product-specific task.

Result

For my MVP workflow, the boilerplate became part of the context provided to the agent. It encoded decisions that did not need to be rediscovered on every project.

Finding

A reusable software foundation is not only developer tooling. In agentic engineering it is also a way to constrain the solution space and communicate house style through code.

Abubakar, Imam. "Should the agent start from a blank repository?." Imam Abubakar AI Research, 2025. https://imamabubakar.com/research/exp-012-greenfield-versus-boilerplate

This archive contains independent research, experiments, architecture studies, and technical observations. Some findings are exploratory and should not be interpreted as peer-reviewed scientific conclusions unless explicitly stated. Architecture studies of third-party products are based on publicly observable behaviour, published technical information, and engineering analysis. They are not claims of access to private source code or infrastructure.