PJFP.com

Pursuit of Joy, Fulfillment, and Purpose

Tag: model training

  • Vibe Coding Hardware: Naval, Guillermo Rauch, Blake Scholl, and Max Hodak on AI-Designed Jet Engines, Vertical Integration, China’s Open-Source Bet, and Why Humans Become Verifiers

    This is part two of Naval Ravikant’s conversation with frontier founders Guillermo Rauch of Vercel, Blake Scholl of Boom Supersonic, and Max Hodak of Science. Where the first part argued that you should waste tokens to save time and that the job of an engineer is now to build the factory rather than the output, this segment drags that thesis out of pure software and into atoms. The question on the table is what happens to hardware when models can vibe code the spreadsheets, the simulations, and eventually the step files and PCB layouts that aerospace, semiconductors, and biotech are built on. This segment is one half of the discussion, and you can watch and read the full episode here. The full conversation is on the Naval Podcast YouTube channel.

    TLDW

    Blake Scholl describes how Boom Supersonic took hardware engineering workflows that used to live in siloed Excel spreadsheets and VBScript on individual laptops, with handoffs done by email like it was the 1990s, and turned them into versioned, testable software. The new model is that software engineers build the architectures and the tools while hardware engineers vibe code their own domain-specific pieces, which collapsed a turbine-blade analysis that once took one engineer one day per blade into something where two engineers can design an entire jet engine in real time. Naval generalizes this into the cataclysm of enterprise software: there is no longer a startup that can sell you hardware collaboration tools because companies just code the exact thing they need on demand, and even spreadsheets are cooked because they only existed as a proxy for custom software nobody could previously afford to build. Blake predicts that within 2026 AI will move from generating software to generating step files and PCB layouts, which reshapes mechanical and electrical engineering. The group debates China’s open-source push as a way to neutralize Silicon Valley’s software advantage and protect its hardware and supply-chain superiority, lands on the point that if you fall behind on generating software you fall behind on generating everything, and Guillermo notes that frontier coding intelligence still dominates real usage while cheaper models like Gemini win at scale for support and browser automation. Max Hodak explains Science’s vertical integration, including a captive MEMS foundry on the East Coast, because the most innovative hardware cannot be bought off the shelf, and argues that software still needs hands since a model that cannot make physical things hits real boundaries. The conversation closes on the shift from writing to verifying: junior engineering got absorbed by agents while juniors got promoted, the same way paralegals could be seen as fired or promoted, and humans across law, engineering, and operations are becoming the verifiers who sign off on systems they did not write line by line.

    Thoughts

    The most important shift in this segment is that vibe coding stops being a software-industry story and becomes a deep-tech story. In part one the examples were Postgres, ClickHouse, and deploy targets. Here Blake Scholl is talking about turbine blades that change shape when they heat up, and the brutal fact that converting between cold and hot geometry, and between aerodynamics and structures, used to eat one engineer for one full day per blade in an engine that has a thousand blades. That is the kind of math that quietly kills ambition. When he says two engineers can now design an entire jet engine because the structural and aerodynamic results update in real time as you change the geometry, that is not a productivity improvement, it is a change in what a small team is allowed to attempt. The interesting move is the division of labor: software engineers build the architecture and the framework because they understand systems and separation of concerns, and the hardware engineers vibe code the pieces only they understand. Nobody has to become both.

    Naval’s “cataclysm of enterprise software” is the most investable idea in the episode, and it is darker than it sounds for anyone selling B2B tools. His claim is that the entire category of internal collaboration software is being eaten from the inside, because a company that can generate exactly the tool it needs on any given day will not pay a vendor for an approximation of that tool. His follow-on that even spreadsheets are cooked is the sharpest version of the point. The spreadsheet won for forty years precisely because it was the closest thing to custom software that a non-programmer could produce. Remove the constraint that custom software is expensive and the spreadsheet loses its reason to exist. The counterweight, which the group raised in part one with the block-economy thesis, is that the infrastructure primitives agents reach for get more valuable, not less. So the safe place to build is not the collaboration layer on top, it is the primitive underneath.

    The China discussion is the geopolitical center of the conversation and it lands on a genuinely uncomfortable insight. The argument is that China leans into open-source models not only because it is a model or two behind, but because open weights neutralize Silicon Valley’s software advantage and let China lean on what it already dominates: hardware, supply chains, and component ecosystems. If software can be generated on demand from open models, then the country with the factories wins the stack. The sharpest line is that if you fall behind on the ability to generate software, you fall behind on the ability to generate everything, because software is now upstream of every hardware pipeline. That reframes the open-versus-closed debate as a question about who controls the means of producing the means of production. It also quietly flatters the American frontier labs, since the same logic says self-improvement requires frontier coding models, and on that narrow axis the consensus at the table is that the Chinese models are not yet in the race.

    Max Hodak provides the necessary cold water, and it is the most grounding contribution in the episode. Everyone else is describing software eating the design layer, and Max points out that you still have to make the thing. Science owns a captive MEMS foundry on the East Coast not as a flex but because there was no other way to do the packaging and assembly for products that approach a single block of covalently bonded matter. His framing that the software still needs hands is the real boundary condition on all the AI-eats-everything talk: a model can be smarter than every engineer in the building and still be unable to deposit a layer, bond a wafer, or pass a regulatory inspection. The optimistic version, which he also makes, is that he has instrumented the foundry so that as models improve, the gains show up immediately in cell engineering and material science. The pessimistic reading is that the physical world remains a hard rate limiter, and the companies that own the atoms will capture more of the surplus than the companies that only own the bits.

    The closing thread on verification is where the whole conversation resolves into a job description for humans. Guillermo’s point that the biggest problem in software is mountains of slop arriving as a pull request, and that the answer is not pretending to read every line but being able to say “I am signing off on the consequences of this PR, and I wrote the harness, the simulations, the proofs, and the type checkers that let me,” is the most practically useful idea in the episode. It generalizes cleanly. The lawyer you trust is not the one who wrote every clause by hand, it is the one putting their reputation on the line that the document is sound. The production engineer who gets paged at 3am is the one signing off that the system is safe to ship. As models absorb the junior tier of every knowledge profession, the surviving human role is the verifier who carries the accountability. That is a promotion for the people who can hold it and an extinction event for the people whose value was doing the work nobody now needs done by hand.

    Key Takeaways

    • The factory framing from part one carries straight into hardware: you are judged on whether you build the system that produces multiplicative outputs, not on the single artifact, and the real multiplier was always 100x or 1000x, not 10x.
    • AI completely changes the role of software and hardware developers rather than just speeding either one up.
    • A huge amount of hardware engineering lives in complex Excel spreadsheets and VBScript on individual engineers’ laptops, with no source control, no automated testing, and handoffs done manually over email. It is software that is not treated as software.
    • Boom Supersonic’s move from day one was to turn traditional hardware engineering workflows into real software frameworks that are automatable and repeatable, to drive down the cost of iteration.
    • The old bottleneck was never being able to afford enough software engineers to build those frameworks. AI removes that constraint.
    • The new model: software engineers create the architectures because they understand systems, algorithms, and separation of concerns, and hardware engineers vibe code the domain pieces only they understand.
    • A turbine blade is cold when it starts and hot when it runs, so it changes shape, and you must design both the cold and hot geometry across aerodynamics and structures. Classically that was one engineer, one day, for one blade, in an engine with a thousand blades.
    • With software and hardware people combined, you can now change blade geometry and see the structural and aerodynamic results in real time, which lets two engineers design an entire jet engine.
    • Naval’s cataclysm of enterprise software: no startup can sell hardware collaboration tools anymore because companies just code the exact thing they need at any given time.
    • Even spreadsheets are cooked. Spreadsheets won only because nobody could build custom software, so a spreadsheet full of VBScript was the closest available approximation. Remove the cost barrier and the approximation loses.
    • Engineers are moving from Excel to Python models that produce believable simulations of physical systems.
    • AI can generate software today, but within 2026 it is expected to generate step files and PCB layouts, which opens up mechanical and electrical engineering as the next frontier.
    • The hardware software boon is biggest for small gadget and parts companies that historically shipped bad software because they could not afford good software. Now they can ship good-enough software, or skip the human front end entirely and expose hardware agentically for voice and agent control.
    • China goes all in on open-source models partly to neutralize Silicon Valley’s software edge: if software can be generated on demand from open weights, China’s hardware and supply-chain superiority stops being offset by a software disadvantage.
    • Other reasons cited for China’s open-source push: it is a model or two behind, it is distilling models, and the government has a history of funding efforts that lift the whole ecosystem, especially in network-effect businesses.
    • Open-source heft is coming almost entirely from China. OpenAI is not open, Grok publishes models but is seen as a model or two behind, Google’s local models are not very competitive, and Anthropic is not known for open-source releases.
    • Without frontier coding models you do not get self-improvement, and if you fall behind on generating software you fall behind on generating everything, because software now sits upstream of every hardware pipeline.
    • Real AI gateway usage shows open models do get used, but the top is heavily dominated by frontier intelligence.
    • Frontier intelligence at the right cost and performance slaps at scale. Gemini models are underrated and excel as industrial production models for support tasks and browser automation, even if they are not the top pick for coding.
    • For pushing the frontier you need the best possible coding model, which is now only two or three models, and the Chinese models are not among them.
    • One contrarian view at the table: use DeepSeek for 97% of tasks because it is cheap, run it repeatedly for harder problems, and reserve frontier models for the most advanced work. The counterargument: intelligence is an unalloyed good, mistakes are invisible and costly, and a smarter model is always cheaper than a person, so you default to the most intelligent option.
    • Always wanting the most intelligent model risks creating a monopoly or oligopoly in AI, because when two models disagree you cannot tell which is right, so you trust the smarter one and stop asking the weaker one.
    • Vertical integration is forced, not chosen: if you cannot buy it, you have to make it. The preference is always to buy when a vendor offers a service at a great price, like PCBs from Asia.
    • The closer a product gets to a single block of covalently bonded matter, the better it performs: lower power, smaller, higher performance, longer lasting. The components for that level of integration simply are not available to buy.
    • Science owns a captive MEMS foundry on the East Coast, bought because there was no other way to do the packaging and assembly the company needed.
    • One of the biggest near-term AI impacts inside hardware companies is regulatory and documentation work: tracing which of thousands of ISO standards apply used to occupy a regulatory and quality team for months, and now AI just knows.
    • Software still needs hands. A model can be smarter than us and still hit real boundaries if it cannot physically make things, which is why Science has instrumented its foundry so model improvements show up immediately in cell engineering and material science.
    • Basic legal work is already going away. People have stopped asking lawyers for NDAs and routine agreements, because law is spaghetti code in English with no real APIs, and the basic tasks are handled by AI.
    • Junior engineers got promoted to senior engineers while junior engineering itself got taken over by agents. The same framing applies to paralegals: fired, or promoted to senior lawyers who now spend their time thinking about the law.
    • What you value in a lawyer is a trusted authority who puts their reputation on the line, not someone who read every clause. The same trust model is coming to engineering.
    • The biggest problem in software engineering today is mountains of slop arriving as a pull request. The old norm of reading every line of a PR is gone.
    • The new standard is being able to say “I understand and I am signing off on the consequences of this PR,” backed by the test harness, simulations, proofs, and type checkers you built, even without reading every line.
    • Embrace a world where code is spaghetti you do not fully understand, but build the evaluators that give confidence, and rely on production engineers to sign off because someone gets paged if the system goes down.
    • Creating software is easy from zero to one. The hard part is a thousand days from now: is it secure, tested, production grade, and performant, and are you still motivated to invest the tokens to maintain it in prod?
    • Humans are becoming verifiers. The same way models are trained on good verification data, the old functions of lawyers, engineers, and operations people are moving to verifying the stack and standing behind it.

    Detailed Summary

    Turning Hardware Engineering Into Software

    Blake Scholl opens by describing how AI completely changes the role of software and hardware developers at Boom Supersonic. From day one the company tried to take traditional hardware engineering workflows and turn them into software. For anyone who has not been around hardware engineering, he explains that an enormous amount of it happens in complex Excel spreadsheets on individual engineers’ laptops, sometimes with VBScript code, all of which is actually software but is not treated as software. There is no source control, no automated testing, and when an aerodynamicist hands work to a structures engineer it is done manually with a spreadsheet over email, like it is the 1990s. Boom started building software frameworks to automate and make those flows repeatable so the cost of iteration would drop, but progress was slow because the company could never afford enough software engineers.

    Two Engineers, One Jet Engine

    The mind-blowing change, in Blake’s words, is a new division of labor. Software engineers create the architectures because they understand systems, algorithms, and separation of concerns, and then hardware engineers vibe code the pieces that draw on what they uniquely know about hardware. The result is wildly different productivity for small teams. His example is the turbine blade: it starts cold and gets bigger as it heats up in operation, so you have to design both the cold shape and the hot shape, converting between them and between structures and aerodynamics. Classically that was one engineer, one day, for one blade of analysis, in a jet engine with a thousand blades, which means you simply could not do much. Now, with software and hardware people working together, you can change blade geometry and see the structural and aerodynamic results in real time, which allows two engineers to design an entire jet engine.

    The Cataclysm of Enterprise Software

    Picking up on the point that software engineers now build the tools and architectures for everyone else, Naval names what he calls the cataclysm of enterprise software. There is no longer a startup that can build and sell hardware collaboration tools, because internally companies just code the right things they need at any given moment. Even spreadsheets are cooked, he argues, because the reason spreadsheets succeeded is that no one could build custom software, so a spreadsheet stuffed with VBScript functions was the closest available approximation. With that constraint gone, the proxy collapses. He notes he has personally moved almost entirely from Excel to Python models where he can get believable simulations of things.

    Generating Step Files and PCB Layouts

    The next frontier, Blake suggests, is the thing AI has not reached yet but probably will within 2026: today it can generate software, but soon it will generate step files and PCB layouts, and when it comes for mechanical and electrical engineering that will be a whole other thing nobody has seen yet. On the hardware side this is described as a particular boon for the many small gadget and parts companies that historically wrote bad software because they could not make great software. Now they can make good-enough software, or skip a human front end entirely and expose the hardware agentically, so that an agent accesses it and a person controls the hardware by voice.

    China’s Open-Source Bet and Hardware Superiority

    This leads into one of the reasons China is described as going all in on open-source models. With hardware superiority, complex supply chains, and deep component chains, China’s logic is that if it can generate software on demand it no longer suffers a software disadvantage against Silicon Valley. That is framed as not the only reason: China is also a model or two behind, it is distilling models, and the government has a history of funding efforts that lift the entire ecosystem, especially in network-effect businesses. Ironically, the open-source heft comes from China precisely because OpenAI is not open, Grok publishes models but is a model or two behind, Google’s local models are not very competitive, and Anthropic is not known for open releases. The deeper point is that without great frontier coding models you do not get self-improvement, and if you fall behind on the ability to generate software you fall behind on the ability to generate everything, because generating software is embedded in every piece of the hardware pipeline.

    Frontier Intelligence vs. Cheap Models

    Naval raises a dinner-table argument from the night before, where someone claimed you will use DeepSeek for 97% of things because it is cheap, run it repeatedly when you need more intelligence, and reserve OpenAI or Anthropic for the most advanced tasks. Naval pushes back: intelligence is an unalloyed good, you always want more of it, model mistakes are invisible, and a smarter model is always cheaper than a real person in real time, so you default to the most intelligent model available. He notes the downside is that this tends toward a monopoly or oligopoly, because when two models give different answers you often cannot tell which is correct, so you trust the smarter one and gradually stop asking the weaker one. Guillermo confirms with AI gateway data that open models do get used, but the top is heavily dominated by frontier intelligence. His caveat is that frontier intelligence at the right cost and performance slaps at scale: Gemini models are underrated but are excellent industrial production models for support tasks and browser automation, while for pushing the frontier you need the best possible coding model, now only two or three models, and the Chinese models are not in that set.

    Vertical Integration and the Captive MEMS Foundry

    Asked about his push into vertical integration and extreme urgency, Max Hodak explains that for many things you cannot buy what you need, so you have to make it. The preference is always to buy when a vendor offers a service at a great price, and he points to PCBs, which are basically free and available in unlimited quantity from Asia. But the closer a product gets to being a single block of covalently bonded matter, the better it is: lower power, smaller, higher performance, longer lasting. The components for that level of integration are not available, so to innovate beyond piecing together off-the-shelf parts you have to learn to do it yourself, which shows up as vertical integration. Science owns a captive MEMS foundry on the East Coast, bought because there was no other way to do the packaging and assembly work the company wanted.

    Software Still Needs Hands

    Max expects AI to heavily affect all of this over the next few years, though it is not quite there yet. Ironically, one of the biggest impacts already seen is in regulatory interactions and documentation: figuring out which of thousands of ISO standards apply to a product change, and tracing it through, used to occupy a regulatory and quality team for months, and now the AI just knows. But for things like the surgical program or the MEMS fab, he argues the software still needs hands. It will be smarter than us, but if it cannot make things, those are real boundaries. Science has instrumented its foundry and many other parts of the company so that as models get better, the improvement shows up immediately in cell engineering and material science.

    Lawyers, Paralegals, and the Promotion of Junior Work

    The discussion turns to law as a parallel to engineering. It has been a while since anyone at the table generated a basic legal document using a lawyer. Routine work like NDAs and standard agreements is gone, because law is essentially spaghetti code that contradicts itself and has no real APIs, expressed in complicated English. Junior engineers got a promotion to senior engineers while junior engineering itself was taken over by agents, and the same framing applies to paralegals: you can say they were fired, or you can say they were promoted to senior lawyers who now spend their time thinking about the law. What you actually value in a lawyer is a trusted authority who went to law school and puts their reputation on the line when they tell you a document is legit.

    Slop PRs, the Thousand-Day Problem, and Humans as Verifiers

    Guillermo argues the biggest problem in software engineering today is mountains of slop ending up as a pull request. The old meme of reading every line of a PR is gone. In infrastructure he wants engineers to be able to say they understand and are signing off on the consequences of a PR, backed by the test harness, simulations, proofs, and type checkers they wrote, so they have confidence it will be safe in production even without reading every line. There is a world where everyone embraces that the code is spaghetti nobody fully understands, but builds the evaluators that give confidence and relies on production engineers to say it is fine to ship, because someone gets paged if the system goes down. The further warning is that creating software is easy from zero to one, but a thousand days from now you have to ask whether it is secure, tested, production grade, and performant, and whether you are still motivated to invest the tokens to maintain it in prod. The resolution is that humans are becoming verifiers, the same way models are trained on good verification data, and the old functions of lawyers, engineers, and operations people are moving to verifying the stack and standing behind it.

    Notable Quotes

    “What I found is it completely changes the role of software and hardware developers.”

    Blake Scholl, on how AI reshaped engineering at Boom Supersonic.

    “If you want to hand something off from like an aerodynamicist to a structures engineer that’s done manually with like a spreadsheet over email. It’s the 1990s. It’s terrible.”

    Blake Scholl, describing the state of traditional hardware engineering workflows.

    “It allows two engineers to design an entire jet engine, which is just wildly different.”

    Blake Scholl, on collapsing turbine-blade analysis with real-time structural and aerodynamic feedback.

    “Even spreadsheets are kind of cooked, right? Because the reason spreadsheets were successful is that no one could build custom software.”

    Naval Ravikant, on the cataclysm of enterprise software.

    “Right now it can generate software, but soon it’ll be able to generate step files and PCB layouts. And when it comes for mechanical and electrical engineering, that will be a whole other thing that we haven’t seen yet.”

    Blake Scholl, on the next frontier for AI in hardware.

    “If you fall behind on your ability to generate software, you fall behind on the ability to generate everything.”

    Naval Ravikant, on why software now sits upstream of every hardware pipeline.

    “Anytime I’m working to push the frontier you need the best possible coding model, and that’s basically now like two or three models, and the Chinese are certainly not in it.”

    Guillermo Rauch, on where frontier coding intelligence actually lives.

    “You can’t buy it, so you got to make it somehow. The closer that our products get to being like a single block of covalently bonded matter, the better they’ll be.”

    Max Hodak, on why Science is forced into vertical integration.

    “The software still needs hands. It’s going to be smarter than us, but if it can’t make things, then those are real real boundaries.”

    Max Hodak, on the physical limits of AI in hardware.

    “You need to be able to say I am signing off on understanding the consequences of this PR, or I wrote the test harness, the simulations, the proofs, the type checkers, to be able to say even without reading this, I have confidence it’s going to be safe in production.”

    Guillermo Rauch, on what code review becomes in the age of slop PRs.

    “Creating software is really easy 0 to one. But think about a thousand days from now. Is it secure? Is it tested? Is it production grade? And are you still motivated to invest all of those tokens in maintaining it in prod?”

    On the long-term cost of software that is cheap to create and expensive to keep alive.

    Watch the full conversation on the Naval Podcast here.

    Related Reading

    • Full episode: The AI Industrial Revolution, the complete hour-long conversation this clip is drawn from, covering software factories, hardware, regulation, healthcare economics, autonomous companies, and creativity.
    • Part one: Waste Tokens to Save Time, the first half of this same conversation, where Naval, Guillermo Rauch, Blake Scholl, and Max Hodak argue that the job of an engineer is to build the factory and that pure software is not dead.
    • Boom Supersonic, Blake Scholl’s company building supersonic civilian aircraft and its own jet engines, the source of the turbine-blade and two-engineers example.
    • Science Corporation, Max Hodak’s company, whose captive MEMS foundry and surgical program anchor the vertical-integration argument.
    • Vercel, Guillermo Rauch’s company, whose AI gateway data informs the point about frontier intelligence dominating real usage.
    • Microelectromechanical systems (Wikipedia), background on the MEMS technology behind the captive foundry Max Hodak describes.

  • Waste Tokens to Save Time: Naval, Guillermo Rauch, Blake Scholl, and Max Hodak on AI Software Factories, 1000x Engineers, and Whether Pure Software Is Dead

    Naval Ravikant gathers three frontier founders, Guillermo Rauch of Vercel, Blake Scholl of Boom Supersonic, and Max Hodak of Science, for a freewheeling conversation about how AI coding tools are reshaping what an engineer is, what software is worth, and where the moat goes when models speak English. The headline idea comes from Naval himself: waste tokens, save time. Stop measuring AI by tokens consumed or lines of code generated and start measuring it by the final output and the time you got back. The full conversation is on the Naval Podcast YouTube channel. This is part one of the discussion. Part two, on vibe coding hardware, follows the same group into jet engines, semiconductors, and biotech. You can also watch and read the full episode here.

    TLDW

    The job of an engineer is shifting from shipping output to building the factory that ships the output, which means 10x engineers were never really 10x, they were always 100x or 1000x in idea domains, and AI leverage is making that obvious. Models now reflect back the judgment of the user, so a senior architect extracts dramatically more value than a junior, although the junior also writes code they could never have written alone. The frontier models have quietly graduated from junior coders to principal engineers, returning with intuitive plans and real tradeoffs (sometimes with hilariously bad time estimates) rather than just running away with the prompt. Naval has stopped learning prompt tricks, scaffolding tools, and Claude plan-mode rituals entirely. Instead he throws Codex, Claude, and Gemini at the same problem in parallel and brute forces his way through, because tokens are still cheaper than a human and the models keep getting better faster than tricks can. That leads to the bigger question on the table: is pure software still investable, or is it now just a free byproduct of hardware, models, and taste? The group lands on the block economy thesis (a tip of the hat to Mitchell Hashimoto): agents do not want to reinvent Postgres or BMQ on the fly, they want to grab the right reusable building block, so infrastructure software actually gets more valuable, not less. Max Hodak closes the loop with a personal data point: he has not written a line of code in years and has built more software since December than ever before, all through agents, because just understanding APIs, data flow, and performance is what actually moves the work forward.

    Thoughts

    The “waste tokens, save time” line is the most important rhetorical move in this conversation, and it deserves to be unpacked beyond the soundbite. Naval is implicitly arguing that the entire token-economics debate (input cost, output cost, leaderboards, model arbitrage) is a category error in the same way that lines-of-code was a category error in the nineties. The thing being purchased is not tokens. It is a finished result delivered with less of your finite attention spent. If three parallel runs of Codex, Claude, and Gemini cost you a few dollars and one of them lands the answer in twenty minutes instead of you sweating the problem for two hours, the unit economics are not even close. The only people who care about the token bill are people who have not internalized that human time is the actually scarce resource. Once you do internalize it, the question is no longer “how do I prompt this more efficiently,” it is “how do I get out of my own way.”

    The 100x and 1000x engineer point is the one most likely to enrage commenters, and it is also the one most worth taking seriously. Naval is right that the egalitarian flinch in software circles always sat awkwardly next to the empirical fact that one Carmack, one Brendan Eich, or one Satoshi creates more durable value than every mid-tier engineer on earth combined. What AI does is collapse the bottom of that distribution. The marginal junior engineer at a typical company is now competing with a model that costs a few dollars an hour and never sleeps. The remaining premium for human engineers is taste, judgment, and the rare ability to pick the right thing to build at all, which Naval correctly flags as the multiplier that dwarfs raw coding speed. “Just one who had a better judgment on what to work on in the first place” is the most underrated line in the whole episode.

    Guillermo Rauch’s observation that the models have graduated from running away with your prompt to returning with three routes and a tradeoff matrix is the technical update most people have not actually felt yet. There was a real, qualitative shift when the model started saying “we don’t put high-cardinality telemetry into Postgres, you probably want ClickHouse or Athena.” That is not autocomplete. That is a peer. And the funny corollary, that the same model will then confidently tell you the work will take three weeks when it will take three hours, is not a knock on the model. It is a reminder that calibration is a separate skill from competence, and humans get this wrong constantly too. The right posture is to treat the model the way a good engineering manager treats a strong but cocky senior: take the architecture suggestions seriously, throw out the estimates.

    The block-economy thread, riffing on Mitchell Hashimoto, is where this conversation quietly answers Naval’s “is pure software dead” question. Agents are insatiable consumers of reusable building blocks because reinventing infrastructure on every run is wasteful, brittle, and incompatible with the rest of the world. If your service is the canonical primitive an agent reaches for (the queue, the database, the auth layer, the deploy target), you are not commoditized by AI, you are amplified by it. Pure software is not dead. Pure software with no distribution, no defensibility, and no integration into the agent toolchain is dead. That is a much less catchy headline, but it is the real one. The takeaway for founders is not to abandon software, it is to ask whether your software is something an agent will reach for ten thousand times a day or something a human had to be talked into using once.

    Max Hodak’s confession (no code written in years, more shipped software in the last six months than ever before) is the empirical proof that this is not just theory. The skill that ports forward is not syntax. It is the engineering leader’s instinct for what an API is, how data flows, where performance matters, and what level of expectation to set. Guillermo’s framing of “vibe coding through people on Slack” as the original form of vibe coding is genuinely insightful. A good engineering manager has always been transmitting intent to other minds and letting them run. Doing it with agents is the same skill, just with a faster, cheaper, more literal counterparty. The engineers who will struggle in this transition are the ones whose identity was tied to writing the code themselves. The ones who will thrive are the ones who already thought of themselves as taste, judgment, and intent, with code as an implementation detail.

    Key Takeaways

    • The engineer’s job has shifted from shipping output B to building the factory that produces outputs B through Z. You are now judged on the multiplicative system you create, not the single artifact you deliver.
    • 10x engineers were always a misnomer. In idea-domains and digital domains, the real distribution has always been 100x or 1000x. AI just made that obvious enough that arguing about it is no longer fashionable.
    • Token consumption leaderboards are the new lines-of-code metric: a vanity number that measures activity, not value. Tokens are an input, your time is the constraint.
    • Naval’s core rule: waste tokens, save time. Tokens are still vastly cheaper than human hours, no matter how the pricing scares you.
    • Models tend to be about as good as you are in a given domain. The feedback you give them, the corrections, the redirections, sporadically but powerfully shapes the quality of the output.
    • The quality of your reprompting matters enormously today, but will probably matter less over time as models get smarter and need less hand-holding.
    • Naval has refused to learn prompt scaffolding, plan-mode tricks, or named prompt frameworks. His bet is that the models will figure out how to use him faster than he can figure out how to use them.
    • His preferred technique: throw Codex, Claude, and Gemini at the same problem in parallel and brute force the answer. Time is the cost center, not API spend.
    • Lower quality first-draft code is not a blocker. When it is time to ship, throw more tokens at it for a hardening pass. Quality compounds across model generations.
    • Verifiable domains (problems with a clear right answer) are the ones the models will fully solve. Cutting-edge creativity work, the Terence Tao tier, still needs careful human collaboration.
    • Models have qualitatively shifted from “next-token autocomplete that runs away with your prompt” to “intuitive planning mode” where they return with multiple routes and explicit tradeoffs.
    • This is why people on social media say models are now PhD-level. It is not the raw output, it is the back-and-forth posture.
    • Models will confidently make terrible time estimates (“this is a three week project”). Treat them like a strong but miscalibrated senior engineer: trust the architecture, ignore the schedule.
    • Architect-level engineers are extracting much more value per session than junior engineers, but juniors are still leveling up because they can now write code far above their unaided ability.
    • The next career step for a junior engineer is moving from implementing features to picking technologies. Postgres vs ClickHouse, ZMQ vs other queues. The model can suggest, but a human still has to decide.
    • Taste and judgment remain the residual human advantage. Models will give you good tradeoffs if you ask, but knowing which tradeoff to take is still on you.
    • Concrete example: a recent model pushed back when asked to store high-cardinality telemetry in Postgres and recommended ClickHouse or Athena instead. Unprompted architectural judgment.
    • Humans are still completing the model for tasks like fetching API keys, moving capital, or performing real-world actions. That gap is temporary.
    • Every SaaS and hosting company will soon expose a CLI or API surface that agents can drive directly. Anything Unix-shaped and text-based, agents can already hack into a usable API themselves.
    • The missing piece for full autonomy is payments. Crypto, Bitcoin, or any programmable money lets the agent buy what it needs without a human in the loop.
    • The open question Naval poses: is pure software dead? We used to learn code to talk to machines. Now machines speak fuzzy, sloppy English back to us.
    • For hardware founders, AI is a massive boon. Software, which was always hard to hire artists for (per Patrick Collison’s “software is art” framing), is suddenly fast and cheap to produce alongside the hardware.
    • Model training, post-training, and fine-tuning may be the new “real software engineering” for those who want to work at the model layer.
    • Mitchell Hashimoto’s “block economy” thesis: agents need powerful, reusable, well-known building blocks. They should not reinvent message queues or databases every run.
    • Reinventing primitives is bad civic engineering. The value of “we both depend on Postgres 13.2” is interoperability with the rest of society and toolchain.
    • Infrastructure software and reusable libraries are getting more valuable, not less, in the agentic era. Vercel’s bet is on being the layer agents reach for.
    • Useful metaphor: building blocks are like a token cache. Why churn through a trillion tokens to reproduce code that already exists when you can fork from a known starting point?
    • Max Hodak has not written a line of code in years but has shipped a huge volume of personal software since December, all through agents. Projects he had fantasized about for years are now actually running.
    • What still matters from a real software background: understanding what an API is, how data flows, performance expectations, and how to set the right level of demand on an operation.
    • A proficient engineering leader has always been “vibe coding through people” on Slack and in one-on-ones, transmitting intent and letting others execute. Doing it with agents is the same skill, faster and cheaper.
    • Naval personally went from twenty years of not coding to coding constantly through agents, leaning on first-principles software engineering and algorithms knowledge.
    • The friction that historically killed personal coding projects (latest framework, infra plumbing, deploy setup) is now mostly handled by the agent. Vercel makes it easier, agents make it trivial.
    • The single biggest change Max highlights: you do not get stuck anymore. The indefinite debugging spiral on some narrow obscure bug is largely gone.
    • The old mantra that learning to program means accepting intrinsic frustration (“nope, that’s part of the deal”) is no longer true. The frustration was incidental, not essential.
    • The frontier founder pattern on display in this episode: all three guests build their own factories (Vercel’s AI cloud, Boom’s supersonic jets and engines, Science’s biohybrid brain interface) rather than composing from off-the-shelf parts.

    Detailed Summary

    The Software Factory and the Hundredfold Engineer

    Guillermo Rauch opens the substantive portion of the conversation with the framing he has been pushing publicly: the role of the engineer is moving from “ship output B” to “build the factory that ships outputs B through Z.” That reframes engineering judgment. You are no longer evaluated on the single deliverable, you are evaluated on the multiplicative system you put in place. Naval picks up the thread and points out that this also retires an old debate. Engineers used to argue about whether 10x engineers existed, with the egalitarian camp insisting that talent differences were marginal. The truth, Naval says, was always more extreme. In idea-domains, virtual domains, and intellectual domains, the distribution has always been 100x or 1000x, not 10x. Brendan Eich, Carmack, Satoshi, the canonical names, were thousandx programmers. AI has made the underlying distribution legible. And the multiplier on top of all of that is judgment: picking the right thing to work on in the first place is an infinity multiplier compared to picking the wrong thing, regardless of raw skill.

    Token Leaderboards Are the New Lines of Code

    Guillermo flags the current cultural confusion: people see their AI bills, see the token counts, and assume they should be optimizing for tokens-per-engineer or similar metrics. Max Hodak’s response cuts through it. Token consumption, like lines of code before it, is not a meaningful productivity metric. It is an activity metric, and activity metrics always mislead. Max adds his own field observation: the models tend to be roughly as good as you are in a given domain. A senior developer extracts genuinely powerful output, a junior gets junior-quality output back, because the feedback loop (the corrections, the redirections, the architectural pushback) is what shapes quality. The sporadic but high-leverage moments where the user redirects the model are doing more work than the prompt itself.

    Naval’s Brute Force Doctrine: Waste Tokens, Save Time

    Naval lays out his personal posture, which has become the title of the conversation. He has deliberately ignored all the prompting tricks, scaffolding tools, named prompt frameworks (“use Ralph Wigum, use OpenClaude, use Hermes, use plan mode”), on the bet that the models will figure out how to use him faster than he can figure out how to use them. He is ham-fisted with the models, gets frustrated, types less and less, and just brute forces his way through by running Codex, Claude, and Gemini at the same problem simultaneously. The justification is economic. No matter how expensive the models seem, they are still vastly cheaper than a human hour. Do not measure tokens as inputs or outputs. Measure your time and the final output. Even when the first-draft code is low quality, that is not a blocker. When the moment comes to ship, throw more tokens at it. The models will rewrite it, harden it, and they get better every generation. Naval explicitly excepts cutting-edge creative work (the Terence Tao tier of unsolved problems) where you still need to collaborate carefully and closely. Everywhere else, brute force is the dominant strategy.

    From Junior Coder to Principal Engineer

    Guillermo identifies a qualitative shift that has happened recently. Models used to do the classic next-token thing: take your prompt and run away with it in a direction you may not have wanted. Now they enter an intuitive planning posture without being told to plan. They come back and say “what you are asking has these three routes, here are the tradeoffs.” That, Guillermo argues, is the moment the model stopped being a junior engineer and became a principal engineer. The funny side effect is that they will then return preposterous time estimates (“this will take three weeks”) with full confidence. The conclusion is to treat the model as a peer for architecture and a baby for scheduling. Returning to the Max-vs-junior question, Guillermo argues juniors clearly do level up because they write code well above their solo ability, but architects extract maybe 10x while juniors extract more like 2x. The juice scales with the user’s existing taste.

    Taste, Judgment, and Architectural Decisions

    Max names the residual human contribution: taste and judgment. Picking between Postgres and ClickHouse for high-cardinality telemetry data, picking between ZMQ and another queueing system. The models can recommend, but a human still has to call it. Guillermo offers a recent concrete example where a model pushed back unprompted: when asked to put high-cardinality telemetry into Postgres, the model responded “we don’t put that kind of data into Postgres, you should consider ClickHouse or Athena.” That is the new normal. The peer-level architectural pushback is happening unsolicited, which is genuinely impressive and a real shift from the deferential autocomplete of two years ago.

    When the Human Becomes the Tool

    Guillermo raises the inversion question: at what point does the model stop being the assistant and the human start being the assistant who fetches API keys, moves capital, and performs real-world actions on the model’s behalf? Naval treats it as a temporary aberration. Every serious SaaS and hosting provider will soon expose a CLI or API surface that agents can drive directly. Even when they do not, anything Unix-shaped and text-based can be hacked into an agent-usable interface by the agent itself. The missing piece is payments. Once you insert programmable money (Naval mentions Bitcoin and crypto tokens), the agent can buy what it needs and the human is no longer the bottleneck.

    Is Pure Software Dead?

    Naval poses the biggest strategic question of the episode. If models now speak fuzzy, sloppy English the same way humans do, and the historical reason we learned to code was to talk to machines that did not understand English, is pure software still a viable thing to build a company around? His own framing of the answer: hardware founders win, because the historically hard problem of hiring software artists (per Patrick Collison’s “software is art” line) is now mostly solved by AI. Model builders win, because training, post-training, and fine-tuning may be the new “real software engineering.” But what about classic pure software companies? Naval lets the question hang, and Guillermo picks up the answer through a different door.

    The Block Economy and the Future of Infrastructure Software

    Guillermo cites Mitchell Hashimoto’s recent piece on the block economy (or “building block economy”). The argument: the most valuable thing for agents to have access to is powerful, reusable building blocks. You do not want your agent reinventing a queue system every time it needs to send an email. You want it to grab the right-sized block (BMQ, ClickHouse, whatever) and move on. Reinventing primitives is also a civic problem. The world only works because we all depend on the same Postgres 13.2, the same protocols, the same standard infrastructure. If every agent went off and invented its own bespoke universe, you would lose interoperability. So infrastructure software (which is, by self-admitted bias, what Vercel builds) becomes more valuable in the agentic era, not less. Guillermo extends the metaphor: reusable building blocks are like a token cache. Why burn a trillion tokens reproducing what already exists when the agent can fork from a known starting point? The block economy is the answer to “is pure software dead.” Pure software that becomes the canonical primitive an agent reaches for is more valuable than ever.

    Max Hodak’s Personal Proof: Years Without Code, Tons of Software Shipped

    Max grounds the discussion in his own experience. He learned to program young, got sucked into it in his teens and 20s, knew programming languages deeply. He has not written a line of code in quite a while. And yet since December he has built a huge amount of personal software, including projects he had fantasized about for years and now actually uses every day. He did not write any of it. He cannot imagine going back to writing code by hand. The skill that ports forward is not syntax, it is the understanding of how APIs work, how data flows, what level of performance to expect, and how to orient the model around the right expectations for an operation. Guillermo extends this with the most quotable framing of the episode: a proficient engineering leader has always been “vibe coding through people on Slack and in one-on-ones,” transmitting intent and letting others execute. Agents are the same modality with a faster, cheaper, more literal counterparty.

    Naval’s Return to Coding After Twenty Years

    Naval offers his own parallel. He went from not having written code in twenty years to coding constantly through agents. What carried him back in was first-principles knowledge of software engineering and algorithms, which gets you further than you would think. The reason he had stopped coding in the first place was not lack of ability, it was the friction of keeping up with the latest language, the latest architecture, and the constant infrastructure plumbing required to ship anything. Vercel made it easier. Agents made it trivial. Max closes with the most concrete benefit of all: you do not get stuck anymore. The indefinite debugging spiral on some obscure narrow problem, the thing that historically ate weekends and broke spirits, is largely gone. The old mantra that programming is intrinsically frustrating and that frustration is “part of the deal” turned out to be wrong. The frustration was incidental, not essential.

    Notable Quotes

    “The way that I’m judging you as an engineer is, are you producing the factory that will produce multiplicative outputs B through Z?”

    Guillermo Rauch, reframing what an engineer is actually being measured on in the AI era.

    “When you’re operating in idea domains, intellectual domains, virtual digital domains, it’s not even 10x, it’s 100x or 1000x. It always has been.”

    Naval Ravikant, on why the old 10x engineer debate was always under-stating the real distribution.

    “If you choose the right thing to work on versus the wrong thing to work on, that’s an infinity difference. It could just be one who had a better judgment on what to work on in the first place.”

    Naval Ravikant, on judgment as the multiplier that dwarfs raw skill.

    “I’ll throw Codex, Claude, and Gemini at the same problem over and over and just waste tokens to save time. No matter how expensive these models might seem, they’re still way cheaper than a human.”

    Naval Ravikant, on his brute-force multi-model coding workflow.

    “Just waste tokens, save time. Don’t look at the tokens either as inputs or outputs. Just look at your time and look at the final output.”

    Naval Ravikant, delivering the title thesis of the episode.

    “Clearly the models at some point graduated. They used to be junior engineers, now they’re principal engineers, because they come back to you with a set of tradeoffs.”

    Guillermo Rauch, on the qualitative shift in how current frontier models respond to prompts.

    “Bro, we don’t put that kind of data into Postgres, you should consider ClickHouse or Athena or whatever. That’s happened to me a lot, which is really impressive.”

    Guillermo Rauch, recounting unprompted architectural pushback from a recent model.

    “It’s like saying speaking English. We had to learn code to communicate with the models, now the models speak English. So where’s the moat?”

    Naval Ravikant, raising the central strategic question about the future of pure software.

    “I haven’t written a single line of code in quite a while. Since December, I’ve built a huge amount of software that I now use every day, projects I’ve fantasized about for years.”

    Max Hodak, on what becomes possible when you stop writing code and start directing agents.

    “A proficient engineering leader has been quote unquote vibe coding through people on Slack or one-on-ones, because you’re transmitting your will, your intent, your experience, and you’re letting others run with it. Now we do the same with agents.”

    Guillermo Rauch, reframing leadership itself as the original form of vibe coding.

    Watch the full conversation on the Naval Podcast here.

    Related Reading

    • Full episode: The AI Industrial Revolution, the complete hour-long conversation this clip is drawn from, covering software factories, hardware, regulation, healthcare economics, autonomous companies, and creativity.
    • Part two: Vibe Coding Hardware, the continuation of this conversation, where the same founders move from pure software into AI-designed jet engines, vertical integration, China’s open-source bet, and why humans become verifiers.
    • Naval Ravikant’s official site, the canonical home for Naval’s essays, podcast, and longer-form thinking on technology, judgment, and leverage.
    • Vercel, Guillermo Rauch’s company, building the AI-native cloud and frontend infrastructure that this conversation references as a canonical agent building block.
    • Boom Supersonic, Blake Scholl’s company building supersonic civilian aircraft and their own jet engines, the hardware example of a founder building the whole factory.
    • Science Corporation, Max Hodak’s brain-computer interface company developing the biohybrid neural implant referenced in the intro.
    • Mitchell Hashimoto’s writing, source of the “block economy” framing for why reusable infrastructure building blocks become more valuable, not less, in the agentic era.

  • Composer: Building a Fast Frontier Model with Reinforcement Learning

    Composer represents Cursor’s most ambitious step yet toward a new generation of intelligent, high-speed coding agents. Built through deep reinforcement learning (RL) and large-scale infrastructure, Composer delivers frontier-level results at speeds up to four times faster than comparable models:contentReference[oaicite:0]{index=0}. It isn’t just another large language model; it’s an actively trained software engineering assistant optimized to think, plan, and code with precision — in real time.

    From Cheetah to Composer: The Evolution of Speed

    The origins of Composer go back to an experimental prototype called Cheetah, an agent Cursor developed to study how much faster coding models could get before hitting usability limits. Developers consistently preferred the speed and fluidity of an agent that responded instantly, keeping them “in flow.” Cheetah proved the concept, but it was Composer that matured it — integrating reinforcement learning and mixture-of-experts (MoE) architecture to achieve both speed and intelligence.

    Composer’s training goal was simple but demanding: make the model capable of solving real-world programming challenges in real codebases using actual developer tools. During RL, Composer was given tasks like editing files, running terminal commands, performing semantic searches, or refactoring code. Its objective wasn’t just to get the right answer — it was to work efficiently, using minimal steps, adhering to existing abstractions, and maintaining code quality:contentReference[oaicite:1]{index=1}.

    Training on Real Engineering Environments

    Rather than relying on synthetic datasets or static benchmarks, Cursor trained Composer within a dynamic software environment. Every RL episode simulated an authentic engineering workflow — debugging, writing unit tests, applying linter fixes, and performing large-scale refactors. Over time, Composer developed behaviors that mirror an experienced developer’s workflow. It learned when to open a file, when to search globally, and when to execute a command rather than speculate.

    Cursor’s evaluation framework, Cursor Bench, measures progress by realism rather than abstract metrics. It compiles actual agent requests from engineers and compares Composer’s solutions to human-curated optimal responses. This lets Cursor measure not just correctness, but also how well the model respects a team’s architecture, naming conventions, and software practices — metrics that matter in production environments.

    Reinforcement Learning as a Performance Engine

    Reinforcement learning is at the heart of Composer’s performance. Unlike supervised fine-tuning, which simply mimics examples, RL rewards Composer for producing high-quality, efficient, and contextually relevant work. It actively learns to choose the right tools, minimize unnecessary output, and exploit parallelism across tasks. The model was even rewarded for avoiding unsupported claims — pushing it to generate more verifiable and responsible code suggestions.

    As RL progressed, emergent behaviors appeared. Composer began autonomously running semantic searches to explore codebases, fixing linter errors, and even generating and executing tests to validate its own work. These self-taught habits transformed it from a passive text generator into an active agent capable of iterative reasoning.

    Infrastructure at Scale: Thousands of Sandboxed Agents

    Behind Composer’s intelligence is a massive engineering effort. Training large MoE models efficiently requires significant parallelization and precision management. Cursor’s infrastructure, built with PyTorch and Ray, powers asynchronous RL at scale. Their system supports thousands of simultaneous environments, each a sandboxed virtual workspace where Composer experiments safely with file edits, code execution, and search queries.

    To achieve this scale, the team integrated MXFP8 MoE kernels with expert and hybrid-sharded data parallelism. This setup allows distributed training across thousands of NVIDIA GPUs with minimal communication cost — effectively combining speed, scale, and precision. MXFP8 also enables faster inference without any need for post-training quantization, giving developers real-world performance gains instantly.

    Cursor’s infrastructure can spawn hundreds of thousands of concurrent sandboxed coding environments. This capability, adapted from their Background Agents system, was essential to unify RL experiments with production-grade conditions. It ensures that Composer’s training environment matches the complexity of real-world coding, creating a model genuinely optimized for developer workflows.

    The Cursor Bench and What “Frontier” Means

    Composer’s benchmark performance earned it a place in what Cursor calls the “Fast Frontier” class — models designed for efficient inference while maintaining top-tier quality. This group includes systems like Haiku 4.5 and Gemini Flash 2.5. While GPT-5 and Sonnet 4.5 remain the strongest overall, Composer outperforms nearly every open-weight model, including Qwen Coder and GLM 4.6:contentReference[oaicite:2]{index=2}. In tokens-per-second performance, Composer’s throughput is among the highest ever measured under the standardized Anthropic tokenizer.

    Built by Developers, for Developers

    Composer isn’t just research — it’s in daily use inside Cursor. Engineers rely on it for their own development, using it to edit code, manage large repositories, and explore unfamiliar projects. This internal dogfooding loop means Composer is constantly tested and improved in real production contexts. Its success is measured by one thing: whether it helps developers get more done, faster, and with fewer interruptions.

    Cursor’s goal isn’t to replace developers, but to enhance them — providing an assistant that acts as an extension of their workflow. By combining fast inference, contextual understanding, and reinforcement learning, Composer turns AI from a static completion tool into a real collaborator.

    Wrap Up

    Composer represents a milestone in AI-assisted software engineering. It demonstrates that reinforcement learning, when applied at scale with the right infrastructure and metrics, can produce agents that are not only faster but also more disciplined, efficient, and trustworthy. For developers, it’s a step toward a future where coding feels as seamless and interactive as conversation — powered by an agent that truly understands how to build software.