A few months ago I caught myself doing something embarrassing. I spent hours building a feature without once deciding which model I was actually using. I just kept going—running prompts, watching token counts climb, then manually switching models once I noticed the usage. Claude for this chunk. Gemini for that one. By the end I had burned tokens across three different models without a clear reason for any of the switches.
When ChatGPT first became mainstream, one skill quickly dominated every conversation.
Prompt engineering.
The better your prompt, the better your answer.
For a while, that was enough.
But AI coding tools have changed significantly over the last couple of years.
Today we have:
- IDE integrations
- Coding agents
- Long-context models
- Planning modes
- Tool calling
- Multiple capable models competing on price, latency, and quality
As the tools have evolved, I've realized something.
The quality of my results is becoming less dependent on how I phrase a prompt and far more dependent on the engineering decisions I make before, during, and after the model generates code.
That's the motivation behind this new series.
Not to discuss prompt engineering.
But to explore what comes beyond it.
Software Engineering Has Always Been About Trade-offs
As engineers, we've always optimized systems.
We think about:
- CPU and memory usage
- Database performance
- Build times
- Cloud costs
- Network latency
- Maintainability
- Reliability
Every engineering decision is ultimately a trade-off.
AI coding introduces another resource to manage.
Not just API tokens.
Engineering time.
That's the resource I've become increasingly interested in protecting.
What Changed My Perspective
Over the last few months I've had the opportunity to work with multiple AI coding ecosystems.
At work, I primarily use LLM APIs for reasoning and coding.
Outside work, I've experimented with several open and commercial models including GLM-5.2, DeepSeek Flash, MiniMax, and others.
Going into those experiments, I expected model intelligence to dominate the outcome.
Instead, the biggest variable kept turning out to be workflow.
The same model produced noticeably different results depending on how I approached the problem.
That's a pattern worth paying attention to.
That realization was uncomfortable because it meant the bottleneck wasn't the model anymore—it was how I was working.
The same task could produce dramatically different outcomes depending on:
- How well I defined the problem.
- Whether I planned before asking for code.
- Whether I continued an unproductive conversation or started a fresh session.
- Whether I switched models when one became stuck.
- Whether I treated AI as a collaborator instead of an autocomplete engine.
None of those are prompt engineering decisions.
They're engineering decisions.
Better Models Don't Replace Better Thinking
One lesson keeps resurfacing.
A better model cannot compensate for poorly defined requirements.
Imagine asking an AI:
Build me a calculator.
Every model now has to make assumptions.
- Should it support decimals?
- Should it validate input?
- Should it handle division by zero?
- Is this a CLI application?
- A web application?
- Should there be unit tests?
Now compare that with a simple specification.
Build a calculator supporting addition, subtraction, multiplication, and division. Accept only numeric input. Prevent division by zero. Include unit tests.
The model didn't become smarter.
The engineering became clearer.
Prompt Engineering Isn't the Bottleneck Anymore
I still think prompt engineering matters.
But I no longer think it's where the biggest productivity gains come from.
The questions I ask today look very different from the ones I asked a year ago.
Instead of asking:
Which model is the best?
I find myself asking:
- Is this task difficult enough to justify a premium frontier model?
- Should I spend five minutes planning before asking AI to write code?
- Has the model become stuck?
- Would switching models save more time?
- Should I continue this conversation or start a fresh session?
- Am I saving API costs while wasting engineering time?
These questions have had a much bigger impact on my productivity than rewriting prompts ever did.
From Prompt Engineering to Engineering with AI
I've started thinking about AI-assisted development as another engineering discipline.
Not because AI is difficult.
But because it's becoming part of everyday software engineering.
We already optimize:
- Infrastructure
- Performance
- CI/CD
- Testing
- Observability
I've started thinking about AI as another engineering resource, alongside CPU, memory, cloud infrastructure, and developer time.
We already engineer those deliberately.
AI deserves the same discipline.
That means thinking about:
- Planning before implementation
- Choosing the right model for the task
- Managing context deliberately
- Knowing when to switch models
- Measuring whether AI is actually improving engineering throughput
Prompt engineering becomes just one small part of a much larger workflow.
What Engineering Beyond Prompts Actually Means
To me, "Engineering Beyond Prompts" means treating AI the way we treat every other engineering tool.
We don't optimize databases by writing better SQL alone—we think about schemas, indexing, caching, and observability.
In the same way, AI-assisted development isn't just about prompts. It's about planning, workflow, model selection, verification, and knowing when to change your approach.
The prompt is where the conversation starts. Engineering is everything around it.
What This Series Is About
One thing I've stopped doing is looking for the perfect AI model. That search never ends. There's always another release next week.
Instead, I've started investing in something that ages much better: learning how to become a better engineer while using AI.
Because that skill transfers regardless of which model happens to be leading the benchmarks.
This series isn't about finding the "best" model.
Every model represents a different balance of capability, latency, and cost.
As models improve, the balance keeps shifting. The engineering principles behind using these tools effectively are what remain useful longer.
To make that concrete, I've started framing AI usage around three questions:
Three engineering questions I ask before every session:
- Is the problem well defined? — If not, no model will save you.
- Is this the right model for the task? — Not the smartest. The right one for the cost, context, and latency you need.
- Is continuing cheaper than switching? — Sometimes starting fresh beats dragging a stuck conversation forward.
Those three questions have done more for my productivity than any amount of prompt tuning.
Over the coming articles, I'll be exploring topics like:
- Cost engineering for AI-assisted development
- Choosing the right model instead of the smartest model
- Planning before coding
- Knowing when to switch models
- Designing reliable AI-assisted engineering workflows
- Measuring productivity instead of benchmark scores
- I'll also share how I eventually redesigned my entire AI workflow after realizing the workflow mattered more than the model
Everything here comes from building software, experimenting with different tools, documenting what worked, and just as importantly, documenting what didn't.
If my opinions change as models evolve, I'll update them.
The engineering lessons are what I'm really interested in preserving.
Closing Thoughts
Prompt engineering helped us communicate with AI.
The next challenge is learning how to engineer with AI.
The future advantage won't come from knowing the perfect prompt.
It'll come from making consistently good engineering decisions while working with AI.