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

Banks falling behind the tech is a familiar story in the U.S., But I am confident Korea will take it to the next level. You need to install seven different programs and plugins that constantly run, slowing down your computer to check your account balance; you need to create a non-exportable digital certificate file to make any transactions.

Where it all began

It all starts with the Export of cryptography from the United States. When the internet was booming in 1999, Korea couldn't correctly use the 128-bit AES encryption technology, so they started from a weakened 40-bit security system. They then later developed their version of a 128-bit security system which required ActiveX and made it a standard (SEED.)

In 2000, the U.S. lifted export restrictions, but Korea continued to use SEED and ActiveX. While they later removed ActiveX systems, they switched to mandating .exe security programs running on the device constantly. As Wladimir Palant found out, these programs are uncomfortable and do not even conform to ancient security techniques. Moreover, they are developed with 15-year-old Visual Studio, causing avoidable security problems like simple Buffer Overflows Attacks. But why? Why are they still not improving things? Some key observations:

Dodging Responsibilities

There is a Korean law stating:

A financial institution or electronic financial provider shall be responsible for compensating the user for damages caused by accident caused by forgery or alteration of an access medium, contract signing, or electronic transmission or processing of transaction instructions.

However, some Korean banks figured they could use their security systems' complexity to shift responsibility onto customers during a security breach. Paired with highly vague terms and conditions, the bank points to these terms and conditions as evidence that the customer was aware of the risks and agreed to assume responsibility for any damages.

Limited Room for FDS

Korean banks, by default, do not have a deferred transfer system, unlike the U.S., which has a tipping system. That means every transaction is instant and irreversible. Therefore, implementing a fraud detection system (FDS) makes it more challenging, as there is limited time to detect and stop fraudulent transactions before the transaction. In contrast, a deferred transfer system like the one used in the United States can provide more time for banks to identify and prevent fraudulent transactions, as banks can cancel or reverse transactions before they are processed. Instead, Korean banks rely on individual customers to monitor their accounts for suspicious activity and report it to the bank, meaning that customers are responsible for detecting fraudulent transactions.

Lack of Competitions

The Korean market is known to have limited competition in some industries, including the banking sector. Several factors contribute to this, including:

• Linguistic and regional barriers. The Korean language is unique, and many Korean consumers prefer to do business with companies fluent in Korean and understand Korean culture.
• Resistance to external influence. Koreans have great national pride and are often wary of external parties playing a significant role in their economy.
• Lobbying and Corruptions. Allegations of corruption have been made against Korea Financial Telecommunications and Clearings (KFTC). This company is one of five authorized certification system companies and makes millions of dollars. The KFTC should be a public interest organization created by the state. Still, high-ranking officials from the Financial Services Commission are accused of colluding with the company after retirement, leading to questions about why they are attracted to such positions.
• Perception of overseas banks. Finally, there is often a perception in Korea that using overseas banks or doing business with foreign companies is unpatriotic or unethical.

For these reasons, the Korean market, including the banking sector, has limited competition.

Conclusion

Despite the challenges and limited competition in the Korean banking sector, the emergence of new fintech companies like Toss and KakaoBank has brought some positive changes. These companies have disrupted the traditional banking industry with innovative digital solutions and customer-centric approaches, providing more options for Korean consumers. With the rise of fintech and the changing expectations of consumers, traditional Korean banks must adapt to stay competitive. While the industry still faces obstacles, the growth of these new players shows the potential for more competition and innovation in the Korean banking sector.