Everyone is talking about how AI is helping junior developers write code they couldn't write before. That's true. But there's a less-told story: what happens when a senior developer picks up these tools. The leverage is completely different — and I didn't fully understand that until I was six months deep into it.
Here's how my working relationship with AI actually evolved, from tentative experiments to the workflow I rely on today.
Stage 1: Testing the Water with Copilot
I started where most developers start: GitHub Copilot inside VSCode, some time in 2025. I wasn't asking it to build features. I was using it for the mundane layer of senior work that nobody talks about — summary reports, technical emails that needed the right tone, quick estimations for sprint planning.
It was useful enough that I got curious. I started intentionally switching models to understand the differences: GPT-4, Claude Sonnet, Gemini X Pro, Kimi2.5, Minimax. Each had a different character. Some were better at structured reasoning, some at generating clean code, some at explaining tradeoffs. I started to develop a mental model of which tool for which job — not because any article told me to, but because I was running informal experiments every day.
At this point, AI was a productivity multiplier for things I already knew how to do. Useful, but not transformative yet.
Stage 2: The Planner/Worker Experiment
In January 2026, I started the Live Dubbing for Holoscan project — building a real-time speech-to-speech pipeline using NVIDIA's Holoscan SDK, a framework I had never touched before. The technical depth was significant: ASR models, translation, TTS, low-latency streaming, unfamiliar APIs.
I tried something I hadn't done before: using two AI systems with different roles simultaneously.
Gemini 2.5 Pro as the Planner. I used it for research, architecture decisions, and understanding unfamiliar territory. Give it a problem, get a structured breakdown of the approach.
GitHub Copilot + Claude Sonnet as the Worker. The implementation layer. Once I knew what to build and why, Copilot handled the implementation details inside the IDE.
This separation mattered more than I expected. The Planner role required broad context, reasoning across documents, and understanding why — things that benefit from a model with a large context window and strong reasoning. The Worker role required precision and staying in the flow of actual code. Using the same model for both is like asking the architect to also lay the bricks.
Stage 3: The Realization That Changed How I Think About This
When I got access to Claude and started using Cowork and Claude Code together, something clicked that I want to be direct about.
I work in Python on our production services. My honest Python level is junior-to-intermediate. I can read it, I understand what's happening, I can debug it — but I wouldn't have claimed the ability to build a production-grade FastAPI service with GPU-accelerated audio processing from scratch, not at the speed a project requires.
And yet: I did. The code shipped. It works in production. It handles real users.
Here's why: AI doesn't know what good architecture looks like. I do.
A junior developer using AI will generate code that works. A senior developer using AI will generate code that works and is structured correctly, handles edge cases, scales appropriately, and fits into a larger system that doesn't collapse six months later. The AI writes the lines. The experience decides what lines to write, in what order, with what constraints.
The gap between a junior and a senior developer was never just about knowing syntax. It was about judgment — knowing which problems are actually hard, which abstractions hold under load, which shortcuts will cost you later. AI doesn't shrink that gap. It amplifies whatever judgment you already have.
Stage 4: The Current Workflow
Today my working process looks like this:
Research and planning with AI first. Before I write a ticket or start a branch, I use Claude to think through the problem. I describe what I'm building, the constraints, the existing architecture. The output is a structured approach I can actually defend in a planning meeting.
Plans become visible artifacts. I take what comes out of the planning session and push it into Jira and GitHub Projects. This is important — the plan isn't just in my head or in a chat window, it lives where the team can see it, comment on it, and hold me accountable to it.
Automation removes the reporting overhead. I use n8n to automate my daily work updates. My manager gets a status report generated from what actually happened in Jira and GitHub — no manually written updates, no "what did you do this week" scrambles. This wasn't a complex implementation, but it saves me real time every week and makes my work more visible without extra effort.
MCP servers connect the tools. The part that's hardest to explain to someone who hasn't tried it: when your AI assistant can directly query your project management system, read your GitHub PRs, and execute workflows — instead of you copying and pasting between systems — the overhead drops significantly. I have MCP connections to GitHub, Jira, and n8n, and the difference in how fluid the work feels is real.
What I'd Tell Someone Starting This Journey
Don't start with "how do I use AI to write code faster." Start with "what do I actually spend time on that isn't the interesting part of my job?"
For me that was: writing status updates, translating architecture decisions into tickets, filling gaps in languages I'm not expert in, and researching unfamiliar APIs. AI is extraordinarily good at all of those things.
The interesting part of the job — deciding what to build, why, how it fits the system, what will break under load — that part still requires you. The tools just clear enough of the other noise that you can focus on it.
I started this with GitHub Copilot and some curiosity. A year later, I'm building things I couldn't have built at the same speed or with the same quality before. Not because AI replaced my judgment — because it finally gave my judgment enough room to do its job.
Top comments (0)