Watching some people “use AI at work” has convinced me of one thing:
AI is not replacing competent developers any time soon.
But it is doing a fantastic job of exposing who didn’t really know what they were doing in the first place.
You’ve probably seen this pattern already:
- 50 prompts.
- 20 rewrites.
- Endless “make it more robust / more scalable / more production-ready” messages.
- Zero understanding of what’s actually happening.
Meanwhile, a real developer could have:
- understood the problem,
- written a small, clear solution,
- and finished in one or two focused passes.
Prompt engineering doesn’t magically turn non-technical people into builders. It mostly turns their confusion into very expensive text.
The Claude Credit Summary That Made Me Feel Weirdly Safe
Everyone talks about AI as an existential threat.
Then you open your team’s or company’s usage dashboard and see something like:
- thousands of credits burned on trivial tasks,
- long chat sessions where the same vague question is rephrased 20 times,
- reports and docs generated, then manually rewritten for hours.
You realize:
The people most excited about “prompt engineering” are often the ones who never learned how to think like engineers.
Real examples companies are already sharing:
- managers spending hours correcting AI-generated reports that “took 5 minutes,” creating what some call prompt engineering debt—a new layer of work on top of already busy jobs;
- no-code builders burning hundreds of credits a day because they keep asking vague questions instead of clarifying requirements or reading basic docs;
- teams running complex tasks on the most expensive models when cheaper ones (or a quick human fix) would have done the job.
Meanwhile, controlled studies keep saying the same thing:
- AI coding assistants give big gains in some contexts,
- and outright slow developers down in others—especially when tasks are small or the codebase is well understood.
If you need 30 prompts to get what a competent dev would produce in one shot, the problem isn’t that you need ‘better prompting techniques.’ The problem is you don’t know what you’re asking for.
“Prompt Engineering” vs Actual Engineering
Prompt engineering was briefly sold as a new job category:
- no code,
- no math,
- no systems thinking,
- just “talk well to the model.”
Companies are already walking that back.
The emerging consensus:
- “prompt engineer” as a standalone role is fading;
what’s valuable now are people who understand systems, data, constraints, and verification—and happen to use AI well.
In other words:
AI skills are a multiplier on real expertise,
not a replacement for the expertise.
The difference in practice:
A non-technical “prompt engineer” burns tokens asking the model to invent APIs, architectures, and glue code from scratch.
- A real developer feeds the model context, constraints, and code, then uses it to refactor, scaffold, or check specific parts.
Prompt engineering without domain knowledge is just creative ways to waste money faster.
The Hidden Inefficiency: Prompt Engineering Debt
People talk about technical debt.
We’re now accumulating prompt engineering debt:
- AI-generated docs that sound authoritative but are subtly wrong,
- half-baked scripts or UIs that “mostly work” but hide security or performance issues,
- workflows no one can reproduce because the steps lived entirely inside chat logs.
You save 10 minutes by letting AI draft something.
You lose:
- hours verifying, correcting, and reformatting,
- more hours when future you or someone else has to figure out “how this was made,”
- trust, when stakeholders discover the tool hallucinated key details.
Managers and non-technical leaders are already reporting:
- AI “helped” them finish something fast,
- but they then spent several hours fixing it,
- net result: more tired, not more productive.
This is the real cost nobody includes in their “AI saved me X hours!” posts.
AI doesn’t just create output. It creates obligations: to verify, to correct, to own the result. Prompt debt is still debt.
Watching a Prompt Power User Struggle With a Two-Minute Bug
The most painful demos of “AI superusers” often look like this:
- They hit a bug or small logic issue.
- Instead of reading the code or error message, they:
- paste everything into Claude or another model,
- ask it to “fix the problem,”
- get a large diff,
- apply it blindly,
- break something else.
Repeat.
If you’re an actual developer, you know what a normal path looks like:
- read the error,
- follow the stack trace,
- inspect inputs and outputs,
- change one or two lines,
- add a test if needed.
Two minutes.
The “prompt engineer” route:
- 20+ minutes and 100+ credits,
- three or four different attempts,
- unsatisfying sense that “it works now but not sure why.”
This is not AI’s fault.
This is what happens when someone:
- doesn’t understand the system,
- doesn’t trust themselves to reason about it,
- and thinks more prompting is always the answer.
If AI is your first reflex for every tiny issue, you’re not a power user. You’re outsourcing your thinking.
Being an AI Superuser Is Not the Same as Being a Developer
There is such a thing as an AI power user.
They look nothing like the people throwing 400-line prompts at every problem.
Real power users:
- have solid fundamentals in at least one domain (dev, data, ops, product),
- use AI to compress workflows they already understand,
- treat models as tools in a chain, not as all-knowing oracles.
They:
- script repeated tasks,
- integrate AI into editors, terminals, and CI pipelines,
- design small, reliable loops where the model does the mechanical parts.
They do not:
- spend all day rewriting the same vague prompt,
- rely on AI to invent systems they don’t understand,
- brag about number of tokens used as if that were a productivity metric.
Being good with AI is not about ‘talking to it a lot.’ It’s about knowing enough to ask for the right thing once.
The Ego Layer: Prompt Engineering as a Mask for Insecurity
Here’s the uncomfortable part:
For some people, “prompt engineering” is a socially acceptable way to hide insecurity.
Instead of saying:
- “I don’t understand this system,”
- “I need to learn the basics,”
- “I’m out of my depth,”
they say:
- “I’m working on AI workflows,”
- “I’m refining the prompt,”
- “The model just needs better instructions.”
It sounds sophisticated.
It keeps them in the conversation.
It lets them avoid asking the “stupid questions” they really need to ask.
But underneath that layer of AI jargon, nothing changes:
- no better mental models,
- no better debugging skills,
- no better understanding of trade-offs.
Prompt engineering becomes a costume you wear so people don’t see that you’re scared to admit what you don’t know.
How Skilled Developers Actually Use AI (and Why That’s Threat-Proof)
Most senior devs who integrate AI deeply share the same pattern:
They use AI to:
- accelerate things they already know how to do,
- generate first drafts they fully understand and can rewrite,
- explore alternatives or edge cases they might have missed.
They don’t:
- let AI design the architecture of a system they don’t understand,
- push AI-generated changes without reading them carefully,
- use AI as a shield from having to think.
Studies and field reports show:
- AI assistants give big boosts when engineers know their stack and use AI as an exoskeleton;
- in unfamiliar systems or without clear specs, they can slow things down or create new failure modes.
The job that’s safest long-term is still:
- understanding systems,
- making decisions under uncertainty,
- reviewing and owning the output—human or AI-generated.
The thing that keeps you safe is not how many prompts you can write. It’s how many decisions you can own.
If You’re Technical: Why This Whole Trend Should Calm You Down
If you’re a real engineer worried about AI replacing you, look carefully at how most “prompt superusers” actually work today.
You’ll see:
- a lot of noise,
- a lot of wasted tokens,
- a lot of shallow output,
- and a lot of work created for the people who still have to be accountable.
The market is already correcting:
- the hype around “prompt engineer” as a standalone role is fading;
- companies are hiring for AI + X (engineering, data, product, security), not for “AI whisperers”;
- senior developer roles are shifting toward more design, review, integration, and governance—not away from them.
AI will absolutely replace:
- a chunk of low-skill work,
- some tasks that used to justify junior roles,
- a lot of fake productivity.
It will not replace:
- clear thinking,
- system-level understanding,
- the ability to define what “good” looks like in the first place.
Your job is not to compete with people burning credits. Your job is to be the person who knows what should happen before anyone opens a chat window.
I fix the Angular apps that generalists break.
I’m Karol Modelski, senior Angular developer and frontend architect rescuing legacy B2B SaaS frontends.
If your Angular app is slowing your team down, start with a 3‑minute teardown of your current setup: https://www.karol-modelski.scale-sail.io/
