I Was Wrong About AI

I’m going to start with something a bit controversial, and honestly, it’s probably something a lot of you don’t want to hear. But here is the reality of the industry right now: if you aren’t using AI extensively in your workflow, you are essentially trying to build a career with one arm tied behind your back.

I know that’s a heavy statement. I know it because, for a long time, I was right there in the trenches of resistance with you.

The Purist’s Wall

If you’ve followed me for a while, you know I’ve always been a bit of a purist. I got into software engineering because I love the craft. There is a specific kind of reward in writing your own code, seeing a complex system come to life, and knowing that every semicolon was placed there by your own hand.

When the first wave of tools like GitHub Copilot or Amazon Q (now Kiro) came out a couple of years ago, I wasn’t just unimpressed; I was annoyed. To me, they felt like glorified autocomplete that got in my way more than they helped. They were clunky, they produced slop, and I eventually just disabled them so I could get back to real work.

In all honesty, my skepticism was fueled by a fear that AI was an attack on my identity as a developer. If a machine can generate the logic, what am I actually here for?

The Shift in Abstraction

Everything changed about six to eight months ago when I stopped looking at AI as a code generator and started looking at it as an orchestrator.

I started small. I used it to rewrite Slack messages, summarize massive document threads, and handle the administrative overhead that usually eats up a developer’s morning. But then I moved into brainstorming. I started throwing organizational and strategic problems at these models—problems I used to spend days agonizing over alone—and the feedback was startlingly sharp. It was revealing insights and angles I probably never would have found on my own.

The real “Aha!” moment happened with a pet project at work. We had this persistent pain point: a system that was incredibly difficult to simulate, which meant leadership was constantly asking questions we couldn’t easily answer. I decided to try out spec-driven development.

Instead of writing the code line-by-line, I fed the AI the requirements, the user stories, the infrastructure constraints, and the data models. By being prescriptive and setting strict guardrails, I was able to reconstruct a simulator prototype in record time. It blew me away. I wasn’t just coding faster; I was solving a multi-year organizational problem that had previously felt too daunting to tackle.

The “Boss Factor” and the Corporate Meta-Game

Whether we like it or not, the “corporate game” has changed. Companies are under massive pressure from shareholders to show productivity gains through AI. You see it in the layoffs and the shifting narratives from leadership.

There is a Boss Factor here that you can’t ignore. Managers love it when you make them look good. If I have an employee who uses AI to solve a problem that was previously unfeasible, that’s a success story I can bubble up to my directors. It makes the employee look innovative, it makes me look like a forward-thinking leader, and it makes the entire organization look like it’s winning the AI race.

If you’re ignoring these tools out of a sense of purity, you’re missing a massive opportunity to build career capital. You’re choosing to stay at the baseline while the baseline itself is shifting.

The New Productivity Baseline

This isn’t a prediction—it’s already happening. New measures of success are being built around AI usage. It starts with rewarding the people who use it, but very soon, it will move toward performance-managing the people who don’t.

You don’t have to love every output the AI produces, and you definitely shouldn’t trust it blindly. But you do have to get your hands dirty. Whether it’s using Claude Skills to aggregate project details so you don’t have to bother people with “status update” emails, or using spec-driven development to prototype systems in hours instead of weeks, the goal is the same: efficiency.

The ground is moving underneath us. We can either decide to stay at the forefront of this shift, or we can watch ourselves drift slowly into irrelevancy. It’s a fundamental change in how the software engineer operates, and while that’s scary, it’s also an incredible toolset if you’re willing to use it.

Get on board or get left behind. The choice is yours.

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts