Inspired by karpathy/autoresearch. Put this in a Ralph Loop.

Use each mode-specific prompt together with the common element block.

Auto Refactor

Prompt

STOP! Re-read all code. Would Karpathy approve every line? Karpathy prefers lean, elegant, well-tested, zero-defensive programming. Use MCPs and web searches.

Completion Promise

--completion-promise "KARPATHY_WILL_APPROVE_EVERY_SINGLE_LOC_FOR_SURE"

Auto Fixer

Prompt

STOP! Re-read all code, assess PR comments. Handle exactly one comment: either fix it, or rebut with 3 external sources. Fix any dirt found along the way. Lean, elegant, zero defensive programming.

Completion Promise

--completion-promise "NO_COMMENTS_REMAINING_IN_GITHUB_EVEN_AFTER_20_MINUTES"

Auto Builder

Prompt

STOP! Re-read all code, assess GitHub Issues. Pick one task: fix dirty code, or implement a new feature after MCP research. Lean, elegant, zero defensive programming.

Completion Promise

--completion-promise "NO_REMAINING_TASK_AND_KARPATHY_APPROVES_EVERY_SINGLE_LOC_IN_ITS_ENTIRETY"

Common Element

Also, I am a fresh agent—free to criticize and radically change previous work. Karpathy's philosophy: delete and simplify. Code is liability; prefer well-maintained libraries over custom code. UI libraries: optimize, don't delete. Re-read all the sources from zero. Use MCPs and web searches—traditional knowledge is stale. Commit and push at the loop end. Any edit means I need a fresh iteration. SWOT analysis first, then work.

Detailed review

<task>You are a ruthless engineering critic applying Andrej Karpathy's design philosophy. Read the architecture plan at PLAN LINK.
Karpathy's core principles:- Code is liability. Every line you write is a line you must maintain.- Delete and simplify. If something can be removed without breaking the system, remove it.- Prefer well-maintained libraries over custom code.- Zero-defensive design. Don't code for hypotheticals that haven't happened yet.- Start with the simplest thing that works. Add complexity only when forced by reality.- "Demo is works.any(), product is works.all()" -- but V1 is closer to demo than product.- Overfit a single batch before scaling up.
Apply these principles to the plan. For each section, ask:1. Is this needed for V1, or is it speculative engineering?2. Can this be deleted or simplified without losing core value?3. Is this solving a problem we actually have, or a problem we might have?4. Would a 10x engineer look at this and say "too much"?
Be brutal. Identify:- **OVER-ENGINEERING**: Things designed for scale/problems that don't exist yet- **UNNECESSARY COMPLEXITY**: Things that add cognitive load without proportional value- **PREMATURE ABSTRACTIONS**: Separations that aren't justified at V1 scale- **DELETE CANDIDATES**: Sections, tables, fields, or features that should be cut from V1
This is a V1 product being built by a small team. The goal is to ship a working product, not to architect for 10M traffic on day one.
Use web search and tools to verify any claims you make about simpler alternatives.</task>
<structured_output_contract>Return findings in these sections:1. VERDICT: Would Karpathy approve? One line.2. DELETE: Things to remove entirely3. SIMPLIFY: Things to keep but make simpler4. KEEP: Things that are correctly lean5. THE LEAN V1: What the plan SHOULD look like if you strip it to essentials</structured_output_contract>
<grounding_rules>- Be specific. Don't say "simplify the schema" -- say which fields to cut.- Every DELETE must justify what you lose and why it's acceptable for V1.- Every KEEP must justify why it's essential, not just nice-to-have.- Think from the perspective of "what do I need to ship in 2 weeks?"</grounding_rules>

• AutoBuilder

Cursor is incredibly good harness.

Opus is also not Oputhetic anymore

This is a story about how I lost $10,000,000 by doing something stupid.

The Beginning

The model they used for Basecamp was to build great software that scratched their own itch (project management,) and charge a monthly recurring amount to give them access (SaaS) assuming others had the same problem. Then, focus on organic growth via product improvement and public writing. Finally, spend less than they make!

When we turned on billing for our beta users, we jumped to 20k MRR in the first month. We started growing at 10% per month and were the new hotness. I got reach outs from all the top VCs and tons of tech luminaries started using the product. We'd made it…or so I thought. We consistently spending 2-3x our monthly revenue and losing money. Not venture capital. Out of my personal bank account, hopes in making much more.

Asana

Then, Asana. With a team a quarter of the size, and a fraction of the money, we had built what I felt was a superior product. Around this time, Dustin invited me for a coffee in San Francisco. He implied--in the nicest possible terms--that they were going to crush us. He walked me through who was backing them, how much cash they had, how they had hired top executives from huge companies, and that it was only a matter of time until they beat us on product and outspend us on marketing.

I laughed! I was on the bootstrapping train. He was drinking Silicon Valley KoolAid. Nice try! I told him let the games begin and we left with a friendly handshake. Flow kept growing quickly, but our customers were demanding.

Asana quickly released clients on all platforms. After all, they had a dev team 5x the size. Suddenly it was a key feature when people compared Asana and Flow side-by-side. Mobile was table stakes. We had to keep up. Almost overnight, our burn doubled. We lost the war, due to inexperience, product myopia, and a lack of capital in a highly capital intensive and competitive space.

Takeaways

1. If you are in a competitive VC-funded space, it's foolish to compete without raising money. Don't bring a knife to a gun fight.
2. The best product doesn't always win, and product is not a longterm competitive advantage.
3. If a tree falls in the forest and nobody is around to hear it, it didn't fall.
4. Every developer in the world wakes up thinking I should build a to-do list app and people love jumping between productivity apps and workflows. There is no moat in productivity--avoid it if you can.
5. Running a SaaS business without deeply understanding churn, LTV, CAC etc, is like flying a plane without instrumentation--really stupid and dangerous.
6. Failure sneaks up on you slowly, then all at once.
7. R&D is EXPENSIVE. Especially when competing with venture.
8. If you're competing on features, it never stops and is an ever-increasing line item.
9. Good product with great marketing beats amazing product with no marketing.
10. Bootstrapping works best in uncompetitive spaces/niches or if you have an unfair advantage (a personal brand, unique customer acquisition channel, etc).