I’ve been noticing something about how I use AI tools. It’s not just about getting things done faster—though that’s part of it. It’s about optimizing my time so I can spend more of it doing what I actually love.
There are three distinct ways AI has been helping me, and the differences between them matter.
Teaching AI What I Already Know
The first way is straightforward: I take things I know how to do well and teach AI to do them my way.
Take user stories, for example. I have a specific philosophy about writing them. I don’t want to see technical concerns in user stories—those are stories for the user, not for the system. I want to see things from a person’s perspective, not just a user’s role. That’s how I write them, and it’s worked well for teams I’ve worked with.
So I’ve created instructions that capture that philosophy. When I ask AI to write user stories, it follows my approach. Then I can review them, refine them when needed, and move forward. Same thing with automated tests. I have preferences—not because they’re objectively the best way, but because they work really well for the people I work with and me.
I can combine the two: AI writes user stories following my guidelines, then writes automated tests to cover those scenarios. When I review the output, it reads as if I wrote it myself. When it doesn’t, I refine it and update the instructions. Next time, it does it my way.
This is AI doing things I could do, but don’t need to spend my time doing anymore.
Outsourcing What I Don’t Like Doing
The second way is about tasks I know how to do but don’t enjoy.
Think about the carburetor on my track bike. I could clean it and adjust it myself. But I don’t enjoy that work. So I outsource it to someone who either gets paid for it or actually enjoys tinkering with mechanics.
The same applies to certain software development tasks. There are things I’m capable of doing—things I’ve done many times—but they’re not what energizes me. Maybe it’s another frontend library, maybe it’s DevOps or CSS things. I know how to do these things (or I can learn them). I just don’t want to spend my time on them.
AI can handle those tasks now. Not because I can’t do them, but because I’d rather spend that time on something else—like having conversations with stakeholders or thinking through a design problem.
Learning What I Don’t Know
The third way is different: AI helps me do things I don’t know how to do, and don’t have time to learn right now.
A couple of months ago, I needed to add an AI-enabled feature to an application. I’d heard about Azure AI Search and thought that might be the direction. But I didn’t actually know—this wasn’t work I’d done before.
Instead of trying to learn everything upfront, I explained the problem I was trying to solve. I described what we currently had and what outcome I wanted. The AI implemented a solution that worked—and it didn’t use Azure AI Search because it didn’t need to.
That was valuable. I didn’t spend time learning something that wasn’t the right fit for my immediate problem. But I also didn’t just accept the solution blindly. I asked it to explain why it went that route. I asked when I should consider Azure AI Search instead. I had the tool document that contained reasoning in markdown files in the project, so I could revisit it later if needed.
It gave me just enough understanding for that moment—enough to learn something I didn’t know before, and enough to know where I might go next if I need to enhance that feature. If I never need to enhance it, I didn’t waste time going deep on something I didn’t need.
What I’m Really Optimizing For
That’s how I’m thinking about AI and software development now.
Is it fun to write code? Sure. Solving problems, writing code—that’s enjoyable. Do I care about code quality? Absolutely. There was a time when I was called “the code sheriff” because I was the one doing code reviews before static analysis tools existed, and I was very picky about coding standards and principles. I wanted code to be clean, intent-revealing, and purposeful. Even though clients would never read the code, I still wanted it to read as expressively as possible.
But here’s the thing: if I have tools that generate code to high-quality standards, I don’t need to write it myself. That’s not why I do this work.
Yes, it’s nice to show code to another developer and get positive feedback. But what really floats my boat is presenting a solution to the people we’re serving and seeing their positive reaction. That’s why I do this.
The Future I’m Building Toward
If I can ride my motorcycle without messing with the carburetor, that’s what I want to do.
If I can create digital solutions with good architecture and good code without spending all my time writing and debugging, that’s what I’m going to optimize for.
I’m building instructions for AI to write code for the things I care about—the things I know how to do well—so it frees up my time for quality conversations with stakeholders. So I can put something in front of them quickly and continue the collaboration. So I can validate ideas faster.
And here’s what’s different now: instead of creating throwaway prototypes, the code AI writes with proper instructions is already decent quality. It’s already close to production-ready. Which means I get to spend more time with the people I’m serving and less time writing code, debugging code, and ensuring standards.
Past, present, and future—that’s how I’m seeing it right now. The tools keep evolving, and so does my ability to identify needs, spot problems, devise solutions, and learn from what works.
What are you optimizing for?
