Article summary
If you’ve been a developer for a while, you’re probably adopting AI one way or another. I still remember the early days when prompts never got me what I wanted. I figured it would be a while before AI took over my job. Within weeks, however, as the models improved and I got better at prompting, there was a distinct moment when I was genuinely surprised and nervous that the code was 95%, if not 99%, of the way to what we wanted.
Grep is faster than eyeballs.
Fast forward three months: my days are no longer spent on line-by-line coding. I am now running prompts, assessing product requirements, and evaluating architecture decisions. Some of these tasks are those we’ve always done as developers. The majority of our time, however, I spent thinking about syntax and how to make code legible, organized, and ready for another developer. We usually beam with pride when we hear a new dev who’s onboarding say, “Nice! The codebase is well structured and easy to understand!”
Almost none of that matters now! AI reads code better than humans can. And, it no longer needs you to make sure that you’ve abstracted all your variables so that they’re easy to find! Grep is 10,000 times faster than human eyeballs!
What do we find joy and pride in now? Although development increasingly looks different, I have found that a couple of things that used to be difficult are now rather enjoyable.
Debugging.
It used to be painful and slow to put logs everywhere so that you could trace through your thinking. Now, it’s as simple as “let’s add logs so we can trace the logic from UI to DB.” You may think we might not even need to debug and could simply ask AI what’s wrong. But let’s not take away even the last bit of joy we have now. Debugging step by step and seeing the process still challenges me to know the codebase and gain control over the repo. This approach also allows me to gut-check my understanding of the infrastructure at a faster pace. I used to debug only a section of the code at a time, but now I can add logs within seconds and get a bigger picture faster.
Onboarding.
Going back and forth asking the agent how the repository is structured is a great way to get the lay of the land. The flexibility to ask as many questions as I need allows me to learn beyond the current code. All said, it is still important to talk to someone who has the project context to understand all the gotchas and business needs.
At the end of the day, development is all about problem-solving; we should always find ways to enjoy and be active in this process, regardless of the tools we have at hand.