dvnc0

What are we holding on to?

Recently, I read through an article on the Every blog, "I Stopped Writing Code. My Productivity Exploded" by Yash Poojary. I read it a few times. The article details the addition of a new feature to an application without requiring a single line of code. Poojary essentially gives control to Claude Code and discusses what he wants, how it should work, and pastes errors in, without writing a single line of code. Immediately, I was hooked when I read "In the meantime, I had begun to question my value as a developer. I used to solve coding problems like sudoku puzzles; now I was watching Claude solve them while I just supervised. The brain rot was real, and I was terrified." A lot of developers enjoy the puzzle - the part of you that silently screams and celebrates every time you solve something complex or reach a root cause. It's the puzzle, the chase, whatever you call it. As our field evolves, there is a quiet fear that we will lose that, that the puzzle will vanish, and we'll no longer have our silent victories. Poojary goes on to discuss how he focused on design and user experience, letting the LLM handle the coding. Eventually, you get to this quote:

The fear of brain rot had haunted me for months. And it was justified: I couldn't write a hashing algorithm from scratch like before. When errors popped up, I'd paste them into Claude like a helpless child. The knowledge I'd spent years accumulating was evaporating. But after I made this new Sparkle feature, I realized that I no longer missed it.

Poojary talks about transforming from "someone who writes code to someone who ships solutions." By the end of the article, I was left wondering: what are we really holding on to? I have been thinking about this for about a week now, going over it in my head and writing down thoughts about this article in one of my commonplace books. I think it comes down to wanting to be in control and feeling the rush of solving the puzzle, admiring our own work, and reminding ourselves that we still have it. This hesitance to let go is slowing us down and will leave some of us behind.

The emerald

I'm guilty of this as well, even as an early adopter of using LLMs to code and someone who dove in headfirst. I still gravitated towards Cursor and handling the complex code by myself, never entirely giving in. I didn't like Claude Code and felt more at home with Cursor, with the editor begging me to write a few lines of code. I was convinced the LLM needed me to do the complex parts. I even went as far as logging out of GitHub on VSCode so I could have an AI-free environment to work in for the times when I really didn't need the distraction, because I needed to solve the complex problem, I needed to solve the puzzle. One of the most challenging things in life is admitting when you need to change. Admitting to yourself that you need to grow and evolve. Patterns are easy to get stuck in; breaking them is hard. You need to develop and shift your skill set to grow with the industry. I'm not saying abandon all hope and give up writing code. Instead, it's ok to let go, to forget syntax, to forget the years of documentation, and to forget which arguments come first. Focus on system design, architecture, user experience, being human, and understanding what humans like and dislike.

It's not easy for some of us to realize that what we have spent decades mastering, we can now let go of and forget. That after decades of being the computer, we no longer have to be. That the things we struggled to learn and grasp and remember years later no longer matter. It is hard to let go; it is hard to feel like that time and dedication are no longer a necessity, but they aren't. There is a Marcus Aurelius quote that I've been thinking about, which discusses the need for praise and admiration.

Is an emerald suddenly flawed if no one admires it?

I realized that a lot of what I was holding on to was the puzzle and self-praise, the "I still got it" moment, when I was solving a complex problem. If I no longer have that moment, if I give up control, does that make me a less effective developer? If you focus on architecture, systems design, and UI/UX instead of syntax and complex algorithms, are you less of a developer than you were five years ago?

Learning to evolve

I tried a similar experiment. I was looking for a simple image resizing tool with basic settings and a few presets for a site of mine that is image-heavy. I decided to install Claude Code again and talk. The experience was enlightening. I was able to focus on the solution and outcome, keeping that project-level thinking in place, and didn't write a single line of code. At the end of the session, I had the application I needed, with preset sizes I had defined and the basic features I required, without a single line of code and without opening an IDE (unless you count using vim to review the code). The puzzle was still solved, and instead of writing the code and struggling with new libraries, I was the conductor, the manager, the project-level thinker, describing the solution.

This will likely be the most significant hurdle for AI to overcome with senior developers. I know many seniors who use AI, but still feel that the LLM needs them to handle the complex parts. In some cases, this may be true, but what comes next? What about after LLMs, when AI has actual memory and learns and evolves faster than we ever could imagine? What then, will the AI still need you to handle the complex parts?

Borrowing from Marcus Aurelius again, time is like a river; the past is already long gone. If you're still holding on to what is long behind you, you're missing out on the future. Learn to be the conductor, evolve, grow, and let some of the decades of knowledge be replaced with new skills.

It's ok to let go.