For the past few weeks, I've been running an AI agent as my de facto junior engineer. It has access to my repos, can open PRs, writes code, debugs issues, and proposes features. I review its work, give feedback, and point it in the right direction.
This sounds like a productivity hack. It is. But the bigger thing that happened is that it made me a better engineer. Not by writing more code, but by forcing me to think like a senior.
The shift: from coder to manager
When you're the one typing every line of code, your brain is in implementation mode. You're thinking about syntax, edge cases, that weird TypeScript error that doesn't make sense. You're deep in the weeds.
When you're reviewing someone else's work, even an AI's, your brain shifts. You start asking different questions:
- Does this solve the actual problem?
- What's the long-term maintenance cost?
- What could go wrong in production?
- Is this the right abstraction, or are we building a mess?
Suddenly I had skin in the game.
What I realized about good engineers
Delegating work clarified what I actually want from an engineer. Not abstractly, but concretely, in the moment, when I'm waiting on a PR or triaging a bug.
Here's what makes someone (or something) good to work with:
Propose features intelligently. Don't just say "we should add dark mode." Explain why it matters, what the scope is, what the trade-offs are. Show me you've thought about it. A half-baked suggestion wastes everyone's time. A well-reasoned proposal moves things forward.
Work independently until you actually can't. The worst thing is when someone asks a question they could have Googled, or worse, asks for permission to try something obvious. Just try it. Come back when you're genuinely stuck, not when you're just uncertain.
Call out risks early. If you see a problem (a race condition waiting to happen, a scaling issue, a security hole) say something. Don't bury it in a PR comment. Don't assume someone else will notice. Flag it, explain why it matters, and propose how to fix it.
Deliver working solutions. Not "I made some progress" or "it mostly works." Actually working code, tested, ready to merge. The last 10% of a task is often 50% of the effort. Finishing is a skill.
Handle debugging on your own. When something breaks, I don't want to be the one stepping through logs line by line. Investigate, narrow it down, propose a fix. Then tell me what you found and what you did about it.
None of this is revolutionary. It's just clearer to me now because I'm on the receiving end.
What that leaves for me
If I'm not writing every line of code, what am I doing? Turns out: the stuff that actually matters for building things that last.
Thinking in systems. How do the pieces fit together? Where are the bottlenecks? What happens when traffic 10x's? What's the upgrade path when requirements change?
Monitoring and observability. If I can't see what's happening in production, I'm flying blind. Setting up alerts, dashboards, and logging is less glamorous than shipping features but way more important at 3 AM when something breaks.
Building for the long term. It's easy to hack something together to solve today's problem. It's harder to build something that won't be a nightmare to maintain in six months. That's the senior mindset: not just "does it work?" but "will we regret this?"
Making judgment calls. Sometimes the right answer isn't obvious. Sometimes you have to trade off velocity against stability, or features against simplicity. Those calls are hard to delegate because they require context about the business, the users, and the codebase that takes time to build.
The meta-lesson
The real takeaway isn't about AI. It's about how you grow as an engineer.
At some point, getting better stops being about learning new frameworks or writing faster code. It starts being about seeing the bigger picture: understanding how software fits into a business, how decisions compound over time, and how to multiply your impact through other people (or, now, through AI).
I'm five years into my career. I've been heads-down in implementation for most of it. Managing an AI agent, even in a small side-project context, forced me into a different mode. It compressed lessons I might have taken years to learn organically.
If you're early in your career, pay attention to what the senior engineers around you are actually doing. It's not just writing code. It's asking better questions, catching problems before they ship, and thinking about systems instead of syntax.
And if you want to accelerate that learning? Try delegating. To a teammate, to an AI, to anyone. You'll learn more about engineering from reviewing code than from writing it.