Non-coder builds software design method via AI dialogue alone

A non-engineer has released CGP (Core Growth Prompting), a primer and procedure designed to let someone with zero coding ability design and implement a software system through dialogue with an AI alone. The full background story was written up in Japanese under the title "How a 40-something office worker who can't code built a patent-worthy system."

CGP addresses a specific cluster of problems faced by non-engineers designing systems through AI dialogue. When features are added one at a time, the design tends to erode into an unplanned patchwork; every new chat requires re-explaining the design philosophy from scratch, causing premises to drift across sessions and eventually cause real problems; and because AI tends to state things confidently even when wrong (hallucination), a non-engineer lacks a set of judgment criteria they can apply without having to consciously run a verification process every time. CGP solves these by pairing a procedure—start from one concrete dissatisfaction, protect the core as untouchable, and attach new capabilities from the outside—with a standing set of criteria for what counts as verified and what does not.

CGP comes in two variants. The personal-use version is intended for projects built by one person or a small team and prioritizes grounding in fact; the public-interest version is designed for contexts where multiple stakeholders may hold genuinely conflicting values (government, local communities, decisions involving multiple parties) and prioritizes preserving rather than resolving those conflicts. The author emphasizes that these are not merely reskins of each other but are designed as separate methods, and a builder should ask: "Can a single builder (me) make the final call on this project?" If yes, use personal-use; if judgments could genuinely differ across stakeholders, use public-interest.

While CGP is not a new software architecture, it differs from standard descriptions of the orchestrator+worker pattern in several ways. Most explanations of that pattern are implementation guides for engineers who already have a settled design; they do not address how to find the minimal core in the first place (Step 1: Core Discovery) or how to judge whether a new feature is safe to attach (Step 3: Attachment). CGP explicitly forbids relaxing the constraint that worker modules return only structured output, treating any such relaxation as "breaking the core" and requiring an explicit check before any change touches it. CGP also fixes a specific priority order—hallucination-resistance > robustness > low latency—and mechanically rejects any proposal that violates it. Most importantly, CGP treats "when is this done" not as a matter of meeting a spec but as a judgment call a human has to make (Step 4: Organic Completion), a question that architecture-pattern write-ups generally do not answer at all.

To use the primer, a person opens a new chat, pastes the full contents of the matching primer, tells the LLM "Please proceed with the design following the principles in this primer," and starts describing what they want to build. The author emphasizes that these primers emerged from building one specific system—Prime Source, a system for verifying news articles against primary sources—and are not a universal answer. The author encourages users to start by using one of these as-is, and then, once comfortable with it, evolve their own version tailored to their own projects. The repo is licensed under MIT License and may grow to include documentation on Prime Source. The author's hope is that this lowers the barrier enough for more people to get involved in civic tech, so that domain experts who understand a public problem firsthand can build trustworthy software around it without needing a software engineering background first.

CGP emerged from the real experience of building Prime Source, an information-audit system that verifies news articles against primary sources using structural text analysis. The author—a 40-something office worker with no coding background—developed this method to solve a practical problem: non-engineers using AI for system design tend to accumulate technical debt invisibly, because feature-by-feature dialogue erodes the original architecture and AI-generated suggestions go unchecked without formal verification criteria.

The key insight behind CGP is that software architecture is not the hard part; the hard part for a non-engineer is the procedure of arriving at a stable architecture through dialogue and knowing when to stop growing it. Most architectural documentation assumes the designer already has a settled vision and explains implementation to engineers; CGP works backwards, starting from a concrete problem and guiding a non-engineer through discovery of the minimal core, attachment of new capabilities, and judgment of organic completion. By baking in a fixed priority order (hallucination-resistance first, then robustness, then latency), CGP shifts the burden of judgment from the non-engineer to the method itself—making it mechanical where it counts most.

No comments yet. Be the first to share your thoughts!