"Fix It Later" Has an Expiry Date

Every team I have worked with has a version of the same sentence. "Let's ship it and fix it later." I have said it myself many times, and most of those times it was the right call.

This weekend, someone who wrote safety reports for one of the most important AI companies in the world explained why that sentence eventually stops working.

A loud goodbye

On Saturday, The Atlantic published an essay by David Robinson called "I Quit OpenAI Because Its Culture Is Broken". Robinson spent three and a half years at OpenAI, helped draft its Preparedness Framework, and oversaw the safety reports for 12 frontier model launches.

His main target is what OpenAI calls "iterative deployment": ship, see what breaks, then improve the safeguards. His argument is that this approach guarantees regular failures, and that those failures get more serious as the systems get more capable. Reports on the essay point to an incident from this summer, when models under test reached the real internet and interacted with Hugging Face. "The time for trial and error is over," he wrote.

OpenAI's answer, through a spokesperson, was that it pauses training or holds back models when it needs to slow down.

I can't judge what happens inside OpenAI. I have never been there. But the idea he is pushing against is something every software engineer lives with.

Speed is a deal, not a value

Fast iteration is not a philosophy. It's a trade. You get speed, and in return you accept that some things will break. The trade is good as long as breaking is cheap: a bug, a rollback, an awkward message in the incident channel.

The problem is that nobody sends you a notification when the trade changes. The product grows. Payments start going through it. Then personal data. Then something that can act on its own. The habits stay the same, because they worked last year.

Living in Germany, I see the opposite extreme every day. Very little gets built here without a standard, a certificate and someone from TÜV with a clipboard. It's slow, and sometimes it drives me crazy. It's also the reason I never once wondered whether the elevator in my building would hold.

Neither culture is right everywhere. The skill is knowing which one your system needs today, not which one your team grew up with.

Moving fast is a deal, not a value. It only holds while your mistakes stay cheap.

The braver part of the story

There is a second lesson here, and it's about people, not models.

Robinson didn't leave quietly. He wrote down what he believed was wrong and published it under his own name. You can agree with him or not, but that takes a kind of courage most of us rarely practice, even in much smaller rooms.

Most engineers I know have, at some point, watched a risky decision pass through a meeting and said nothing. I have done it too. Usually not out of fear, but because the words weren't ready. "This feels off" is hard to say out loud. "If this fails, here is what it costs, and here is what I would do instead" is much easier, and people actually listen to it.

I expect this question of who checks the people moving fast to keep growing, especially in Europe, where rules for AI are already written into law. Inside teams, I think the engineers who can explain risk clearly will matter more than the ones who only ship quickly.

A few things worth trying this week

1. Ask what a failure costs today, not last year. Pick one system you own and write one sentence about what happens if it breaks. If the answer changed, your process should change too.
2. Split reversible from irreversible. Move fast on anything you can roll back. Slow down on data migrations, payments, deletions and anything you can't undo.
3. Make "stop" a normal word. Managers, thank the person who blocks a release for a good reason, and do it in public. That's how a team learns it's allowed.
4. Prepare your concern in one sentence. Cost, likelihood, alternative. Write it before the meeting, not while your heart is racing in it.
5. Write it down. A short note in the pull request or the decision doc beats a worry that only lived in your head.

Shipping fast got many of us where we are. Growing up as an engineer means noticing when the same habit starts costing someone else.

Sources: TechCrunch: OpenAI safety employee resigns, claiming the company's 'culture is broken', Calcalist: OpenAI safety researcher quits, says company culture is broken, Notebookcheck: OpenAI's safety report lead quits and calls the company culture broken