Agentic development has improved massively in the last six months. In the summer of 2025, I tried using Copilot to build a moderately complex feature. At the time, I was genuinely amazed by what it could do — but in practice it got more wrong than right. I spent too much time correcting and reworking the output, and overall the experiment felt like a failure.

Over the Christmas holidays, I tried the same approach again — same type of feature, similar expectations — and the difference was night and day. This time, Copilot delivered over 90% of what I wanted straight out of the gate, and in several places it exceeded my expectations. Just as importantly, it did this quickly.

Importantly, the way I worked with the tools didn’t really change. In the summer experiment, I also provided a clear scope, explicit guidelines, and sensible guardrails. What changed was the capability of the models themselves.

The same instructions that previously produced something brittle and error-prone now resulted in output that was accurate, well-structured, and required far less intervention. The improvement wasn’t incremental — it was material. That experience really drove home how fast this space is moving.

This isn’t something coming “in the next few years”. It’s here now. The way we build software has already changed.

The role of the engineer is shifting away from manually assembling every piece, line by line. Increasingly, we are becoming orchestrators — defining intent, setting constraints, reviewing outcomes, and steering systems toward the right result rather than implementing every detail ourselves.

That doesn’t mean engineering skill matters less. If anything, it matters more. Knowing what to build, how to structure it, and where the sharp edges are is what allows these tools to be effective. Without that context, agentic systems produce noise. With it, they produce leverage.

The engineers who thrive in this world won’t be the ones who type the fastest — they’ll be the ones who can reason clearly, communicate intent precisely, and design systems that guide autonomous tools toward good outcomes.

That’s the question on everyone’s lips. And if we’re being honest, the answer is probably yes — at some point.

But for now, that question is largely a distraction. The more useful framing is: how do I use this to do more, without compromising quality? For myself, my team, and the business.

As the orchestrator, you’re still very much in the loop. You need to know how to use these tools, what context to give them, what constraints to apply, and — critically — how to validate the output. None of that goes away. In fact, it becomes the job.

One thing that’s been key for me is using LLMs to help plan and map out larger pieces of work, but then deliberately breaking the implementation down into small, well-scoped chunks. For each step, I ask the model not just to implement, but to explain why it’s doing what it’s doing.

There’s also real value in simply watching the model work. Seeing how it reasons through a problem, identifies trade-offs, navigates edge cases, and then implements a solution is fascinating — and genuinely educational. Used this way, it’s not just a productivity tool, it’s a force multiplier for learning and understanding.

There’s a lot of noise right now around which LLM to use, which tools are best, and which IDE you should be running. In my experience, that largely doesn’t matter.

What matters is how you approach the capability, not the specific interface. Whether you’re using a command-line tool, an IDE integration, a desktop app, or a web UI, the underlying shift is the same. The real leverage comes from learning how to frame problems well, provide the right context, set clear constraints, and iterate effectively on the output.

Obsessing over picking the “right” tool often just adds anxiety and slows adoption. It’s far better to remove that friction, pick something accessible, and start using it. The learning comes from doing, not from endlessly comparing options.

It’s clear that AI will have a significant impact on software engineering, just as it will across many other cognitive professions. Further down the line, we’ll likely see similar disruption in more manual roles as robotics continues to advance.

But staring too far into that future isn’t particularly helpful. What is useful is embracing what’s already here, right now. Understanding how these tools can help you work more effectively, help your team move faster without sacrificing quality, and help your business do more with the same people.

This shift is happening whether we like it or not. The opportunity is in leaning into it early, learning how to use it well, and turning it into a genuine advantage rather than something to fear.