Bolt.new: Making the Development Environment Part of the Agent

The first attempt did not work

In January and February 2024, StackBlitz tried to build what became Bolt.new, a conversational tool for creating web applications. The models could generate code, but Eric Simons says they were not accurate and fast enough without extensive retrieval augmentation, which introduced problems of its own. The team shelved the idea. Newer model previews later produced code good enough to build a product around.

That improvement also prompted a new interface. StackBlitz had spent seven years building an integrated development environment, or IDE, for programmers. Simons describes starting Bolt’s interface from scratch around what AI could now accomplish. Launched October 1 using Claude Sonnet 3.5, Bolt paired conversational code generation with StackBlitz’s browser execution technology. The central engineering problem in this Latent Space conversation is turning generated code into software users can run, repair, and deploy.

Itamar Friedman introduces the verification side through Qodo. His framework divides software development into specifications, tests, and code, with Qodo approaching the problem through testing. Over roughly a year and a half, it had expanded from an IDE extension for unit tests into broader testing, repository context, and code review. Its offerings included Qodo Merge and the open-source CoverAgent; Qodo Cover, CoverAgent’s commercial counterpart, was still forthcoming.

Friedman argues that permissions and approvals justify specialized agents, even as models become more capable. Enterprise agents may need different data sources, tools, guardrails, and authority. A role prompt asking a general-purpose model to act as a tester or developer does not resolve those operational boundaries.

From an empty project to a live application

Bolt’s initial strength was taking an application from zero to its first version. Two user patterns emerged: - Developers start in Bolt, then export. They send the project to GitHub or download it and continue in tools such as Cursor. Some return to Bolt for a large feature. - Nonprogrammers remain in Bolt. Its conversational interface becomes their development environment throughout the project.

This split explains why comparisons with Cursor initially surprised the Bolt team. A local IDE and a browser chat interface appeared to serve different workflows, but user feedback revealed overlap among people relying heavily on AI to build applications. For these users, removing local setup changes who can build software. StackBlitz’s browser runtime, WebContainer, addressed a barrier that experienced developers already knew how to overcome.

A wedding site illustrates the interface advantage: supply a date, location, and photograph, then ask the system to place them appropriately. A configurable site builder requires learning its controls before expressing that intent. One speaker recounts their mother, around 70, creating her first website about her nursing career by describing herself and her work.

Deployment completes the first useful result. Bolt’s Netlify integration could submit files and produce a live website before the user logged in; the user could then claim it in a Netlify account. A participant who disclosed being a StackBlitz investor draws a broader lesson: interfaces that computers can navigate easily become useful building blocks for agents. Here, a simple deployment operation bridges generated files and a website another person can visit.

A controlled runtime makes failures observable

WebContainer grew out of a realization the team dates to 2017. Service workers gave web applications programmatic control over serving URLs. Originally intended to support offline applications, they supplied a primitive for running web servers inside the browser. Together with newer browser capabilities such as WebAssembly, they made a browser-hosted Node.js development environment possible. The first WebContainer beta went online in 2021.

The team describes WebContainer as an operating system purpose-built for browser tabs. Converting conventional Docker environments to WebAssembly produced artifacts too large and slow for the intended experience. A development runtime could instead omit unnecessary capabilities, such as audio drivers. The speaker tentatively recalls a roughly megabyte-scale system versus tens of megabytes for Docker-to-WebAssembly alternatives—approximate sizes, without a controlled benchmark.

Building it also exposed gaps in the browser platform. The team reports extensive Chromium bug filing and collaboration with Google, including work to make Chrome DevTools useful for debugging the runtime. Games and IDEs are revealing stress tests: games demand intensive computation, while an IDE must support building and executing applications inside another application.

For Bolt’s agent, the consequential property is a consistent environment with instrumentation at the process and runtime levels. On an arbitrary local machine, a failure may depend on operating-system differences or configuration that is difficult to inspect reliably. WebContainer narrows that variability and lets Bolt capture failures from both builds and running applications.

The repair interaction follows a concrete sequence: 1. Capture a failure from the build process or running web application. 2. Offer fix and ignore controls so the user chooses whether to attempt repair. 3. Send application state and error telemetry to the agent, including errors from Node.js or the browser. 4. Attempt a code correction using that context. The team calls the implementation primitive at the time and reports useful results without a repair-success benchmark. Its distinctive mechanism is making execution failures available as inputs to the agent’s next action.

Repairing visible errors is part of a broader verification problem: - Testing checks functionality: does the software behave as expected? - Code review checks maintainability and practices: is the change appropriate to merge and maintain? Both matter for app builders and enterprise agents. Their scope differs: an isolated application may need less integration testing than enterprise software with many interacting systems.

Bolt also breaks work into smaller tasks and executes them in a concrete order, citing Claude Artifacts as an influence. Its open-source core exposed system prompts and could run locally. Community forks added model choices, and a participant built a real-time voice demo on one of those forks; voice was discussed as a possible product addition.

Enterprise context includes deployment and organizational intent

