A Singapore engineering manager asked me a good question last week, before any of this happened. He wanted to know which AI coding assistant to standardise his team on. I gave him a decent answer about evaluation and cost. I should have given him a better one, which is that the question has a hidden assumption: that whatever he standardises on will still be the same thing in six months.
On 17 October 2026, TechCrunch published "Replit is no longer working with Anthropic, CEO says", and it is a cleaner illustration of that assumption breaking than anything I could have invented.
What was said, and what is disputed
Replit co-founder and CEO Amjad Masad said onstage at TechCrunch Disrupt that his company is no longer working with Anthropic. Replit sells a browser-based development platform that has become a fixture among founders and developers, and before striking a deal with OpenAI in August it relied on Anthropic’s Claude models to run that platform. Masad noted on stage that Replit had been, until recently, a top-five customer of Anthropic.
His stated reasoning was threefold. "I think ChatGPT is better now," he said, adding that the company uses an internal benchmark to assess performance. "We publish a public benchmark as well, and consistently, Sol and Astra perform better on building vibe-coded applications from scratch. It was a decision based on both cost, partnership, and performance. And for all these reasons, we just felt like they were a better partner for now."
Then the story gets more careful. After Disrupt, Masad clarified that customers can still reach Anthropic models on the platform, but that OpenAI is now the default. "Replit remains model agnostic," he told TechCrunch. "Our users can choose Anthropic’s Claude or other supported models. OpenAI is now our preferred partner for powering Replit Agent, based on performance, economics, and the strength of our partnership."
And people familiar with the arrangement rejected the framing entirely. One person, who asked not to be named, said the partnership was still in place. TechCrunch also noted that Replit had been promoting Anthropic products on its website, blog and social accounts as recently as a few weeks earlier, including a late September post citing Claude Fable 5 and Claude Fable 5.1 as models running in the agent environment.
Our Expert Take
Resist the urge to pick a side on whether the contract ended, because that question is not yours to answer and it is not the part that affects your team. Two companies disagreeing in public about the status of their commercial relationship is a story about those two companies. Strip it back to the claim that nobody contests and you get something much more useful: the model behind a widely used development platform was changed, users retain a manual override, and the change was announced rather than negotiated. That is the fact pattern to plan around. I would treat every vendor benchmark cited in this episode, from either direction, as marketing, and the default switch as the only operationally load-bearing detail.
The default is the dependency
The single sharpest line in the TechCrunch piece is an observation about human behaviour, not technology: the shift could significantly reduce Replit’s spend with Anthropic because most customers stick with the default rather than selecting a model themselves.
That is the mechanism, and it generalises well past this one vendor. A choice that exists in a settings menu and is never exercised is not a control that your team holds. It is a parameter that your supplier holds, and suppliers adjust parameters according to their own cost structures and partnership terms, on their own schedule, without a change request arriving in your inbox.
So the honest description of most Singapore engineering setups I have seen this year is this: the model generating code in your repositories can change without a procurement decision, without a security review, and without anyone on the team being asked. Not through any failure on your side. Through a default.
Masad’s own phrase for Replit’s posture, "model agnostic", is worth examining, because it is doing two different jobs. As an architectural statement it is a real engineering achievement: being able to swap the model underneath an agent without rebuilding the product is hard and valuable. As a customer-facing statement it quietly transfers something. Agnostic at the platform layer means the platform can change its mind. It does not mean you are insulated from the change.
Why this bites harder in Singapore than elsewhere
Two local characteristics make a silent default change more consequential here than it would be for a consumer startup in California.
The first is the share of engineering work that is done under somebody else’s assurance expectations. A large part of Singapore’s technical employment sits in financial services, government-adjacent delivery, healthcare and enterprise integration, where a client or an internal risk function can reasonably ask what produced a change and how it was checked. "An AI assistant wrote it, and I am not certain which model was behind the assistant that week" is a genuinely awkward answer, and it is the honest answer for a lot of teams right now.
The second is the depth of the vendor and outsourced layer. Plenty of Singapore engineering work is delivered through agencies, offshore teams and contractors, each with their own tooling choices that you do not administer. If your own default is uncertain, a vendor’s default is a second-order unknown. This is why the question belongs in a statement of work and not only in an internal policy document, and why our note on statement of work clauses for outsourced AI development now gets more use than anything else we publish on vendor management.
Our Expert Take
The reaction I would most like Singapore employers to avoid is the policy reflex: a memo naming one approved assistant and one approved model, circulated with the expectation that it settles the matter for a year. I understand the appeal, and it fails for the exact reason this story exists. The approved product can change what is underneath it between your memo and your next audit, and your policy will then be describing something that is no longer true while giving everyone the comfortable feeling that it is. The durable version is not a named vendor, it is a named capability: somebody owns an evaluation set, reruns it when anything upstream moves, and is accountable for reporting the result. That holds up through a vendor switch. A memo does not.
The four questions I now ask every engineering candidate
I have been adjusting these over the year and this episode pushed them into their current form. None of them mentions a product name, which is deliberate: a candidate’s fluency with a specific assistant tells you about a product that may be running a different model by their start date.
1. Walk me through what you do between generating code and opening a pull request
The answer I am listening for is a sequence, not an attitude. Candidates who have genuinely integrated these tools describe something concrete: they read the diff before running anything, they check the imports and dependencies that got added, they run the tests the tool did not write, they look specifically at error handling and edge cases because that is where generated code is weakest. Candidates who have not will say they review it carefully, which is a value rather than a practice.
2. Tell me about a time a tool gave you something plausible and wrong
Everyone who uses these tools seriously has this story. The absence of one tells you the person either has not used them on anything load-bearing or has not been checking. The good answers include how long it took to notice, which is the part that actually matters, and what they changed afterwards.
3. How would you notice if the quality of generated output got worse next month?
This is the question that this week’s news created, and almost nobody has a prepared answer. I am not expecting a measurement framework. I am looking for someone who understands that a silent upstream change is possible and has some instinct for a canary: a set of tasks they would rerun, a code review signal they watch, a sense of what their own baseline is. A candidate who has never considered that the tool could get worse without announcing it is going to be a poor early warning system.
4. What do you refuse to delegate to an agent?
The answer reveals calibration faster than anything else I ask. "Nothing, I check everything it does" is overconfident. "I use it for boilerplate only" is underusing a tool the market has moved past. The answers I trust describe a boundary and a reason: schema migrations that are hard to reverse, authentication and permission logic, anything where failure is silent, anything they would struggle to review carefully enough to defend in an incident review.
For the broader adoption picture these questions sit against, our coverage of developer AI agent adoption and what it means for Singapore hiring has the numbers. On the modelling side, machine learning in Singapore covers the build options.
Not sure which model is behind your team’s tooling right now?
Most Singapore teams we talk to cannot answer that question for every tool in use, and a few discover a vendor changed it already. We will go through your stack and your hiring specification with you.
Discuss your tooling and hiringThe default audit, in one afternoon
This is deliberately small. It is the version that actually gets done.
- List every AI coding tool in active use, including ones adopted by individual engineers without a procurement process. Expect the list to be longer than the approved one.
- Write down the model currently behind each. Where nobody knows, write "unknown" rather than guessing. The unknowns are the finding.
- Add a column for who would find out if it changed, and be honest when the answer is nobody.
- Pin the model explicitly wherever the work is regulated or client-facing, and record the model identifier with the change rather than relying on the platform default.
- Build 20 to 50 evaluation tasks from your own codebase, with known-good outcomes, that you can rerun whenever something upstream moves. This is the only item here that takes real effort, and it is the one that converts future vendor news into a measurement instead of a debate.
- Put the question in your vendor paperwork: which models, notification on material change, and a right to pin. If a vendor cannot answer, that is information.
What this episode does not mean
It does not mean the tools are unreliable or that adoption should slow down. The productivity case for AI-assisted development is not in question here and nothing in the reporting touches it. It also does not mean one model is better than another: the only benchmarks in circulation belong to parties with a commercial interest, including the public benchmark Masad cited, and none of them were run on your codebase.
What it means is narrower and more durable. Supplier relationships in this layer of the stack are young, the economics are unsettled, and defaults are going to keep moving. Teams that hold their own evaluation baseline will experience the next switch as a Tuesday morning measurement. Teams that do not will experience it as an unexplained drop in quality, three sprints late, with no way to tell whether the cause was the tool, the codebase or the new joiner. If a switch is what prompts you to bring capability in house, our guide on transitioning engineering work from a vendor to an in-house team covers that path.
Our Expert Take
My prediction for the next twelve months is that this stops being news, and that is exactly why it is worth acting on now. There will be more switches, in both directions, and some of them will not be announced on a conference stage at all: they will appear in a changelog, or not appear anywhere. The engineering organisations that come through that comfortably will be the ones who did a boring thing early, which is writing down twenty tasks from their own codebase with known-good answers and keeping them runnable. It is a day of work, it is nobody’s favourite project, and it is the difference between reading vendor news as information and reading it as weather.
Hire for the verification habit, not the tool on the CV.
If you have an engineering requisition open in Singapore, the AI tooling section was probably written for last year’s vendor landscape. We will rework it with you around the behaviours that survive a default change.
Let’s review your specFrequently asked questions
Has Replit definitively ended its Anthropic partnership?
The accounts conflict and it is worth being precise. Masad said onstage at Disrupt that the company is no longer working with Anthropic, citing cost, partnership and performance. People familiar with the arrangement told TechCrunch the partnership remains in place, and reporters noted Replit was promoting Anthropic products on its own website and blog as recently as a few weeks earlier, including a late September post citing Claude Fable 5 and Claude Fable 5.1 running in its agent environment. Masad later clarified that customers can still select Anthropic models and that Replit remains model agnostic, with OpenAI now the preferred partner powering Replit Agent. The one fact nobody disputes is the part that matters operationally: the default changed. Whether a contract was terminated is a question for the two companies.
Why does a default model change matter if users can still pick a different model?
Because almost nobody picks. TechCrunch made the point explicitly: the shift could significantly reduce Replit’s spend with Anthropic because most customers stay on the default rather than selecting a model themselves. A dropdown that technically offers choice but is never touched is not a control, it is a setting, and settings get changed by vendors on their own commercial timetable. The practical consequence for an engineering manager is that the model generating code in your repositories can change without a procurement decision, a change request, or anyone on your team being asked. If your assurance story depends on knowing which model produced a given change, a silent default is a gap in that story.
What should Singapore engineering teams actually change after this?
Three things, none requiring a new tool. First, run a default audit: list every AI coding tool in use, write down which model is behind each, and note who would find out if it changed. For most teams the honest answer to the last column is nobody. Second, pin and log where it matters: use explicit model selection in regulated or client-facing work rather than relying on the default, and record the model identifier alongside the change. Third, own an evaluation set: twenty to fifty tasks from your actual codebase that you can rerun when something moves upstream, so a quality shift becomes a measurement rather than an argument in a retrospective.
Should we screen Singapore candidates on specific AI coding tools?
Screen for the behaviour, not the brand. A requirement naming a particular assistant selects for familiarity with a product that may be running a different model by the time the person joins, which is the lesson of this episode. The questions that survive a vendor switch are about judgement: how the candidate verifies generated code before review, what they do when a tool produces something plausible and wrong, how they would notice a quality regression in output they did not write, and where they draw the line on what they will not delegate. Tool fluency is worth one line in a job advert and is learned in a week. The verification habit takes considerably longer and is the thing you are actually hiring.
Sebastian
Mobile App & Hiring Expert at HireDeveloper.sg. Works with Singapore employers on engineering requisitions and developer tooling decisions, with a particular interest in the questions that keep working after the vendor landscape moves.