The thing that makes Mac Budkowski’s account of building Cryptosaurus with vibecoding worth reading is not that 100 hours of work remained after the prototype worked. What is worth examining is why anyone would expect otherwise.
Vibecoding, the term Andrej Karpathy coined in February 2025 to describe letting an LLM write code while you navigate by feel rather than comprehension, compresses one specific kind of work: the translation of a clear mental model into typed, syntactically correct code. That work has always been a small fraction of what software engineering actually is. The 100 hours that vibecoding does not solve are the hours that were never about typing.
What the 100 Hours Contain
Fred Brooks wrote “No Silver Bullet” in 1986. The central argument was that software development has two kinds of difficulty: accidental complexity, which comes from the tools we use (languages, compilers, environments), and essential complexity, which is inherent to the problem itself. Brooks argued that all the productivity improvements of the prior decades had attacked accidental complexity, and that no tool could eliminate essential complexity because essential complexity is the problem itself.
Vibecoding attacks accidental complexity with remarkable efficiency. Writing boilerplate, scaffolding a new route, wiring up a library you have not used before, generating a migration file, converting a Python class to TypeScript, all of this qualifies as accidental complexity in Brooks’s sense. The LLM handles it well because it has seen it thousands of times and the correct output is well-defined.
The hours that remain are essential complexity. They include:
Error handling at the boundary. Vibecoded code reliably handles the happy path. The LLM generates what a successful request looks like. Production systems fail in ways that demo paths never exercise: network timeouts, partial writes, malformed third-party responses, rate limits, stale tokens. Writing code that handles these cases requires understanding what can go wrong, which requires either reading the generated code or holding a mental model of the system. Neither is what vibecoding optimizes for.
Security hardening. Cryptosaurus is a crypto tool, which means it handles keys, potentially wallets, API credentials, and financial state. Vibecoded code for a demo does not need CSRF protection, input sanitization, safe secret handling, or authorization checks beyond the surface the demo exercises. A production version does. None of this emerges from the LLM without specific, knowledgeable prompting, and knowing what to prompt for requires domain knowledge that the “vibe” abstraction does not capture.
Observability. A prototype that works in your terminal has no logging strategy, no metrics, no alerting, no distributed tracing. Adding these after the fact means understanding what the code does well enough to instrument it meaningfully, which is the opposite of vibecoding. The gap between “it works on my machine” and “I can tell when it is broken in production” is almost entirely in those 100 hours.
Testing. Vibecoded code tends to be structurally difficult to test. Tests require seams, and LLMs generating code for a working demo have no incentive to introduce them. Retrofitting testability often means refactoring, which means reading the code, understanding it, and owning it, exactly what vibecoding deferred.
State management edge cases. Demos show state in the expected transitions. Production systems encounter users who hit back, refresh mid-operation, run two tabs, lose their session, or interact in sequences the demo never exercised. Handling this requires reasoning about state machines, which is inherently design work that cannot be vibecoded.
The Ownership Problem
There is a structural issue that the hour count does not fully capture. Vibecoded code has no author in the traditional sense. The developer who vibecoded a project understands the requirements and the high-level shape of the solution, but not the implementation. This creates a kind of accountability gap that previous productivity tools did not produce.
When you use a framework like Rails or Django, you do not write the framework code, but you understand the contract it provides. When you use a library, the documentation describes what it does and what invariants it maintains. Vibecoded implementation code has no such documentation, and its behavior is not specified except by what the LLM happened to generate. Debugging requires reading unfamiliar code, making changes requires reasoning about code you did not choose, and the codebase has no human advocate who understands it deeply.
The ownership gap is an inherent property of the technique. Karpathy was explicit that he barely read the generated code; that is what distinguishes vibecoding from LLM-assisted development. The gap is the cost of the speed.
The No-Code Parallel
This gap between demo and production is not new to vibecoding. The no-code and low-code movement of the 2010s hit the same wall. Bubble, Webflow, Glide, and their siblings enabled non-developers to build functioning applications quickly. The production equivalent of those 100 hours showed up as performance problems at scale, difficulty handling edge cases the visual builder did not anticipate, inability to integrate with systems the platform did not natively support, and the fundamental question of what happens when the platform’s mental model diverges from your requirements.
No-code platforms addressed this by constraining the problem space tightly. Shopify themes are fast to build because Shopify has already made hundreds of architectural decisions for you; accepting those constraints is the product’s value proposition. Vibecoding does not constrain the problem space in the same way. It operates on arbitrary software problems, which is both its strength and why the ownership problem is harder to escape.
What Vibecoding Is Actually For
None of this means the technique is without value. Vibecoding compresses the prototype phase dramatically, and prototypes have real value. Validating a product idea, testing a technical assumption, building a demo for a stakeholder, generating a starting point for a greenfield project, these are legitimate uses where the 100-hour gap is not a problem because the prototype does not need to become a production system.
Budkowski’s Cryptosaurus account is valuable precisely because it documents what happens when it does need to become one. The 100 hours are not a surprise once you understand what they contain. They are the essential complexity that no tool has ever been able to remove, because removing essential complexity would require understanding the problem, and understanding the problem is the work.
The gap between a vibecoded prototype and a working product is the same gap that has always existed between any prototype and a working product. Vibecoding accelerates one side. The other side is not a productivity problem.