Let Go and Let Copilot
Developing healthy detachment from your code
Buddhism teaches us that attachment a.k.a. grasping or clinging is one of the main causes of suffering. Attachment is the basis of the second of the four noble truths, 1) that suffering is inevitable 2) that attachment leads to suffering 3) that there is a possible end of suffering 4) that there is a path to follow to reach that end of suffering.
How can one of the fundamental teachings of a 2500 year old philosophy help us adjust to a modern reality filled with AI coding assistants like Windsurf, Cursor, and Copilot?
Creators can easily become attached to what they produce. We see open source authors appointing themselves "benevolent dictator for life" to lend a watchful eye to their creation years after their last personal contribution to that code. Any of us working in this industry have personally seen countless examples of someone being painfully attached to a tool, design, or implementation.
How does our level of attachement change when a non-human entity starts doing a significant portion of the creation?
Job Satisfaction
The work and cognitive load needed to rewrite a large piece of functionality can cause a human to reconsider taking that leap. Deadlines still exist and most managers still expect you to not spend too much time on work that doesn't lead to new features.
The mental cost of a rewrite shrinks when Windsurf can quickly rewrite the same piece of code 3, 4, or 15 times for you. You don't even have to end up changing anything if after seeing 15 iterations you realize the original was either good enough, or elegant in ways you couldn't appreciate before seeing all those alternatives.
Attachment can start to negatively impact engineering team cohesion when it intersects with ego. When you have personally tried and failed to unravel a particularly gnarly section of code, and an ambitious junior comes in ready to tackle it, the natural tendency is to scare them off, a partly out of fear they may succeed where you failed. If my ego can attribute their wins to being partially augmented by an AI assistant, I don't have to feel a twinge of defeat or self judgement. Humans and AI assistants will both benefit from that gnarly code being untangled and nobody has to lose face.
When working with AI you will still feel some pride when your work is pushed, but you probably won't be overly attached to any particular part of that implementation with your personal investment in that change being smaller. As long as you were actively engaged with your AI pairing partner and paying attention to what was added, you will still maintain a smaller and less complete mental model of that code, without the side effect of not wanting to change it. You're still learning and growing, just not overoptimizing for the skill of typing working code from memory.
I’ve personally found that adding AI tooling to the mix has reignited a desire to program that had started to atrophy. I love learning new things and producing working solutions to problems a lot more than I love the artform of producing elegant code. Consistent style can be very important when you had to bounce around the codebase yourself and walk through each function but your AI assistant is more patient at explaining its own decisions than any programmer I’ve ever worked with.
Every potential coding project represents a time commitment, and as I became more experienced I found myself using that calculus to write as little code as possible and save my limited coding time for the highest impact projects. When I can vibe code a small script or browser extension in 15 minutes, that calculus suddenly always points to yes, meaning I can quickly automate away a much larger portion of my tasks without worrying if that work distracted me from that core business-impacting activity I was hired to do.
Maintainability
You have to start making your architecture and coding style expectations explicit. Don’t just plow forward on your own defining architecture by being the noisiest contributor, expecting other individuals to follow your conventions, or forcing them to by being a pain in the ass in every code review.
This is another place for you to let go. Don’t stress yourself out making yourself a required reviewer for every subsystem you own. Document explicitly what types of changes you'd accept and the format you'd accept them in, write that in a format both that humans and AI can consume. AI tooling has lowered the barrier for working in unfamiliar code making multiple people more likely to contribute even on a small team. The contributions of many individuals and the unique prompts they provide their own assistant will further distance the code over time from the weight of a single individual's perspective.
As long as changes are being done with care and standards are kept high, the result should be more, not less maintainable than something heavily tied to the opinions, skills, and ego of a single individual.
Identity
The biggest and probably hardest thing to detach from will be our identity as coders. Getting really good at coding and watching yourself crank out a really good implementation can be very addictive. Spending 15 years getting good at anything and then being told that specific skill is no longer as lucrative or useful as it once was is a hard pill to swallow. This transition is going to be hard for both current individual contributors and those higher up in the tech industry that still look back fondly (often through rose-tinted glasses) at their glory days heads down cranking through hard problems through typing, coffee and force of will alone.
As someone who was a daily hands-on coder, dropped that identity for a trip into management, then came back to it, I was ready for a tool like AI to take over some of the heavy lifting for me. The normally busy schedule of a staff+ engineer expected to be writing design docs, attending architectural reviews, and working as a conduit for stakeholder made any tool that can potentially save me time but let me stay hands on look better and better. "You can produce more working code in a shorter time AND get help picking back up where you left off more quickly" sounded great to me.
I realize this isn’t going to be and easy transition for everyone, try out vibe coding on a side project, and see what it feels like. Remember you aren’t letting go of all your experience completely you are bringing in a typing assistant. Imagine if a lot of code reviews could be less contentious. What if the expected standards for a codebase were clearly understood by everyone involved before review time?
We may not become enlightened, but we might be able to be a little bit less stressed out at work.