The engineer who directs the machine
For most of my career, being a good engineer partly meant being fast at producing code. You learned the syntax, memorized the APIs, and got quick at turning a ticket into a pull request. That skill is quietly becoming a commodity.
AI compresses the time from idea to working code. The part of the job that was writing boilerplate and glue is shrinking fast, and it is not coming back. If I define myself by the act of typing code, that is bad news. If I define myself by solving problems, it is the best leverage I have ever had.
What gets more valuable, not less
The interesting thing about cheap execution is what it makes expensive by comparison.
- Judgment and taste. Knowing what to build, when to say no, and when a shortcut will cost you later. AI accelerates execution but it does not have opinions about what deserves to exist.
- Systems thinking. How components interact, where they fail, what happens under load. The bigger the blast radius of generated code, the more this matters.
- Problem framing. Turning a vague business need into a well-scoped technical approach is more valuable, not less, when the building is the easy part.
- Debugging. Generating code is fast. Understanding why a complex system is broken still takes real reasoning and context.
The honest tension
There is a cost I feel directly. When the machine hands me an answer before I have struggled with the problem, I ship it, but I do not always grow from it. The struggle is where understanding lives, and it is easy to shortcut.
My answer is not to avoid the tools. It is to use them for execution and then deliberately reinvest the time they save into the things they cannot do: architecture, design taste, and deep domain knowledge. I keep a space where I work without AI on purpose, just to keep the muscle.
The engineers who struggle in the next few years will be the ones who were really good at typing. The ones who thrive will be the ones who were always really good at thinking, and who picked up a faster pen.