Last updated: November 12, 2026

In his conversation with Paul Graham, Amjad Masad describes how Replit’s earlier work helped its AI agent. They had built a way for people to code together, and the agent could participate as another user. I think that’s worth remembering when we judge decisions that only make sense years later.

Paul Graham and Amjad Masad in Y Combinator's How to Build the Future conversation

Watch the full conversation on YouTube (Y Combinator, 44 min).

What interested me is how ordinary the connection sounds once someone explains it. People could already work together in the same coding environment. According to Masad, that earlier work gave the agent a way to join them.

The company still needed to build something new. But it had something useful to build on. Masad says the infrastructure, cloud and IDE teams kept a role, and a new agent team was added.

It’s tempting to turn that into a story about seeing the future. I find the simpler version more useful. Work built for one purpose became useful for another. Recognizing that new use matters, even if the original decision had a different reason behind it.

I’ve worked on HR systems for more than 20 years. That’s long enough to know how easy it is to judge an old decision once you already know how it ended. And right now, almost every company is about to put AI next to systems that were built for a different reason. So the question of how to judge old work fairly isn’t academic anymore. It decides what you keep, what you retire, and how much the AI project really costs.

What exactly did Masad say about Replit’s earlier work?

The part I mean sits around minutes 17 to 18 of the Y Combinator video. Replit had built a way for several people to edit and run code in the same environment at the same time. When the company built its agent, Masad says, that same design let the agent take part as one more user in the session.

He also says the older teams didn’t become useless. Infrastructure, cloud and the IDE kept their role. A new agent team was added next to them.

Two things are worth holding on to. First, this is Masad’s account of his own company. I haven’t checked Replit’s internal history, and I won’t add technical detail he didn’t give. Second, the account describes a connection, not a forecast. Whether anyone at Replit expected the agent when the collaboration work was built, I can’t tell from the conversation. So I won’t guess.

That second point is the whole post, really. A connection you can explain afterwards is real and useful. A prediction is a different claim, and it needs different evidence.

What can stay useful when a product changes?

A product has parts, and it has a way those parts work together. We often discuss them as if they must change at the same time. Research on innovation gives us a reason to separate them.

In their 1990 paper on architectural innovation, Rebecca Henderson and Kim Clark split product knowledge in two. Component knowledge is knowing each part well. Architectural knowledge is knowing how the parts are linked into a whole (p. 11). Their point was that familiar components can be connected differently, creating a product that demands a different understanding of the whole system.

They used a simple fan example to explain it (pp. 12 to 13). For a maker of large ceiling fans, a better blade or a stronger motor is an ordinary improvement. A portable fan uses largely the same parts: blade, motor, controls. But putting the motor and blade close together in a small housing creates new interactions the old design never had to deal with. Knowing the parts doesn’t mean you automatically understand the new arrangement.

Then they said something I think every CEO should read twice. Organizations build their structure around the product’s architecture. A fan company creates a blade group and a motor group, and the people working on the motor and the blade report to the same supervisor and meet every week (p. 15). Over time, the org chart and the communication channels become a copy of the old design. That’s why a new architecture can be hard to see from inside a company that knows every component perfectly.

Their research went beyond that illustration. Over fourteen months, from March 1987 to May 1988, they interviewed more than a hundred people in the semiconductor photolithographic alignment equipment industry and backed the interviews with internal company records where they could (p. 19). The paper studied manufactured equipment, not AI coding agents. It doesn’t prove what happened inside Replit. It does give us a clear distinction for understanding Masad’s account: the value of an existing capability and the shape of the next product are separate questions.

Replit collaboration work built for people coding together later let the AI agent join as another user, per Amjad Masad.

Illustration based on Masad’s account in the YC conversation, around minutes 17 to 18. This is a conceptual connection, not Replit’s technical architecture.

In Replit’s case, the connection Masad names is specific. Tools for people coding together helped the agent participate as another user. We don’t need to assume every older component survived, or that the new product was easy to build, to understand why that mattered.

Now take an HR system. Employee records, payroll rules, the leave approval workflow and the self-service portal are components. The architecture is how they connect: who enters what, who approves, and which report feeds which decision. An AI agent might use the same employee data and the same tested payroll rules while changing the architecture completely. That’s why “keep the HR system or replace it?” is usually the wrong question. The better one is: which parts still earn their place, and which links between them were built for a way of working we’re about to drop?

Why does this question matter more now that AI is arriving?

Because almost every old system is about to meet a new use, or a new rival. In the World Economic Forum’s Future of Jobs Survey, 86% of employers said AI and information processing technologies will transform their business by 2030 (WEF, Future of Jobs Report 2025, p. 11, Figure 1.2).

And the old decisions come with a bill. IBM’s Institute for Business Value surveyed 1,300 senior AI decision makers in large enterprises across 17 countries (pp. 2 and 18). It defines technical debt as the cumulative consequence of past technology decisions, and says AI projects inherit the conditions of the technology estate they land in (IBM IBV, The tech debt reckoning, p. 4).

The report even uses an HR example. For an AI assistant that answers employee questions on pay, benefits and leave, the model itself may be cheap to train, but only if the HR data it needs is accessible, consistent and secure. In most enterprises, IBM says, that data is scattered across several applications (p. 8). Anyone who has tried to reconcile a payroll file with the employee master knows exactly what that means.

Here’s what the research says, in one place:

SourceWhat it foundPageWhat I take from it
WEF, Future of Jobs Report 202586% of employers expect AI and information processing to transform their business by 2030p. 11, Figure 1.2Nearly every old system will be judged again, soon
IBM IBV, The tech debt reckoning (2025)Executives expect 18% to 29% of total AI implementation costs through 2027 to come from technical debt; 69% say it will make some initiatives financially untenablep. 7Past decisions show up as a line in the AI budget
IBM IBV, The tech debt reckoning (2025)Only 29% have put the full cost of technical debt into their AI business casesp. 9Most companies judge old systems without numbers
IBM IBV, The tech debt reckoning (2025)80% agree that fixing technical debt in one AI initiative improves the ROI of related future initiativesp. 13Earlier work can pay off later, which is Masad’s story in survey form
PwC, 29th Global CEO Survey (2026)56% of CEOs saw neither higher revenue nor lower costs from AI in the last 12 monthsp. 5Buying the tool isn’t the return
McKinsey, The state of AI in 202555% of AI high performers fundamentally redesigned workflows when deploying AI, against 20% of other respondentsp. 16, Exhibit 11Keep what works underneath, but change how the work flows

Read the IBM numbers as what executives told IBM, not as measured results. IBM also sells modernization work, so I’d hold its framing a little loosely. But the direction matches what PwC found from 4,454 CEOs. PwC’s advice is to build AI foundations, and the first one it names is a technology environment that enables AI integration (PwC, 29th Global CEO Survey, p. 7).

There’s a fair reading of all this that cuts both ways. Old systems can slow AI down, and they can also be the reason it works. IBM gives its own HR as an example: it says the reusable cloud frameworks its CIO team built while scaling its AskHR assistant became the template for AI in functions like finance and procurement, and laid the groundwork for an IT assistant called AskIT (p. 16). That’s IBM telling its own story, so treat it the way I treat Masad’s: a useful account, not proof.

Why can the past look more obvious than it was?

Once a product exists, the earlier work can seem like a series of deliberate steps toward it. The ending helps us decide which details to pay attention to. Other possibilities fade into the background.

Psychologist Baruch Fischhoff examined this problem in his 1975 research on hindsight. Participants, mostly university students, read short accounts of historical or clinical events (p. 290). Some received an account without an outcome. Others received the same background with a stated outcome added.

Knowing the reported outcome changed two things. The outcome people had been told about seemed more likely, and the same background facts took on different importance (p. 288). Some of the reported outcomes were deliberately false, and the effect still appeared. So it was about what people believed had happened, not about learning the true ending.

In a further experiment, participants were asked to answer as if they hadn’t known the outcome (p. 293). Their judgments still reflected that knowledge. People overestimated what they would have known without it (p. 288). Simply telling ourselves to be fair may not be enough to recover what uncertainty felt like earlier.

Hindsight bias in Fischhoff 1975: knowing an outcome makes it seem more likely and changes which facts look important.

Conceptual summary of Fischhoff’s experimental design and findings. No effect size is represented.

These were controlled judgments about short descriptions. They were not observations of executives making investment decisions over years. I wouldn’t use them to diagnose a person in a company interview. I would use them as a reason to be careful with my own reaction to a convincing business story.

Picture a hypothetical board looking at an HR system bought eight years ago. If an AI assistant now runs nicely on its clean employee data, the purchase will look wise. If the data turned out to be a mess, the same purchase will look careless. The decision, the people and what they knew on the day are identical. Only the ending changed.

How would we judge the same decision before knowing the result?

Imagine a hypothetical software team deciding whether to support shared editing. Its customers currently need to work together on the same documents. The team has a sensible reason to build it, even if no later AI use ever appears.

Years later, an assistant can use part of that system. The investment now serves another purpose. That is new information about its value. It doesn’t change what the team knew on the day it chose to build.

Now imagine a different team making a similar investment without a clear customer need. If a useful second purpose appears later, the ending still doesn’t tell us whether the original reasoning was sound. A good result can make us too generous about a weak decision, just as a poor result can make us too harsh about a reasonable one.

I would separate these questions when discussing an older project:

