Source: https://arstechnica.com/ai/2026/07/openais-first-branded-hardware-is-a-light-up-keyboard/ I was talking to someone from one of the tech companies and told her that we are in a “Build to Delete” era. She said, “I’ve not heard that phrase before. Can you explain?” I was referring to a number of projects that I worked on in the last two years that are no longer needed, thanks to the advances in frontier models. Each model release surprises us with new capabilities, making some of the tools and services we built to improve the software development lifecycle redundant.
I still remember when we were content with the autocomplete feature in our IDEs. The next phase had developers using a chat window in the IDE to prompt for code snippets that they would copy into their files, similar to how one did with Stack Overflow in the last decade. Then agents started generating a lot of code, and developers got excited and began building code review agents. At one point, I got tired of all the code review agents in the company. Given the non-deterministic nature of LLMs, each one would find a different issue, causing burnout for folks who took these comments seriously and wanted to fix every one of them.
Source: https://www.anthropic.com/institute/recursive-self-improvement The diagram above depicts the progress made with each version of the Anthropic models when they were released. One of them made all the code review agents redundant, and it was time to rm -rf every one of them.
In late 2024, one of the teams I was working with was planning to build a nudge feature to notify reviewers about the pending code reviews assigned to them. I was impressed by a paper from Meta on how they used a NudgeBot to accelerate code reviews. Since I had very little experience with ML, I used the opportunity to work with an applied scientist and train a model on all the code review related data we had collected over the years, to test a smart nudge feature. The idea was to nudge developers based on a number of criteria so that notifications were customized, instead of sending them to everyone at the same time every day. Right after evaluating the smart nudge, I built what I called a zero-click merge feature, which selectively merged code changes that were marked safe by a rule-based system that eventually included an LLM as a judge. While the smart nudge feature did not make it to production, the zero-click merge did, and the last time I checked, it was still actively being used.
I’ve noticed a similar trend in the industry, with some companies retiring or disabling product features because they think the models do better. In November 2025, Cursor added a custom-trained semantic search tool alongside grep, since embedding-based retrieval helps agents find relevant code more reliably than regex search alone in large codebases. They reaffirmed the benefits of semantic search in January 2026 through another post, where they explain how they use Merkle trees to detect changes and avoid reprocessing everything. I recently saw a post online claiming that the latest versions of Cursor no longer support semantic search through embeddings generated in the backend. I couldn’t confirm this from their blog posts, but a Cursor team member confirmed it in a forum thread: agents now lean on an Instant Grep tool, and Cursor is no longer computing embeddings of your code or storing them on their servers for search. The reason given was that models had gotten good enough at using grep that the dedicated semantic search path was no longer helping in a meaningful way. Their March 2026 post explains the replacement, which is making grep-style regex search fast on huge repos by building local trigram and n-gram text indexes on the user’s machine, rather than relying on semantic search’s server-side embeddings.
I don’t agree with this one. I’ve built semantic search over the code base where I work, and it still earns its keep. Grep needs a seed token. The queries where you don’t know what the thing is called, like where do we handle shipping updates rather than where is ShippedProcessor, are exactly the ones embeddings were good at, and an agent that guesses seed terms and searches in parallel is paying in turns for what one lookup used to do. I also suspect cost was part of the calculus, since serving embeddings for every customer’s repo is expensive and a local index moves that expense onto the user’s machine.
Cursor made this call for their user mix and I’ve made a different one for mine, and that difference is the whole point. The question to ask before deleting anything is whether the model has absorbed the problem or has just gotten better at working around it. My code review agents died because the model itself started catching what they caught, so the problem was gone. Retrieval isn’t gone. The day I see our agents resolving concept queries without a name through parallel grep and not burning turns, I’ll delete the embeddings myself. But I haven’t seen it yet.
I could give many more examples of features that were essential last year and are no longer required. Some of us, myself included, have embraced the mindset of not getting too attached to what we build, staying flexible enough to move toward better solutions. However, I have seen a few other developers who hold on to their products and projects dearly, and instead of pivoting, they double down and invest even more. The sunk cost fallacy is in play: they value the work more because of how long it took to build, and in some cases ego takes over and prevents them from letting go.
I’ve been developing software for a very long time and have built some masterpieces in the past. I’m proud of what I’ve built, and a few times I reluctantly transferred ownership of services that I built and owned to other teams. It did hurt, but I let go and moved on to build bigger and better things.
Those who have read The Mythical Man-Month know that in most projects, the first system built is barely usable. It may be too big, too slow, or too difficult to use, but it kind of works. Using that solution, one can build a redesigned version that addresses all these problems and more. Treat code as disposable, expect to throw away your first solution, and focus on the problem solved, not the lines written.
With AI, we are at the same crossroads today. One of my friends mentioned that some of the teams he is involved with are considering rewriting their most heavily used services from scratch with AI. Rewriting something from scratch was considered blasphemy in the early 2000s. Here’s a post by Joel Spolsky where he argues that rewriting code from scratch is the worst strategic mistake any software company can make. That post is from the 2000s, and we are now in 2026, with AI disrupting everything around us. So maybe rewriting some services from scratch is not such a bad idea after all.
I rarely edit an agent’s artifacts myself, even for a small change, because I want the agent to make the change so that it remembers having made it. Given that large corpuses of code were written by humans, I suspect it might help if we have agents rewrite them, the way Brooks wanted in the 70s. While it was once prudent to make changes incrementally as part of a redesign, my experience has been to let the coding agent rip and then test once the entire code is written. If the tests don’t work as expected, or if the output does not match the specs, I throw everything away and start again. It has happened to me once, but starting from scratch was the best outcome for both the agent and me.
As new models are released, see if you can get away without some of the skills and MCP tools in your AI toolbox. Keep trimming the code and tools until there is nothing left to remove. If you take away one thing from this post, remember that refactoring or deleting code is a sign of progress, not a personal failure. While Werner Vogels would say, “Now, go build,” I will say, “Now, go delete.”