Software Engineering has been a passion of mine for a long time. It didn’t start with binary or complex algorithms; it started with the joy of pure creation.
My first introduction was Scratch. As a child, I didn’t care about memory management or syntax errors; I loved that I could drag a block and make a cat dance. It was visual, immediate, and it hooked me on the feeling of building things.
As I matured, I moved to Python, JavaScript, and eventually Java. I remember opening NetBeans for the first time and feeling a distinct shift. I was shocked by how much “static” was required just to get going. public static void main, imports, class definitions—we called it boilerplate. At the time, it felt like a heavy tax I had to pay just to get to the logic. But I paid it, because I loved the problem-solving. I loved controlling what happened between the curly brackets.
When I got stuck in a while loop or hit a logic error, I didn’t have an AI to fix it. I had System.out.println statements and sheer stubbornness. I would brute-force my way to a solution, learning the intricate behaviors of the code by breaking it and fixing it, line by line.
The Shift to “Bespoke Libraries”
Fast forward to 2026. I am working on a personal project—a complex application I’ve wanted to build for years. In the past, this would have taken me months of weekends.
Today, I described the architecture to a multi-agent AI system. In minutes, it generated the file readers, the sorting algorithms, and the third-party client connectors.
This brings me to a realization: The profession is not ready for what is coming.
We have always used abstractions to move faster. We stopped writing sorting algorithms from scratch because we have standard libraries. But an AI agent is effectively a bespoke library. It is an infinite import where performance isn’t defined by the code’s efficiency alone, but by the quality of your prompt and the number of tokens you can afford.
The “frustrating” parts of code—the boilerplate I used to wrestle with in NetBeans—are gone. The AI generates it, and with recent model improvements, it matches the documentation surprisingly well.
The New Bottleneck: The Review Gap
Here is the problem we aren’t talking about: Code is shipping faster than human cognition can verify it.
In my personal project, the “writing” bottleneck is solved. But I have created a massive “reading” bottleneck. The AI can generate a Pull Request with five new features in the time it takes me to brew a coffee, but it still takes me hours to understand the implications of that code.
We have automated the typing, but we cannot automate the comprehension.
I recognize that AI hallucinates. To counter this, I use TDD (Test Driven Development) and multi-agent setups to get reliable results. But this shifts my role entirely. I am no longer just writing functions; I am auditing them.
Human bandwidth is narrow. We are not great at thinking systemically or holding deep recursive stacks in our heads—that’s why we used to add breakpoints and debug statements to our own code. Now, we have to apply that rigorous debugging mindset to code we didn’t even write.
The “Developer of Software”
I sometimes distance myself from the title “Software Engineer” these days. I prefer “Developer of Software.”
It feels more accurate. My value isn’t in knowing how to read a file from scratch anymore. That knowledge has become the new boilerplate.
My value—and the future of this profession—lies in what the AI cannot do:
- Systemic Architecture: Understanding how the pieces fit together when the codebase grows exponentially fast.
- Edge Cases: Anticipating the weird, one-in-a-million user behaviors that aren’t in the training data.
- Human Navigation: Collaborating with others to define what we are building, rather than getting lost in how to type it.
We are moving toward a future where the code is almost complete before we sit down. The challenge isn’t creating the software; it’s surviving the review process.