Get the guide to build your first AI agent directly in your inbox on newsletter signup:
Some time ago I wrote about how I was able to merge 100+ PRs a month.
Those were mostly config changes in JSON, so you could argue that you can’t compare config changes with code. Well, now I reached the same throughput with code. It was just a matter of time.
But while AI has automated most of the manual steps that I had to take, my own understanding of the process is becoming more and more a black box.
No problem when things work well, and I have working code as an output. But it’s a problem when I want to optimize this system. I can’t optimize what I don’t understand.
In this article we’ll see how to increase our throughput without becoming a dumb proxy between requirements and prompts.
AI increases output but reduces your capability
Before AI, if I picked a task, I had to do things like
Explore the surrounding code
Create a plan to implement, at least in my head
Implement it, running the unit tests and iterating as needed
Deploy it to do some testing and attach the proof of testing to my PR
Raise the PR
Iterate, addressing any comments
Now AI does mostly all of this. I just point it to which task to implement, define the goal, and AI does all the other things.
But in the process of asking AI to do things, I lose visibility and understanding of the process. Is AI making a plan first, spotting gaps, and then implementing? Or is the AI implementing, then realizing it doesn’t work as expected, and course-correcting?
This may seem irrelevant if the end result is working code. But we know as software engineers that the ends never justify the means. Bad code, a bad process, and you’ll suffer from it when maintaining production code later.
The same way we have a metric for PRs raised, tickets closed, or story points delivered, we should have a metric for our level of understanding and our level of expertise as software engineers.
Your job is to operate at two levels
It’s a paradox that the same person has to oversee the process and stay very high-level to achieve high throughput, but also dive deep into the low-level details and tweak the process to optimize it. That single person in both sides of the process is you.
You definitely need to define the goal and constraints, and be on top of the architecture. But you should also optimize to make sure the agents follow a process that leads to no confusion. So how do we maintain our ability zoom-in and zoom-out in the software development process?
Let me tell you how I handled it in the last project that I worked on.
Every AI workflow that I’ve built starts from the inside. I start by building an agent/skill to deploy and verify. Another one to raise a code review. Another one to handle the implementation with the constraints of the project... Step by step, I’m removing myself from the low-level details, and a bigger part of the process is handled by AI.
The key for me is iteration. On the first attempt, I don’t try to make AI handle the end-to-end. It just happens over time.
If you follow these steps, the important part is always being aware of the high-level of the project. This is what good Senior engineers are able to do. They can implement but maintain a 10,000-foot view of the project.
After some time, you’ll face the opposite problem. It’s been months since you had to run the build yourself, but lately, for some reason, the agent is looping too much in build failures.
This is something that also happened before AI in software engineering. You don’t look into working code while it’s working. So rather than brute-forcing the AI into finding a solution, I’d recommend working in steps:
Isolate the part to optimize. Don’t ask AI to handle the end-to-end. Instead handle up to that part, and also after that part
Slow down and read. We’ve done this all the time. The stack traces and error logs are where we start investigating failures.
Figure out what’s wrong, and generalize it to update your agent/skills
Chances are that you find a failure that is trivial for you, because you’re an experienced engineer, but it was not obvious to AI. This is the most common failure scenario: We ask the AI to do things, but we don’t realize the AI can’t read our minds.
The good news is that AI can self-update agents and skills. You don’t need to write the markdown by hand, but just inspect the end-result.
Build the software engineering equivalent of 10,000 daily steps
There were no gyms thousands of years ago. The gym is the consequence of us moving less in our day-to-day.
We are in a moment in history where we could think less than ever. I’m not saying this is good, quite the opposite, but it’s the reality. Nowadays, people can delegate all decisions, all understanding, and all actions to AI
Even if you think this is not your case, you’re reading this article, so you’re better than the average developer... you’re also experiencing, to some degree, the atrophy of the brain.
Many people try to walk 10k steps per day as a baseline of activity. We now need an equivalent for our brain.
If you’re already having some goals for your fitness and health, let’s also add some goals for your brain health:
Read every day. Ideally, some technical material in the context of becoming a better software engineer, but any reading, including reading a novel, will make your brain focus on one thing and achieve a deeper level of focus than if you’re switching between agents.
Define the problem in depth upfront without help. This is not about ignoring AI, but for AI to work well, it’s better if you have a good definition of the problem and constraints. You can work in a whiteboard with peers or just write down all the context yourself to send it to AI for review.
Run periodic system audits. Even if you see the code reviews flowing, from time to time it’s good to review what the process is once again. It may have been months since you implemented some parts of it into an agent/skill, so refreshing your mind is always good. You may find optimizations that you wouldn’t do otherwise.
For the first brain goal, reading this newsletter is already a good one. Make sure to subscribe to access all the techniques and systems
Conclusion: Automate the manual work, not the understanding
I don’t know how things are going in your company, but I see the leadership at Amazon pushing all the time for AI adoption and removing ourselves from the process.
Yet we have to own it. We have to explain it to other teams. We can’t afford to wait for an AI agent to finish to give an answer in a meeting.
With the ideas from this article, you’ll be able to zoom-in and zoom-out, you’ll preserve your engineering skills while delivering faster than ever. Thanks to your in-depth understanding, not only will you deliver faster, but you’ll deliver at higher quality.
Now let me ask you: What will be your brain goal, the equivalent to the 10k daily steps but for your brain?
If you found value in this post:
❤️ Click the heart to help others find it.
✉️ Subscribe to get the next one in your inbox.
💬 Leave a comment with your biggest takeaway
♻️ Share it with your peers
AI is already helping you to save time (phase 2). Today’s article will allow you to do the things that make you grow and create evidence that you can work at the next level, making progress toward your promotion
I’m building this system below for paid subscribers. Thanks for your continued support!
🗞️ Other articles people like
I agree with you. The thing is now we delegate our understanding to it and sometimes that understanding makes us learn too!
One thing I am doing is deciding what I can do end-to-end with AI and what requires deep understanding. I also use AI to walk-through the application so I can understand the main parts of it.
Regards.