Kieran Klaassen uses AI to ship Cora while keeping human judgment at the start and end of the work.
2
He spends about half his time building features and half teaching his system what it got wrong.
3
A stored solution should make the next feature easier to build than the previous one.
Summary
Kieran Klaassen describes rebuilding Cora, an AI-native email client, as a single engineer with support from specialists. His work moved through several bottlenecks: first code quality, then planning, then deciding what to build, and finally the repetition of his own decisions. He responded by building a memory system that stores solutions and extracts his judgment into the development process. His loop is brainstorming, planning, working, reviewing, polishing, compounding, and repeating. AI handles the middle of the loop for hours, while the human decides what problem to solve and judges the finished result. Klaassen recommends spending half the time shipping the feature and half improving the system. He demonstrates commands for generating ideas from a backlog, reviewing documents, brainstorming larger projects, running overnight implementation loops, and recording product feedback. The goal is a system that becomes easier to use and produces better work after every feature.
AI let Klaassen run Cora as a one-engineer product team
Kieran Klaassen says he has not written a line of code this year and may not have read most of the code either, yet he ships a product that thousands of people trust with their email. He is rebuilding Cora, a complete AI-native email inbox, as version two. He owns the product and handles incidents himself, with support for design, databases, and other specialist problems. The setup is deliberate. As a former engineering leader and founder, he wanted to find out how far AI could take the product before he needed to grow the team. Cora runs across desktop, phone, CLI, and agent integrations.
The bottleneck moved from code quality to product judgment
Klaassen describes a sequence of constraints in his work. Two years ago, the code was the problem because AI produced hallucinated or broken implementations. He added agents and skills for review until the code became good enough. Then larger projects exposed weaknesses in planning, so he improved the plans. The next constraint was deciding what to build, which required talking with users and understanding their problems. Once AI could help with plans and product decisions, Klaassen noticed that he was repeating his own thinking. That repetition became the next problem, leading him to build a system that could remember his decisions.
Compound engineering stores judgment so the next task starts further ahead
Compound engineering came from extracting Klaassen's thinking, taste, and repeated decisions into a system. He first stored knowledge in a CLAUDE.md file, but it became too large, so he built a memory system instead. His claim is that implementation is becoming easier while judgment and taste remain the human bottleneck. When a past brainstorm or decision is stored, the next AI-generated brainstorm already includes that reasoning. This lets him move to larger problems. He says a single engineer with a compounding system can outperform teams using AI without such a system, because the system carries useful decisions into future work.
The human belongs at both ends of the AI work loop
Klaassen's loop is brainstorming, planning, working, reviewing, polishing, compounding, and repeating. He describes it as a human-AI sandwich: the human is the bread and AI is in the middle. At the start, the human decides what to work on and defines the actual problem. In the middle, AI handles the planned work, including implementation and review. At the end, the human uses taste to decide whether the result is delightful or needs a higher standard. The middle must be reliable enough to run for hours, often overnight and in parallel. Human attention should go to problem definition and the final bar.
Half the work should improve the system rather than only ship the feature
Klaassen's rule is to spend 50% of the time creating the feature and 50% teaching the system what it got wrong. The first half asks whether the feature was built and delivered the intended value. The second half asks what can be learned and stored so the next attempt is better. He saves this knowledge as solution documents inside the repository. In his experience, this can reduce token use over time because the system already contains the right answers. It avoids some later review, correction, and broad research. The stored solution is an investment in future work.
The Compound Engineering plugin turns backlogs and documents into structured work
Klaassen built the Compound Engineering plugin while building Cora and later shared it publicly. Its idea-generation command can inspect open tickets from sources such as Linear, GitHub, Slack, and Intercom, then turn the backlog into a structured document with arguments for what deserves attention. It can compare ideas against OKRs, past experiments, repository knowledge, and strategy documents. A document-review command asks sharp questions about a PRD or other document. Once those questions are answered, the answers can be compounded so the system already knows them next time. Klaassen says the approach also works through files or other tools, without using his plugin.
The overnight loop handles implementation while the human raises the product bar
Klaassen's LFG command runs planning, implementation, review, testing, pull request creation, and dogfooding for hours. It can work in parallel and add before-and-after video or screenshots to the pull request. His final polish step gives the human a summary of what the loop built and the product view needed to judge it. He distinguishes this from QA. The result should already work, while polish asks whether the product feels good enough. In one example, the system had placed two logo marks on a page. That was technically functional, but Klaassen wanted only one. He compounded the correction so future design work would avoid it.
The system should document decisions and make the middle boring
People can apply the method without the plugin by extracting repeated decisions into files or another memory system. Klaassen says the middle of the process should handle planning, working, and reviewing without needing the human. If it still needs intervention, he recommends running it manually, noticing where it fails, and improving the system until it can run for hours reliably. He also argues for documenting the reasoning behind decisions rather than documenting only code. Postmortems and agent traces can reveal which decision caused a problem, after which that decision can become a lesson for future work. The system should remember what happened and change its later behavior.
Every shipped feature should reduce the cost of the next one
Klaassen's standard is that the next feature should be easier to build because the current feature shipped. Traditional engineering often adds complexity that makes later changes harder. His process tries to reverse that pattern by turning every correction, design decision, and product lesson into stored knowledge. He says people should keep the brain active at the beginning, avoid outsourcing problem understanding to AI, and raise the bar at the end rather than merely fixing failures. The purpose of compounding is therefore practical: each feature should leave behind a better planning and implementation system, so future work starts with more of the needed judgment already available.
"50% should go into creating the feature, just making sure: did it build the feature? Did it deliver the value you set out to do? But 50% of the time should go to teaching the system for anything that it did wrong."07:45
Who should watch
You are building products with AI and keep correcting the same implementation or design mistakes.
You want to run long autonomous coding sessions but still need a clear role for product judgment and taste.
Your backlog is messy and you need a way to turn past decisions, user knowledge, and strategy into better plans.
