AI is the muscles, you must be the brain

The Three Positions on AI

Let's face it. It is no longer a matter of "if" but "how" when it comes to integrating AI tools into your daily dev work. Ever since AI becomes a real thing in IT, I felt myself trapped between contradictive and equally wrong positions.

• Some treat LLMs, GenAI and AgenticAI as a silver bullet that solves everything and allows a single unskilled person to deliver the work of an entire IT department.
• Some are scared or they even hate AI because "it will take everyone's job" and/or "it will make us stupid".
• And others try to ignore it and to avoid it, being convinced it is "useless" and they can work better without it.

It feels difficult to navigate through the raging sea of such articles and social media posts. Things are never as good as you wish and never as bad as you fear. This is what I tend to believe as a universal truth, sort of. It applies here as well.

A Senior Dev’s Perspective

As a senior dev, I don't fear AI will replace me. I don't mourn for doors being closed; I foresee new doors that are opening. In the worst-case scenario of being laid off by my current company, there are so many new possibilities! I am also realistic enough to know it is never that easy. I already lived through the "agile revolution" or "cloud revolution", and while some issues were addressed by then-revolutionary approaches, others remained and even brand new emerged. The SW engineer's work is never done.

Lastly, I am not being overconfident enough to feel too good for AI. I am pretty sure I will never navigate between files and grepping its contents so quickly as a tireless machine can. Also, despite being quite fast at typing, I will never match my Copilot. So I won't even compete. I will let AI do things where it shines and keep myself the important things - defining the goals and verifying the results. That's it.

The Shifting Role of the Developer

The dev's role is shifting from writing the code to owning the code, and from resolving Jira tickets to writing them. I can see why some struggle with this. Being a code monkey wasn't much, but it was honest work. Adding architectonic and managerial overlap and having to deal with a whole new class of problems might be overwhelming.

I consider myself lucky that AI arrived in times when I already have solid computer science fundamentals and years of practical experience with application development. This allows me to use GenAI not just like a wheel of fortune, but I can be reasonably confident about judging the result and steering it towards the right path. For juniors or people who never even wrote code before, this might be difficult if not impossible.

Learning in the Age of AI

On the other hand, learning new things has never been easier. Your personal teacher is ready 24/7, and you are in charge of what you will learn, when, and how. This can be both a good and a bad thing though. Again, I believe I can handle it, because I already have past experience with moving myself forward. I am used to looking for new information and ready to verify what someone tells me against the unbiased primary sources. What about someone who is not? What about the children? Won't somebody please think of the children?!

Worry not. There are already brilliant minds, people smarter than me, who are developing new techniques of the AI-infused learning process. To name one and to show you what I mean, you can watch THIS TALK by Juan Andrés Núñez. As with all new technologies, we just have to learn to work with them properly.

A Typical Workflow with Copilot

Which leads me back to the original idea of this article. That is to remind everyone that the "proper" usage of AI means to augment your capabilities, not to replace them. Exactly as The AI Manifesto says.

My typical workflow now is to tell GitHub Copilot what I want to do, wait for it to implement a draft, and then reason about the result and tweak the produced code until I like the result. Whenever I realize it is faster to describe the task than to make the changes manually, I do it. And in fact, it is almost always faster. The mainstream frontier models and their harnesses in coding tools are already so good that even with imperfect prompts they produce good enough results. The rest is on my judgement and experience. And sometimes a trial-and-error round. Or more of them...

I always remember one of my university teachers as he told us he had to go 4 floors up and down whenever he had to change something in his program and needed a new punch card for the machine. So they were rather thinking thrice before just "trying" something. But I was already born into the era of convenient IDEs where you just one-click and see. You dig through errors until it works. And I lived to the rise of equally simple cloud deployment - I currently just commit to GitHub, Netlify does the rest, and I see the result live in a minute. That was already before AI. Copilot just speeds the process up.

It is much more effective in pinpointing the problem (although sometimes obscenely wrong about the real causes), because it reads the logs, navigates through files, and visualizes the code flow much faster than I could ever do. But it is still up to me to keep control, because the solution it creates is not always the best. Sometimes it is actually very bad and I must step in. But the overall process is much more enjoyable than sitting alone hopelessly and praying for someone's answer on Stack Overflow which may never come.

The same with developing new features. For me, it is much more convenient to reason about already existing code than pioneering the solution from scratch. I let Copilot do it and then I "just" dismantle it. I want to understand what each piece of code does. When I am suspicious, I question. When I think it is not all right, I raise objections. Sometimes Copilot agrees, sometimes it convinces me about its solution (before it does, I am cross-checking and verifying its statements to make sure I am not falling for a hallucination).

But I also have to admit it is getting more and more difficult to keep the morale to honestly check everything and to do a proper code review every time. When the task is bigger and the number of changes larger, the determination of going through everything fades. And this is exactly the time when I must remember - the muscles work, the brain must control.

A Cautionary Tale: The Icon Incident

There was a recent inconspicuous event that reminded me how important this is. My task was to improve our custom UI library and provide it with "success" and "error" cards to display results of our API calls. They should feature a green or red circle with either a tick or an X icon. As always, I set AI in motion. As always, it creates a decent solution. As always, I did my best to check the outcome.

Then in 2nd level code review my colleague remarked: "Ok, great, but why did you use custom SVG path to draw icons? We already have predefined icon components in the project." Which is something I completely forgot as I am constantly context switching between three different projects I currently have something to do with. And Copilot didn't sniff it up because why should it?

This little incident didn't mean much. I fixed it (using AI) in no time. And that's why we have code reviews after all. But it still resonates in me and inspired me to write this.

The Core Message: You Must Still Think

Having the source code written or a log file analyzed is now easy and fast. But you still need to be there to govern and guide. You still need to think. You still need to abstract and to imagine. You need to know what and why. You need to turn processes into requirements and requirements into tasks. You need to understand your code. You need to properly document your project - not only for others, but especially for you. And now you also need to learn how to talk properly to your AI agents and how to provide them with instructions to become more effective in helping you achieve your goals.

The programming job is still there. AI didn't take it. It is just a bit different. Easier in some ways and more complex in others. The SW engineer's work is never done.