Enterprise agents face substantial work before they can understand any code. Friedman reports 96 deployment combinations, reflecting several independent customer requirements: - Code hosting: GitHub or GitLab, hosted in the cloud or on premises. - Execution environment: different cloud providers, on-premises installations, and Kubernetes availability. - Model access: external model services or internally deployed models, including installations required to remain isolated.

A cloud-provider choice does not settle the architecture. An AWS-only customer may still run GitHub Enterprise on premises, requiring private connectivity. Inference arrangements include customer-owned GPUs, models hosted within AWS, Azure OpenAI, and OpenAI models requested by customers running on GCP. These restrictions affect both deployment engineering and which models the agent can use.

Once installed, an agent may face tens of thousands of repositories, particularly where each microservice has its own repo. Finding relevant code is only part of the problem: existing code may conflict with desired future practice. The proposed indexing approach lets technical leads identify high-quality repositories, repositories to expand, and repositories to deprecate. Those judgments become inputs to retrieval so suggestions reflect the organization’s direction.

The same concern applies to training. Fine-tuning directly on legacy code can encourage repetition of outdated practices and mistakes. Qodo is described as accepting a Markdown document of technical leads’ best practices to constrain suggestions. That provides an explicit source of organizational guidance, though adherence was not quantified.

Flow engineering reduces dependence on model-specific prompts

Model restrictions give task decomposition another purpose. Flow engineering here means breaking a large problem into smaller tasks and selecting suitable models for them. A large, loosely constrained request may need substantially different prompts for different models. Smaller tasks reduce that sensitivity, making it easier to support o1, Sonnet, Gemini 1.5, and internally developed models across customer environments.

The team reports improved competitive-programming results from combining an external coding workflow with o1-preview. It argues that reasoning models still benefit from explicit task structure. The reported comparison does not include a reproducible evaluation setup and distinguishes o1-preview from the model used for the cited International Olympiad in Informatics result, so it cannot establish the size of that benefit.

Participants disagree over whether these models merit the label “System 2,” used here in discussing deliberate reasoning. One rejects the label; another says their capabilities may be incomplete and still need guidance. The stronger skeptic later argues that agents’ awareness of their environment and their own knowledge gaps offers a path toward that capability. This remains a conceptual position rather than a benchmark conclusion.

Open source supplies feedback—and lowers competitors’ barriers

Opening an agent’s implementation creates a commercial tension. The Qodo-side account describes competing with specialized startups and incumbents across individual agents, and alleges that an unnamed competitor reproduced even the open-source product’s interface typos. The Bolt-side response favors releasing as much as is strategically sensible: imitation puts pressure on a team to improve before it becomes comfortable.

Forks made missing features visible immediately. Within the first week, community versions of Bolt reportedly added persistent chat messages and checkpoints. Hosted-product users asked why those features were absent while the team was occupied keeping servers and GPUs online. The forks supplied working interface patterns and code to evaluate, as well as pressure to ship.

An infrastructure business also supported the decision. Browser execution still needs surrounding services: the team says npm installation and database connectivity involve server-side proxying or acceleration. StackBlitz sells WebContainer as a service and expected more browser-based AI builders to become customers. Running code locally therefore does not imply that serving more users has no additional cost.

Bolt’s success complicated that strategy. Before launch, a few hundred thousand dollars of first-month annual recurring revenue would have been exceptional; the team expected substantial business from WebContainer integrations. Revenue instead became heavily concentrated in Bolt. One participant advises choosing between the application and infrastructure businesses, or raising enough capital to pursue both. That was strategic advice, not a fundraising announcement.

The specifications–tests–code framework then returns as a way to distinguish products. Bolt connects descriptions of desired behavior to generated code; Qodo starts with tests and extends toward code and specifications. One prediction is that stronger agents will move more interaction toward tests as executable specifications—desired behavior expressed in a form that can be run—while code and developers remain part of the process.

Rapid growth required a consumer operating model

At roughly six weeks after launch, the team reports continuing acceleration through word of mouth, TikTok, and YouTube. Much traffic arrived directly, making acquisition attribution difficult. Daily additions to annual recurring revenue (ARR) reportedly rose from about $100,000 several weeks earlier to about $500,000 over the latest couple of days. Those were additions to an annualized recurring figure, not daily cash receipts, and the speaker questioned whether the recent pace would hold.

A new agent release and an updated Sonnet reportedly produced a large conversion increase, although changing both together prevents separating their contributions. A participant’s event-app experiment shows the product behavior more concretely: an initial RSVP request produced a wedding page, and subsequent requests added event creation and editing. For administration, Bolt added an admin-view toggle and pencil buttons for inline editing—a simpler design than the separate admin interface the participant had imagined.

The participant speculates that limiting files made that design easier for the model. The team’s explanation of its broader effectiveness emphasizes runtime and model expertise concentrated in the same engineers. Dominic Elm is described as a founding StackBlitz engineer who had previously worked on machine learning and built an online development environment for it. He subsequently led WebContainer engineering and then the team’s AI work. That shared context, the speaker argues, helped a small group connect implementation decisions quickly.

