Over the past few years, I've spent a lot of time experimenting with AI-assisted development. Like many engineers, I initially thought the biggest value would come from AI writing code faster than I could.
I was wrong.
The real value comes from moving the engineer higher up the abstraction stack.
When I first became a GitHub Copilot Pro user, I approached it the same way I approach any engineering problem. I created detailed specification files, documented requirements, provided context, and tried to be explicit about desired outcomes. I spent a significant amount of time refining prompts and experimenting with different ways to communicate intent. GitHub Copilot accelerated implementation, but consistently getting the right result often required substantial iteration and human oversight.
For the better part of a year, I found myself spending almost as much time describing what I wanted as I would have spent building it myself.
The output was often technically correct but somehow missed the point.
It was a strange realization: the challenge wasn't getting AI to write code. The challenge was getting AI to understand the system I was trying to build.
Then I switched to Cursor.
The biggest difference was not the model. It was the workflow.
I adopted a simple approach:
Ask → Plan → Build → Verify
Instead of treating AI as an autocomplete tool, I started treating it like a junior engineering team. My job wasn't to write code anymore. My job was to define the problem, refine requirements, review designs, and validate outcomes.
Within my first month of using Cursor, I built more side projects, prototypes, and internal tools than I had during nearly a year of using Copilot.
That experience led me to a conclusion that feels almost obvious now:
Agentic coding is basically just system design.
The industry talks about agents as though they're a completely new skillset.
In practice, the skills that matter most are the same ones senior engineers and architects have used for decades:
- Understanding requirements
- Defining scope
- Designing workflows
- Identifying risks
- Establishing constraints
- Creating feedback loops
- Verifying outcomes
None of those involve typing code.
They involve understanding systems.
The AI handles implementation.
The engineer handles intent.
Ironically, one of the most important lessons I learned was that AI is often most useful before any coding begins.
Like many engineers, I don't always start with a complete set of requirements. Sometimes a stakeholder gives a rough idea. Sometimes I have a concept scribbled in a notebook. Sometimes I know there's a problem worth solving but haven't fully articulated the solution.
In those situations, I frequently use the free tiers of tools like Claude, Gemini, and whatever other AI happens to be available that week.
Not because I need them to generate code.
I need them to challenge my thinking.
I'll throw a vague idea at multiple models and ask questions like:
- What requirements am I missing?
- What edge cases should I consider?
- What would an MVP look like?
- What alternative approaches exist?
- What assumptions am I making?
The responses are often imperfect, sometimes wrong, but incredibly useful as thought partners.
It's similar to walking over to another engineer's desk and saying:
"This idea is still half-baked. Tell me what's wrong with it."
AI excels at helping transform fuzzy ideas into structured requirements.
Once I have those requirements, implementation becomes almost trivial.
This realization changed how I think about software development.
I enjoy designing systems...
I enjoy drawing architecture diagrams...
I enjoy figuring out how components interact...
I enjoy translating vague business needs into something concrete...
What I don't enjoy is creating the same form for the hundredth time.
Or another dashboard...
Or another CRUD screen...
Or another API wrapper...
Those tasks are necessary, but they're rarely where the real engineering value exists.
Historically, however, a huge portion of software development effort was consumed by exactly those activities.
Today, agents can handle much of that boilerplate.
The bottleneck is no longer coding speed.
The bottleneck is clarity of thought.
The challenge shifts from:
"How do I build this form?"
to
"What problem is this form solving?"
From:
"How do I implement this dashboard?"
to
"What decisions should this dashboard enable?"
The code becomes an implementation detail.
The design becomes the product.
That's why I believe AI is not reducing the importance of engineering fundamentals.
It's amplifying them.
The better you are at requirements analysis, architecture, system decomposition, and validation, the more leverage you gain from AI tools.
The more I use agentic workflows, the more convinced I become that "prompt engineering" is largely a temporary term.
What we're really doing is engineering systems.
The only difference is that some components are now AI agents instead of microservices, scripts, or human operators.
And just like every other component in a system, agents perform best when somebody has taken the time to design the architecture properly.
The more I use AI tools, the more convinced I become that the future isn't about becoming a better prompt engineer.
It's about becoming a better systems engineer.
Because at the end of the day, an AI agent is just another component in your architecture.
And like every other component, it performs best when somebody has designed the system well.
The only question I haven't figured out yet is this: how do junior engineers learn system design when the traditional junior-to-senior apprenticeship pipeline is slowly disappearing?
But that's a story for another post...
