It's another reddit thread. Go ahead and get your pitchforks and head to the comment section. I'll see you all down there.

Disclaimer: No tokens were consumed while writing this post.

This expression "Writing code was never the hard part" is something that I've preached. Because to an extent, it's true. I've been a software engineer at various levels for 15 years and the hardest part of the job is always dealing with everything that is ancillary.

• Meticulously defining requirements so that there is absolutely zero confusion from stake holders when you deliver what they asked for.
• Convincing stake holders that what they are describing is not actually what they want. No, they actually want this instead.
• Finding out how to dodge the hype traps. No, we don't need blockchain. No, we don't need to go serverless. I know it's webscale, but SQL is what we need for our use-case. I know you're reading a lot about kubernetes... Actually, I like kubernetes.
• Remember those meticulous requirements? Well stakeholders are back and they're ready to gaslight you about what you discussed.
• Manager just sent you a PM. They want you to know that you shouldn't work overtime, but that thing that would probably take you a week needs to be done on Monday. It's Friday.
• Oh. The bikeshedding. Don't even get me started on the bike shedding. We need to build a simple app so that our customers can fill out 4 forms and submit them. We then map it to a number of different downstream providers and the work is done. But Scotty Staff engineer, who has something to prove, wants to talk about why our story points need to represent complexity instead of time.

There are a number of things you deal with day in and day out as a software engineer that have nothing to do with actually sitting down and writing the code.

Time for personal anecdote.

So I would say it's hard to really pinpoint where success comes from. I like to attribute mine to being pragmatic, having good intuition when it comes to design, being able to effectively communicate with management and being able to give good direction to software engineers.

I'm good at convincing our team that we can go with the simpler approach. I'm good at developing understanding for operations and cloud, which has led me to design pretty reliable and scalable systems. I've also just been around the block enough times to know where the footguns are hiding and I've solved this problem before.

I can pass interviews. Leetcode comes easy to me, even though I hate it.

But I also have ADD. And sitting down and writing code without getting distracted is something I find very difficult. I can decompose the problem. I can be forward thinking when it comes to design. I recognize when I need to rewrite something. I can research with the best of them, and syntax is something that naturally sticks in my head for some reason.

But locking in to do that? Feels impossible sometimes. Sorry, I have to respond to this slack thread. Someone wants to build their own Kafka and I just need to teach them how to use Kafka.

Ok, back to writing the code. Wait. Our pipelines quit working. Our atlassian admin revoked all of our keys in his effort to implement our companies new "least privilege" OKR. Sure would have used some heads up. Ok. Back to writing the code, what was I doing again?

I say all this because I notice this trend. This trend that people think that only bad engineers are using AI. I'd say it differently. Developers are using AI badly.

If you're not reviewing, and actually reviewing, the output of the AI, you're doing it wrong. Ok, no, you don't need to fully understand that regex in that script that it wrote to parse that API. The data that comes back looks good and it's not that important that it's 100% accurate.

Claude code has become my daily driver. I have significantly shifted how I write code, and I've also spent a lot of time learning in depth how these products work and all of the different techniques, the ins and outs of the settings and configurations. It solves the ADD I have. Because I can sit down and write out a PRD. I can design something ahead of time and be very specific about what I'm asking for. I can give it specifics to validate the implementation. And I can get distracted while I'm writing it and come back to it and finish it.

I know that AI is a contentious topic. I know that it feels so good to dunk on the vibe coder. Because they're not real programmers. The true scotsman is practically baked into the software engineers DNA.

But I will stand by one bold prediction. The future is not going to be a dichotomy of good and bad programmers. People who figure out how to effectively leverage AI in their job (emphasis on effectively..) are going to excel. People who refuse to adopt the technology are going to fall behind.

Because as a reminder: This is what engineering is. It's very easy to go back a year and point out all of the bad things AI used to do. And a year later, it still does a bunch of bad shit... but it has also dramatically improved. Remember when it used to just straight up hallucinate APIs and websites that didn't exist? Now it does that sometimes, but it typically does it in the background and iterates enough to get to the real API.

And it's only going to get better. It might get worse before it gets better, but eventually, this technology will be better than it is today.

Or it won't be, it'll be abandoned to the graveyard of other tech that never lived up to the hype. But I don't think that's the case here.