QuestionEvidence that helpsWhat the evidence cannot settle
Why did we build it?Customer needs and records from that timeWhether later uses were predicted
What is useful now?A specific capability serving a current taskWhether every old component should stay
What changed?A new technical possibility or user needWhether the change was inevitable
Should we keep it?Present benefit and continuing costWhether past spending was justified

This is a way to keep a conversation honest, rather than a scoring system. The answers may be different for different parts of the same product.

A short record written at the time helps a lot here. A customer request or a note explaining the choice gives us something firmer than memory. It may show that the team considered alternatives we have since forgotten. Reading it before judging the decision won’t remove hindsight, but it can remind us what was still unknown.

What should you check before you keep or retire an old system?

Here’s the check I’d run, in this order, before an AI project decides the fate of something older.

  1. Write down why it was built, from records of the time. Do it before anyone discusses today’s AI plans. Otherwise the ending writes the history.
  2. Name the capability, not the system. “The HR system” is too big to judge. “Employee records that match GOSI and payroll every month” is something you can test.
  3. Ask what actually changed. Is there a new technical possibility, like an agent that can act as a user? Or a new need from the business? Be specific enough that the team can show the connection.
  4. Price the debt for one use. IBM’s advice is that every AI initiative should carry a line item for the debt it must resolve to succeed (p. 10). Not a cleanup of everything. Just what this one use needs.
  5. Keep the capability apart from the workflow around it. The data and rules underneath may deserve to stay. The approvals and handoffs on top may still need redesigning, which is what McKinsey’s high performers did.

A quick example of how the answers can split. Say your payroll rules are well tested and match the regulations, but every change request still needs three sign-offs on paper. The rules are a capability worth keeping. The sign-offs are part of the old architecture. You can keep one and redesign the other.

Does this give us a reason to keep every old project?

No. A possible future use isn’t enough by itself. Software still needs maintenance, and people working on an old project cannot spend that same time elsewhere.

There’s also a problem with learning only from examples like this one. We hear an account where an earlier capability became useful. We hear less about comparable work that never found another purpose. Looking only at the helpful examples can make patience seem cheaper than it really is.

That is my caution about the example, rather than a finding about Replit. The conversation doesn’t provide a comparison with companies that made different choices. It can’t establish that keeping the same sort of infrastructure would be sensible everywhere.

There is a related concern in my earlier piece about over-customizing SaaS. Preserving an old workflow exactly can make change harder. That is different from retaining a useful capability while allowing the work around it to change.

The distinction also belongs in the discussion of an AI-native organization. Rethinking who does the work doesn’t require pretending every system underneath it has become worthless. In The Redesign Imperative I argued that AI put onto the old structure isn’t progress. This is the other half of that: some of what sits under the structure is still worth a lot. The difficult part is deciding which old assumptions still hold, and that decision belongs to the leadership team, as I wrote in AI Transformation Leadership.

I’d rather have that discussion than an argument about whether the company should keep the past or replace it. A real product rarely offers such a clean choice.

Masad’s account is worth remembering for that reason. The earlier collaboration work had a later use he could explain plainly. It makes me more willing to look again at a decision whose full value wasn’t clear when it was made, without assuming every unfinished project deserves the same patience.

If you’re deciding right now whether to keep or retire an older system, drop me a message. I’d like to hear which part of it you’d actually miss.

Frequently asked questions

What did Amjad Masad tell Paul Graham about Replit’s older infrastructure?

In the Y Combinator conversation, around minutes 17 to 18, Masad says Replit had built a way for several people to code together in the same environment. When Replit built its AI agent, that design let the agent join as another user. He adds that the infrastructure, cloud and IDE teams kept their role, with a new agent team added. This is his own account.

What is hindsight bias?

Hindsight bias is the tendency to see an outcome as more predictable once you know it happened. In Baruch Fischhoff’s 1975 experiments, people told an outcome rated it as more likely and changed which facts they thought mattered. Even when asked to ignore the outcome, they couldn’t fully do it. For leaders, it means old decisions often look wiser or sillier than they were.

What is architectural innovation?

Architectural innovation, a term from Rebecca Henderson and Kim Clark’s 1990 paper, means linking familiar components together in a new way. The parts stay largely the same, but how they work together changes. Their research showed that established firms can struggle with this, because their structure and communication channels are built around the old way the parts fit.

Should we replace our old HR system before adding AI?

Not by default. Judge the parts separately. Clean employee data and well-tested payroll rules may be exactly what an AI agent needs. The workflows and approvals around them may need redesigning. IBM’s 2025 research suggests pricing the technical debt for each AI use, rather than funding one big cleanup or ignoring it.

How do I know if an old system is worth keeping?

Name the specific capability, not the whole system. Ask what it does today, what changed that makes it useful in a new way, and what it costs to keep running. Then check the records from when it was built, so the ending doesn’t write the history. If the team can’t show a concrete connection to a current need, a possible future use isn’t enough.

References