The reported arrival of roughly 20,000–30,000 customers in six weeks created support and engineering needs. Buyers were now primarily people with little development experience, requiring a different operating model: - Enterprise success depended on relationships. Sales engineers helped customers install StackBlitz, and customers shared telemetry during calls because the company could not directly observe their instances. - Consumer success required understanding usage and retention. The team was shifting toward analytics, email marketing, and livestreams, while participants recommended studying customer segments and emerging churn.

The founders could draw on their earlier experience selling web-development courses to consumers. Hiring would also increase, but deliberately: the team wanted to meet demand without letting management complexity undermine the advantages of a small group.

Inference pricing shapes capability

Bolt initially carried a $9 offering from a business where that inexpensive plan had never been the main revenue source. By week two, support demand was overwhelming and users were exhausting their model-usage allowances without a way to buy more. The team revised pricing over a weekend, roughly doubling the base price and adding $50, $100, and $200 plans, with additional token purchases available beyond subscriptions.

The underlying argument is that pricing can constrain how much context an agent receives. The Bolt-side speaker argues that cheap, unlimited subscriptions encourage providers to minimize the code context they send to models. Bolt aims to supply as much application state as possible, on the premise that newer models can use it effectively. The speaker’s comparison with Copilot is qualitative; the consequential connection is between inference budget, available context, and the scope of work a capable model can attempt.

The team says it was taking little margin at the time, prioritizing users’ inference allowances, without giving a detailed cost breakdown. Additional purchases brought revenue beyond recurring subscriptions. The $50 tier also had an audience among developers generating components or designs who did not need the highest usage levels.

ViralHooks.ai illustrates why a user might compare the subscription with the cost of building software. A product manager in Thailand reportedly built the application, which extracts video hooks and helps users write their own, on Bolt’s $50 plan in one or two weeks. She had previously received an Upwork quote of $5,000 and roughly three months. The comparison is between a contractor’s quote and a reported self-built application; it does not account for equivalent scope, quality, or total labor.

Professional website builders were also described as major power users. Participants see room to price AI by delivered value, while acknowledging how difficult that value is to predict for an individual customer. Higher proposed price ladders express this idea; they do not establish demand at every tier.

The remaining distance to production

Bolt was conceived as a prototyping tool whose developer users would download the code. Early testing changed that assumption: users wanted real applications. A power user identified as Mauricio summarized recurring requirements as a database, authentication, and payments. Backend setup and deployment became central product responsibilities.

Firebase and Supabase were described as working well with Bolt, but users still had to create resources externally, return to Bolt, and configure connections. The proposed next step was agent-driven provisioning, including migrations and table creation. Another participant suggested keeping prewarmed instances ready to assign when an application was created. These were plans for removing setup steps, not shipped capabilities.

Hosting had a similar gap. An initial Netlify deployment could precede login, but users still needed an account to retain the site. The team was discussing built-in hosting through Netlify’s white-label capabilities. Its proposed end-to-end experience would let a user request a site, choose an available domain, approve its purchase, have the domain configured, review the result, and approve production deployment without leaving Bolt.

Language support exposes a related tradeoff. WebContainer is described late in the conversation as having minimal Python support and some C++ capability, while Bolt remained focused on JavaScript and Node.js web applications. The discussion identifies three considerations: - Handoff to engineers: the JavaScript and Node.js ecosystem offers an established pool of developers to extend generated applications. - Workload coverage: Python-only libraries could matter for data science and machine learning, though the team reported little such demand among its users. - Failure recovery: concentrating on one ecosystem makes it easier to collect common errors and improve repairs, with possible future fine-tuning.

A narrower ecosystem can make the entire path more reliable. Replit’s use of virtual machines is presented as a more general way to run varied languages and workloads, although the speaker had not tried its new agent. Bolt’s stated priority was streamlining web-app creation for users who might need more help getting from an idea to production than experienced developers do.

Test the opportunity, then act on specific objections

The closing discussion returns to the failed first attempt. After a two-week sprint, the team found Bolt unconvincing and rolled it back. Tangible improvements in newer models justified reopening the experiment. The founder’s advice follows that sequence: test an opportunity firsthand, then bring concrete results to people with deeper domain knowledge. Outside encouragement strengthened the team’s conviction once there was something to inspect.

The final anecdote puts this attitude in personal terms. After his daughter’s birth in April, amid uncertainty about the company, the founder committed to an Ironman despite never having run a marathon. He reports finishing in 12 hours and 15 minutes. His coach advised against attempting the race with only three months remaining, but also identified a specific weakness: insufficient bike training. He acted on that criticism, riding six hours a day on weekends for a couple of months.

His lesson is to extract actionable objections from expert advice and independently assess what remains achievable. He connects the coach’s doubts with browser-engine experts questioning WebContainer’s feasibility. Race day and launch day, in his account, expose whether the preparation and assumptions were grounded in reality.