I started my first real software development job in my second year of university. A true novice, glowy eyed, and terrified that everyone around me could see how little I actually knew.
Even back then, before AI became the buzz word of the century and what it meant to write software changed forever, I hated the title "coder". I would never call myself it, it was not my title at work, and I would cringe a bit internally whenever I heard others use the term to refer to themselves.
I didn't fully understand why the word bothered me so much back then. But for all my insecurities, I knew it didn't describe what I was trying to be.
That instinct was right, even if I couldn't articulate it yet. I would come to understand that building software was never just about writing code. It's about understanding problems, making tradeoffs, and owning the outcome. That was true then, and it's even more true now.
Human-in-the-dupe
There's a growing narrative in the industry that goes something like this: AI writes the code, AI reviews the code, and eventually the human just approves the pull request. Maybe not even that. The whole loop closes and engineers become supervisors of machines that ship software on their behalf.
When something eventually does go wrong, you'll be faced with a sobering reality: you tried to deliver a solution with no accountability.
Accountability-driven development
The intuition I had many years ago, the reason I hate the word "coder", is because the primary value of someone who delivers software isn't the code. It's that they're accountable for it.
Accountability isn't about blame. It's about being the person who can say "I know what this does and I'm confident it should ship." Being accountable doesn't mean you'll never make mistakes. It means that when mistakes are made you are in a position to learn something and move forward.
You don't need to write every line yourself. But you need to understand what's going out the door. If you don't understand what you shipped, you have nothing to learn from when it breaks. That's the job. It always has been.
There's no trick to it. You gotta read.
I'm seeing more and more people discussing how to optimize AI driven code review cycles. Certainly there is a place for such reviews, but their place is similar to automated integration and e2e test cases, not human review.
No, it has nothing to do with reasoning capability or whether or not you think your favourite model is smart enough to handle it. Stop it. It doesn't matter.
Your software has value because you are accountable. You do not need to read every single line. Develop an intuition for what is important and risky, and read those parts. If you plan on delivering it, read the code that matters, whether it was written by you, someone else, or AI.