Amjad Masad and Paul Graham on Replit’s Path to AI Coding

Paul Graham asks Replit co-founder and CEO Amjad Masad how the company knew an AI coding agent would work before the idea became widely accepted. Masad says the shift looked dramatic from outside but grew incrementally from what the team observed users doing.

Replit had already offered code completion. Masad recalls watching people who had never programmed copy generated code from a chat window into Replit, then paste errors back into the chat and repeat. Their improvised workflow suggested a product opportunity: automate the loop rather than requiring constant copying.

Automating the loop required understanding errors and continuing until the program worked, not simply producing one answer. Masad says early models were unreliable at tool use and required a much more complicated harness than later models. As model capabilities improve, he expects some of that supporting engineering to become commoditized.

A second ingredient was Replit's existing infrastructure. Masad says the agent could call tools to provision a database, host a service and deploy an application. The company had spent years building these systems before releasing its agent in September 2024, after showing Graham an earlier version that summer.

Graham recalls feeling unsettled by the demonstration because his own programming style values carefully reducing code. Masad points to Graham's earlier argument that making programming easier can bring in disproportionately more programmers. They joke about how far plain-language programming takes that principle.

Masad says Replit's original 2015–16 pitch anticipated using data from a large programming platform to train models that predict code, before the Transformer paper. He connects the idea to a longer interest in making programming accessible, including an early desire to program from a phone while in class around 2008.

Graham challenges the idea that prediction comes only from sitting down and thinking: Masad had spent years working on the same problem. Their exchange distinguishes long familiarity with a domain from the sudden moment when an enabling technology makes an old idea practical.

They revisit the 2024 demonstration, when Masad described code as analogous to object code. Graham says the framing was unsettling. Masad says he too had grieved the possible loss of a craft he loved and believes many engineers will need time to adapt; this is his interpretation of a personal and industry experience.

They discuss what made agentic coding visible to a wider audience. Masad points to tools that run tasks through to completion and suggests that a familiar interface, such as messaging an agent, can matter as much as the underlying capability. He says he underestimated how much product form affects adoption.

Masad admits that watching users struggle with Replit was painful, but credits co-founder Haya Odeh with insisting that the company stay close to users. Graham says observing real confusion can expose problems a builder has avoided acknowledging.

The pair also discuss Replit's distinctive visual design and early community of young programmers. Masad describes a simple user experience built on complicated systems work: the interface can look effortless because the company handles difficult execution and administration underneath.

Masad argues that this infrastructure helps with enterprise customers, which he says pay close attention to reliability and security. He claims that guardrails can make a product slower or more expensive but more acceptable to those buyers. His competitive claims are his own assessment.

Graham compares Replit to an iceberg: natural-language generation is visible above the surface, while deployment and sandboxing sit below. Masad describes operating-system work and a transactional, reversible file system designed to support collaborative programming.

That collaboration architecture helped when agents arrived, Masad says. An early agent could be treated as another user working in the same project as a person. Existing teams for execution, cloud services and the editor then exposed tools to a new agent team placed between them.

The early agent needed robust editing tools because models could misidentify lines, omit implementation or stop before a task was complete. Masad says the team had to detect such failures and continue the loop; in his view, more capable models can now work with simpler shell tools.

The first release barely worked consistently. Masad estimates that perhaps 30% of attempts failed, but users still found value because the alternative for some was not programming at all or manually copying code between tools. The figure is his recollection, not a measured reliability benchmark.

Masad says some early paying customers had previously sought outsourced developers. He contrasts a costly outsourced application with much lower spending on Replit as an illustration of the demand, while Graham observes that the existence of outsourcing itself showed how many people wanted software built.

Before agents could do as much, Replit tried to serve that demand through Replit Bounties, connecting requesters with developers on the platform. Masad says those developers were already using early AI assistance; he later concluded that customers would increasingly ask agents directly and the company shut the program down.

Masad describes employees inside banks, manufacturers and other large companies using Replit for internal tools and software replacement. He cites an example in which a project scoped at $10 million was implemented with $250,000 of Replit spending. This is a customer example he reports, not a controlled comparison of total project costs.

He sees these internal champions as entrepreneurial even when they work inside large organizations. Graham suggests that visible use of AI can also make them useful to colleagues trying to understand the technology. Both are describing a pattern they believe they see, rather than a guarantee of promotion or success.

Enterprise adoption also requires administrative work: controls for IT and security, budgets and rules about what users can do. Masad describes the tension between a product's individual users and the people responsible for purchasing and governing it.

Masad questions giving every employee the same token allowance. He argues that organizations should consider the value produced relative to spending, because users and projects can differ substantially in impact. Graham suggests that measuring useful work is itself a difficult enterprise problem.

For now, Masad says vendors may need to provide the controls buyers request in order to enter an organization, then develop better ways to show where value is being created. The pair regard that as a product problem extending beyond code generation.

Masad says Replit increasingly describes its ambition as a platform for a self-driving company rather than only vibe coding. Replit uses itself as a first customer to explore how agents might build and operate software across a firm. This is a company vision, not evidence that organizations can already run autonomously.

He says he had long expected easier software creation to have broad effects, but had not fully appreciated how it might change everyday work. Graham argues that successful companies often develop a new direction while still growing their existing business.

Masad sees AI as a force that continually makes existing features easier to copy, making reinvention important. Graham cautions that a broad claim about transforming companies needs concrete examples, because any vendor can adopt the same language.

They suggest pursuing the larger vision incrementally: identify customers already doing a promising kind of work, help them succeed and turn the lessons into a repeatable product. Masad compares this with the agent launch, which appeared discontinuous externally but followed many internal steps.

The pair discuss invention as a process in which an idea can precede the technology needed to execute it. An apparent leap to outsiders may look smoother to people who have been developing its components for years. They use Apple devices as an analogy for that long preparation.

Masad predicts that people may eventually use far more agents than can run on a personal laptop, increasing the role of cloud environments. Graham asks whether agent use will persuade more developers to move away from local-only workflows. Both are speculating about future adoption.

Masad describes himself as willing to abandon familiar methods when computers become capable of doing them. He says a rapidly changing environment rewards flexibility and lifelong learning, and refers to Graham's essay about keeping one's identity from becoming too rigid.

Masad recounts a company hackathon survey in which participants reportedly shifted from anxiety to optimism after an hour with Replit. He presents it as an anecdote about exposure to tools; the interview does not establish the survey method or whether the effect persisted.

He says many large organizations are behind the practices common among advanced AI users and still face legacy software. The pair discuss companies offering to rewrite old COBOL systems, contrasting that service with Replit's aim of giving customers tools to build for themselves.

Asked how he anticipates change, Masad says he actively makes and revises predictions. He cites Ray Kurzweil and a long-run view of increasing compute as influences, while Graham notes that experience with a particular domain also shapes what a founder can notice.

Masad says that after seeing GPT-2 he extrapolated toward chat, agents and personal assistants. He argues that taking exponential change seriously helped him accept that computers might increasingly perform parts of his own work and build toward that possibility. These are retrospective reflections and forecasts, not proof that every trend will continue indefinitely.

Graham concludes that someone who expects rapid change may be particularly comfortable in a period when tools and practices change quickly. Masad agrees that the moment suits his preference for adaptation. The discussion closes on how long-term preparation and willingness to revise assumptions can shape a founder's response.