Or: How I Learned to Stop Worrying and Become a Very Expensive Prompt Engineer

The Hype Arrives at Your Door

I resisted longer than most. While half of LinkedIn was busy posting “10 prompts that made me 10x more productive”, I was doing the sensible thing: ignoring them and writing code like a normal human being. Then, less than a year ago, I tried Cursor.

Within the first hour, I understood the appeal. Boilerplate that would have taken me twenty minutes appeared in seconds. A stubborn bug I was staring at got diagnosed before I finished explaining it. This was not a chatbot. This was something that actually read my code, understood the context, and suggested things that made sense.

I also, within that same first hour, understood the danger. Because the moment I leaned back and said “go ahead, do the whole thing” — something shifted. The code that came back worked. It compiled. It ran. But it was a stranger’s code. It ignored the patterns we had established, reinvented utilities that already existed three files away, and applied the kind of enthusiastic over-engineering that you usually only see from someone who just discovered design patterns and wants you to know about it.

One more observation surfaced immediately: the AI was noticeably better at frontend work than backend logic. Ask it to build a UI from an API spec and it will delight you. Ask it to reason about distributed state, race conditions, or why your WebSocket connection drops under load — and the confidence remains, but the correctness does not. More on that shortly.

Vibe Coding: Lost in Translation

“Vibe coding” is one of those terms that has been used so many times by so many people that it no longer means anything specific. For some, it means using AI as an intelligent autocomplete — you drive, it helps. For others, it apparently means typing a vague prompt, walking away, and coming back to find a finished application waiting for you like a golden retriever with your slippers.

The first approach is powerful. The second is utopian.

Yes, if you give an AI enough prompts and enough patience, it will eventually produce something that runs. What it will not automatically produce is something production-ready. “It works on my machine” has always been a warning sign. “It works because the AI said so” is a whole new level of optimism.

Production readiness is not just about the happy path. It is about error handling, observability, security boundaries, and the twelve things that can go wrong at 3am that nobody thought to put in the prompt. Vibe coding as a discipline — AI-enhanced development, not AI-replaced development — is a legitimate shift in how we work. The other kind is a great way to build a demo that will haunt you in six months.

Where It Genuinely Shines

Let me be fair, because these tools deserve credit where they have earned it.

The clearest wins follow a pattern: the better you can define the problem, the better the output. When the input is structured and unambiguous, the results can be impressive enough to make you feel slightly redundant.

Building a UI from an existing API spec is a near-perfect use case. The contract is defined, the shapes are known, and the AI scaffolds, wires, and styles faster than you can open a new component file. Similarly, cross-language performance testing — taking existing Python business logic and asking the AI to write equivalent Go or Rust for benchmarking — works well. The logic is already expressed. It just needs translating, and translation is something these tools handle with confidence.

The use case that impressed me most was infrastructure as code. While building a remote patient monitoring system — a real-time platform processing data from patient devices through IoT Core, routing it through SQS and SNS, serving a frontend via WebSocket connections and a REST API with a BFF layer, all running on Lambda with PostgreSQL behind an RDS Proxy — I wrote the business logic. The Lambda handlers, the domain models, the data processing. Then I described the architecture to the AI and asked it to write the CDK stack.

Five hundred and twenty lines of infrastructure code came back. VPC configuration, security groups, IAM roles with least-privilege policies, API Gateway setup, Cognito authentication, IoT Core rules, EventBridge schedules. Not perfect on the first pass, but correct enough that the gap between what it produced and what I needed was small. The alternative was days of AWS documentation archaeology. This was hours.

Documentation is the other unsung hero. Technical docs, customer-facing guides, README files that people will actually read — AI handles all of this well. Partly because documentation is a domain where “sounds right” and “is right” overlap more often than they do in code.

Where It Will Absolutely Betray You

Here is where we need to have an honest conversation.

The same AI that correctly wired up your IoT Core rules to your SQS queue has no idea that the batching pattern it just invented for your new notification type already exists, fully implemented, three modules away. It does not know your codebase. It knows the files you showed it. Everything else is a blind spot, and it will fill that blind spot with new code rather than admitting ignorance. I have watched AI tools reinvent utilities, re-implement helper functions, duplicate constants, and create parallel implementations of things that had perfectly good existing versions — all with the serene confidence of someone who has never heard of the git grep command.

But the story that best illustrates the deeper problem is this: a colleague deleted a single line from a GitLab CI pipeline. One line. It was the line that set the working directory before running a deployment command. The command failed with an error about missing resources. Simple enough.

