The word “no” is a powerful word in anyone’s career.- Justin Theroux
There is a mythical figure in software engineering: the 10x engineer is someone who is ten times more productive than their peers by accumulating a toolkit of personal efficiencies.
When I was fresh out of college in my first software development job, I was a 10x engineer. I knew it, I loved it, and I generally kept it to myself. I consistently beat my estimates, but I used my efficiency to build systems that were 10x better written and tested, not to pump out 10x as many features.
The core of my secret sauce as a Java developer was, first and foremost, being a solid engineer. Second was aggressively leveraging Perl to automate my environment and workflow. While our "build master" struggled to manage a clunky Windows batch file, I set up a nightly Perl cron job that pulled and compiled both the latest codebase and the stable release. Everything was ready on my desktop the second I walked into the office. I wrote a custom style checker and auto-corrector. I wrote scripts to generate those darn boilerplate getters and setters. I built my own unit testing framework back when the rest of the team relied entirely on manual QA.
One of my favorite tricks was maintaining a local Microsoft Access database that replicated our shared Oracle DB. Whenever the development database broke and work ground to a halt for everyone else, it was no problem for me to swap my JDBC config and maintain progress.
I shared none of it. As an individual contributor, I felt it wasn't my job. I knew that if the team adopted my custom toolset, I’d become the default "owner" on the hook to fix it whenever something broke. Keeping the rest of the team moving wasn't my responsibility… so young me thought.
As my career matured and I took on broader responsibility for team success, my perspective shifted. I realized that elevating an entire team to 2x or 3x performance was far more valuable than being an isolated 10x individual. Over time, the custom tricks I used were democratized and built into standard tools like Checkstyle, JUnit, Eclipse, Ant/Maven, CruiseControl, and Clover. The gap closed, and the classic Java 10x engineer faded away as standard tooling caught up. Since then I’ve watched every new technology wave trigger the rise and fall of the 10x engineer. Now, in the early stages of agentic coding, the 10x engineer is back. Be wary.
I regularly talk with colleagues using agentic AI development tools to achieve astonishing levels of individual output. I consider myself both an AI optimist and an AI skeptic. AI is incredible at getting work started, but it struggles to cross the finish line if you hold your codebase to high standards. In software engineering, the first 80% of a project takes 80% of the time, and the remaining 20% takes the other 80% of the time. I have yet to see AI solve that second 80%, and I worry we are accumulating technical debt under the premise that future AI will be smart enough to clean it up. Maybe it will, but when?
Just as with previous waves, the real shift to team efficiency won't happen through everyone becoming an isolated power user working in a vacuum. The real transformation will occur when today's "AI ninjas" step back and democratize their workflows into repeatable, team-wide tools and processes. I can’t wait to see how it shakes out to measure the true, collective productivity gains across whole teams.