Quitting: Duty, not character flaw

“If at first you don’t succeed, try, try again. Then quit. There’s no point in being a damn fool about it.” — W. C. Fields

You’re working with your favorite coding assistant bot, but things aren’t working out the way you had hoped. What do you do? In reality, you’re presented with a simple, binary choice… keep going (try to steer in a different direction, correct problems, or improve things in place) or, just quit (and probably try again… or not).

When Pairing with Bots, its job is to execute things fast. This makes your job knowing when to quit, else it will bury you in slop. Do it early. And do it often. You might have to force yourself to do this. We’re conditioned by society never to use the “Q” word (it is a four-letter word, after all). It’s a moral failing to not “push through”, to not “overcome adversity”, to “give up like some kinda loser”. This kind of thinking will not do as you Pair with Bots. Half of your team is not human, which nullifies 50% of that argument. I’d like to posit that there’s a better way to view “quitting” in this scenario which obliterates the other half of the argument more completely than bombing a uranium enrichment facility.

Reclaiming lost opportunity

It’s not really quitting, it’s learning. And leveraging the opportunities our new coding assistants can afford us to the maximum degree. Why not give up this “meh” implementation and start over with a different approach (It’s probably going to cost you less than an hour). Heck, why not try 2 new approaches? Or 3? We can actually do that now… that’s actually a possibility. What an opportunity!

Let me take you back to the “bad old days” for a moment: I learned some expensive lessons in the decades before 2025. The development team had to proceed very carefully, methodically even, to avoid making a costly mistake like committing to the wrong library, database, architecture, programming language, etc. There was a tension between “big design up-front” (BDUF), “research projects/spikes”, and good old predictable, steady agile progress and incremental refactoring. The latter almost always won, because businesses prefer this and don’t really understand the long-term implications of committing to the wrong technical course of action.

As someone who worked most of their career in that mode, it’s soul-crushing. It’s hard to do well, and highly demotivating when you are aware of better ways to do things, but cannot make meaningful improvements to the code with any speed at all. I don’t think I actually left any code that much better than I found it, despite years of careful, safe “background” refactoring efforts mixed in with the features and emergencies “du jour”. In my experience, pre-2025… even if I were given the opportunity to spend some time developing and testing better approaches, it would never be enough time… and the code often reflected the “abandon-ware” nature of such repeated, ongoing and disparate experiments which usually followed the “strangler fig” design patter that never fully strangled anything. The added complexity of two competing, living software “trees” were left to eternally be locked in a death grip of complexity neither could escape.

Fast forward to 2026… this isn’t the issue anymore. I may never strangle like a fig again, because of the opportunities afforded me by just “quitting” approaches that don’t work. This is not to say migrations and transitions don’t need to still be carefully planned and executed… just that with the right automation and tools, the two implementations just don’t need to co-exist for months or years anymore… as they once did.

I hope you’ve noticed that replicating code in a different programming language, database, framework or library is one of your AI bot’s “superpowers”. It’s kinda the best way to supply a verifiable spec for SDD (spec-driven-development), especially if there are automated tests (or you add them first). “Transformer” is literally another name for an LLM. So, if you’re short on ideas, here are a few of my recent favorites:

• Quit your bloated TypeScript UI framework, try HTMX or WebAssembly
• Quit using slow, insecure Python back-end code, replace it with Rust
• Quit 🤑 paying the BigQuery tax, try 🦆 DuckDB (and Quack!) instead
• Quit making DevOps run books, automate a deployment dashboard
• Quit re-initializing Claude Code sessions, make a RAG knowledge base for it

Quitting these things means giving up something in which you’ve undoubtedly invested a lot of time and effort, something familiar that you’re very comfortable with… that’s hard, intellectually. You may decide, for example, that an HTMX UI means giving up something you can’t live without, but you’ll never know if you don’t turn your frustration with it into the motivation to “quit” it long enough to at least give HTMX a shot. Knowing when to quit the HTMX rewrite and return to the comfortable conventions of your framework is also a quitting skill. Quit early, quit often.

Starting Over with Jeff Grover

That almost became the title of this blog (in the AI before times). There are so many benefits to a “reset” mindset that we often overlook because we’re creatures of habit, or feel trapped by circumstances beyond our control, or we’re afraid to venture into the unknown, or don’t want to feel like we were “wrong” because we just deleted weeks of work.

With an AI writing tests, the practice of Test-Driven Development (TDD) is kinda weird… being that the practice is a design practice as much or more than it is testing. But if I can drag you back a couple of years ago into those “AI before times”… you may recall writing tests for existing code is hard. You AI pair will often fall victim to mocking the world surrounding whatever small subset of code you’re trying to add unit tests to, because that’s what humans did… and so this is how AI “learned” to do it. (PROtip: tell your AI pair not to do that in CLAUDE.md or elsewhere). Personally, I think this is almost always the wrong approach, and a missed opportunity to encapsulate and simplify a complex system.

A better approach is to carefully perform an extraction refactor on the code you want to test, which will then (hopefully) enable testing that piece of logic in isolation. By doing this, you are effectively quitting the dependencies and complications of the rest of the app, and allowing yourself to start over with a clean slate for writing your unit tests. It’s like an opportunity to write your “main()” function again for this small piece of the system, liberating you from the cognitive load and complexities of all the dependencies. The only thing that has really changed with this “one neat trick” of refactoring post-AI is that (while you still need to know about tricks like this) you can now somewhat safely perform this same strategy to target much larger parts of the system… maybe a whole sub-system at a time in some cases, and quickly get a revelatory result.

Loyalty bad, quitting good!

While there certainly are reasons to be loyal to a family, a cause, a country, or even a technology, there is a price to be paid. We need to recognize this. In a world where reducing your dependencies on bloated, problematic libraries subject to supply-chain attacks by implementing your own version in hours or days… we have to ask if that library deserves our continued loyalty.

I’ve grown to love the community, the simplicity and the convenience of the Python programming language. But I’m often quitting it these days… in favor of Rust (to which I feel no such loyalty) because of the huge performance and security benefits and the fact that those things I appreciated about Python as a language (mostly that it wasn’t “nit picky” about things when I was trying to accomplish a goal) don’t really matter anymore, because the AI is rarely “tripped up” by the cognitive burden Rust imposes on mere human programmers.

When everything is quickly changing around you, I think it’s time to realize you might have to quit doing some things, and quit being loyal to things you’ve been holding onto… if you want to survive. Things are definitely changing quickly in 2026, not just in technology but in the world… and I feel like we’re in real danger of falling behind or having our loyalties actively used against us if we don’t have the courage to quit things that just don’t work for us anymore.

Hate it? Just quit. It’s 2026, you have options… because things are changing.

Quitting: Duty, not character flaw was originally published in Pairing with Bots on Medium, where people are continuing the conversation by highlighting and responding to this story.