The AI did not think so. It redesigned the pipeline. It changed commands. It restructured stages. It rewrote environment variable handling. It was like watching someone respond to a missing shirt button by rebuilding the entire wardrobe. After several rounds of increasingly creative suggestions, I stepped in, asked it to check the recent git diff on that specific file, and it immediately found the missing line.

The lesson is not that the AI was stupid. The lesson is that it does not think simply. It does not ask “what changed recently?” before it asks “how do I solve this comprehensively?” It does not factor in human interventions — a deleted line, a config someone changed by hand, an environment variable someone set manually last Tuesday. The context of what happened before it arrived is invisible to it, and it will construct elaborate explanations rather than ask obvious questions.

In a system where a misrouted alert means a patient does not get notified about a critical reading, “elaborate but wrong” is not an acceptable failure mode.

The Skill Floor Problem

There is a cognitive trap I have started calling the working bias, and it is more dangerous than any specific bug an AI can produce.

It works like this. You are frustrated. You have been staring at the same problem for an hour. You hand it to the AI, and the AI fixes it. The feature works. You feel relief. And in that moment of relief, your brain — the same brain that has been reviewing code for years — quietly switches off its critical evaluation mode. The thing works. We can move on.

The problem is that “the thing works” and “the fix is correct” are different statements. The AI may have patched a symptom. It may have introduced a subtle regression. It may have solved the immediate problem in a way that creates a harder one downstream. But you are no longer looking carefully, because the frustration is gone and the tests are green.

This trap is dangerous for experienced engineers. For junior developers, it operates on a different level entirely.

Mr. Miyagi did not hand Daniel a black belt on day one and say “figure it out.” There was a reason for wax on, wax off. The fundamentals were not a formality — they were the foundation that lets you recognise when something is wrong. A junior developer using AI tools full-throttle is Daniel trying the crane kick without the wax on. It might look like it’s working, right up until it doesn’t. A junior engineer using AI tools does not just inherit the AI’s code — they inherit the AI’s blind spots. They may not have the system knowledge to recognise that the new implementation conflicts with an existing pattern. They may not see that the error handling is optimistic. They do not yet have the years of 3am incidents that teach you what “this looks fine” can cost you.

The AI does not have full context of your system. The junior developer often does not either. Two incomplete maps do not add up to one complete map. They add up to confident navigation in the wrong direction.

So, Will It Take Your Job?

No. But the honest answer is more uncomfortable than a simple no.

In the short term, some roles will contract. Companies will hire fewer people to do the same volume of work, and some of them will be right to do so. In the medium term, expect a correction — not because AI will stop improving, but because the accumulated technical debt of AI-generated code that nobody fully understood will eventually need humans with deep system knowledge to untangle it. Senior engineers who understand distributed systems, who have seen failure modes, who know what the codebase was supposed to do — they will be expensive and necessary. The Terminator said “I’ll be back.” So will the greybeards.

What will change more dramatically than headcount is expectations. If AI makes a good engineer twice as productive, the market will not respond by hiring half as many engineers at the same salary. It will respond by expecting twice the output. The benchmark for a normal delivery will shift upward, and anyone not using these tools will fall behind the new baseline. Fast.

The more interesting prediction is what happens to the role itself. The competency that will matter most in ten years is not fluency in any particular language or framework — it is system design, architecture, and the ability to translate a complex problem into a precise, well-structured prompt. People will study how systems work, how components interact, how failure propagates. Then they will use that knowledge to describe problems clearly enough for AI to solve them correctly. The AI may even select the language and the framework. Knowing Python or Go may matter less than knowing why you would choose one over the other — and being right about it.

And one more thing that nobody seems to be discussing, because everyone is still in the honeymoon phase: enjoy the current pricing while it lasts. The same playbook that built Netflix and YouTube Premium is running right now. Get people dependent, make switching painful, then adjust the numbers. The AI tools that feel indispensable today are free or cheap because the goal is adoption. Once the adoption is locked in, the prices will find their natural level. We have seen this film before. We know how it ends.

The tool is real. The productivity gains are real. The risks are real. And the bill is coming.

Use it. Understand what it does. Keep your hand on the wheel.

Or, to borrow from a 1983 film about a computer that nearly started a nuclear war: the only winning move is not to stop playing — it is to never let the machine play alone.

Between Systems is a blog about distributed systems, software architecture, and the gap between how we think software works and how it actually behaves at 3am.