I have been thinking about how engineers update their opinions, and the role model I keep coming back to is not the one most people would pick. It is a software engineer who spent two years mocking AI in public, then quietly started using it on a side project, then folded the experience into a softer public stance without ever admitting he had changed his mind. The pattern is more useful than the conclusion.
Most engineers I know treat their opinion on AI the way they treat their favorite text editor. They picked it years ago, they have defended it in a hundred Slack arguments, and they cannot let it go without losing face. The cost of that rigidity is starting to show. The teams that are shipping the most useful AI-assisted work this year are not the ones whose leaders had the strongest initial take. They are the ones whose leaders were willing to be wrong, in public, with a calendar attached.
This is not a story about AI. It is a story about how to update a position you have been vocal about, without losing the room.
The trap of the totalizing stance
The first thing to understand is why most engineers cannot update their AI stance. It is not because they have strong evidence. It is because they have made the stance load-bearing. They have built an identity around being the person who is skeptical, or the person who is enthusiastic, and any update threatens a story they have been telling about themselves for two years.
Most importantly, make the opinion non-load-bearing from the start. That means saying things like “I think this is true right now, but the math could flip in five years.” It means saying “I am positive about this for learning, but not for production.” It means leaving seams in the opinion so that the future version of you can update without breaking the earlier version.
The engineer I keep coming back to did this reflexively. In late 2023, when asked about AI-generated code landing in the kernel, he gave a shrug answer and pointed out that hallucinated bugs are not really worse than the ones humans ship. In 2024, he sharpened the line to say the AI industry was ninety percent marketing, and the math could flip in five years. In 2025, he said he was positive about vibe coding for learners, while keeping the kernel off limits. Each version of the stance left room for the next one. That is the move.
The escape hatch is the move, not the apology
What most people miss when they watch a public figure change their mind is that the apology is the easy part. The hard part is the sentence that lets the change happen without anybody losing face. The best practitioners do not write the apology. They write the escape hatch into the original claim.
It is a small piece of writing discipline. When you say “X is ninety percent marketing,” you are also saying “ten percent is real.” When you say “AI is useful for beginners,” you are also saying “use cases exist.” When you say “I will not put AI into the kernel,” you are saying “I might put it somewhere else.” Each sentence has a literal meaning and a structural meaning, and the structural meaning is the one that buys you room to update.
The mistake is to over-specify. The mistake is to say “AI is a fad that will die in three years.” That sentence has no room. You cannot update it without contradicting yourself. The sentence that survives is the one that locates the boundary explicitly: I am skeptical here, I am positive there, the math could flip eventually. The boundary is the load-bearing element. The opinion is the load-bearing element. Both pieces matter.
The Saturday project is the unit of evidence
Once you have a stance with a built-in escape hatch, the next question is how to actually update it. The recipe is the same in every case I have seen work: pick a Saturday project, the kind where nothing breaks if you throw it away, and run the experiment. That is what the engineer I mentioned did with a small audio effects tool. He wrote the audio core in C himself, handed the Python visualizer to an AI assistant, and noticed that the tool was useful, then quietly folded that observation into his public stance.
The reason the Saturday project works is that it has a low cost of being wrong. If the project is bad, you delete the folder and you lost a Sunday. If the project is good, you learned something the old stance could not have taught you. Either way you have evidence, and evidence is the only thing that lets you update without losing credibility.
The mistake is to skip the project and update based on what other people are saying. That is how you end up carrying an opinion you got from a podcast. The mistake is also to start with the project that matters. If you try to update your stance based on a six-month production migration, the cost of being wrong is too high, and you will defend the old stance out of self-preservation.
The private-public split is the piece nobody talks about
The other piece of the move is a public-private split. The engineer I mentioned did this with a small personal project, separate from the kernel work he is famous for. Personal projects can use AI. The kernel still cannot. That is how the public stance updated without forcing the broader community to update theirs.
This is a useful pattern for anyone whose opinion is followed by other people. You can update your personal toolchain and your public stance independently, as long as the personal is clearly labeled personal. The point is to be honest about which is which. “I use this on my own projects” is fine. “The kernel will use this” is a different claim. Conflating the two is what makes people lose trust.
The pattern that breaks is the opposite: updating the public stance without the private evidence. The moment you tell your team “we should be using AI for production code” without having built anything with it yourself, you lose the room. People will sense that you have a stance you cannot defend. The Saturday project is what makes the public stance defensible.
A practical version of this is the personal practice. Try the tool on something you do not care about, before you tell anyone else to try it. That is the order of operations. The order is what makes the public stance survive.
How to actually do this
Here is the simplest version of the protocol, distilled from watching this pattern work and fail in different shops:
- Make your stance have a built-in shelf life. “I think this is true right now, but the math could flip in five years” is a sentence that survives.
- Run a Saturday project before you change your opinion. Pick something where the worst case is “I deleted a folder and lost a Sunday.”
- Separate personal from public. Update your toolchain in private, then update your public stance when the evidence supports it.
- Talk to one engineer whose taste you trust before you let a podcast shape your view. Most loud opinions are echo chambers.
- Treat the stance as a draft, not a tattoo. The point is not to be right. The point is to be the kind of person who can update without losing the room.
The mistake is not having a strong opinion. The mistake is having a strong opinion that you cannot update without losing credibility. The way to avoid that mistake is to build the escape hatch into the opinion in the first place, and to back the opinion with experiments you have actually run.
Trade-offs
The trade-off with this approach is the time cost. A Saturday project is not free. Saying “I will test this on something I do not care about” still requires picking something, building it, and then having the discipline to throw it away if the result is bad. Most engineers will skip the experiment and stick with the opinion they already had. That is the rational choice in the short term, and the wrong choice in the long term.
There is also a trade-off in what counts as a “small project.” If your small project ends up being your largest archive of customer data, the experiment will tell you less than you think. Pick something where the worst case is “I deleted a folder and lost a Sunday.”
The last trade-off is the one nobody likes to talk about. The “change of mind” arc only works if you have a platform to begin with. The engineer I mentioned changed his mind in public because the public was already watching. If nobody is watching, the change of mind is just a habit change, and habit changes do not require any courage at all. Most engineers are not in his position. The good news is that the staircase is the same. The bad news is that nobody is going to write about it.
A practical first step
If you want to do this, do not start with the codebase you care about. Pick something on the side. Pick something where the worst case is “I deleted a folder and lost a Sunday.” That is the whole exercise. Use the tool, see if the result is something you would have shipped yourself, and then either keep it or move on. The point is not the project. The point is having an answer that is yours, not borrowed.