The Job AI Can’t Apply For

There’s a question we engineers keep dancing around instead of answering directly:

If AI can write most of the code, why do we still need engineers?

The usual answers I’ve received so far, “engineers make decisions” , “humans are creative” and “AI is just a tool” are too vague to mean anything. Let’s take the question seriously instead.

Say I hand an AI a well-defined requirement and it produces the backend, the frontend, the schema, the tests, the deployment config. It compiles. The tests pass. Woohoo, The app works.

Then, what is the engineer doing now?

Not becoming more important in some abstract sense. Some engineering work is just getting cheaper. The valuable part is moving somewhere else.

And honestly, you can point to exactly where.

Someone has to own the failure

Press enter or click to view image in full size

A payment system processes $1 million in a day. Reconciliation comes back $30,000 short.

The AI wrote the payment service. It wrote the tests too. Everything passed.

Now someone has to trace the transaction lifecycle, read the queue and retry behavior, check the gateway responses, and figure out whether the money died in business logic, persistence, or integration. Nobody’s asking, “can you write a new method?” at this point. The hard part is understanding what actually happened inside a system that’s bigger than any single file.

This is where domain knowledge earns its keep. Someone who’s worked in payments knows that “payment received” doesn’t mean “payment settled.” There’s authorization, capture, retries, idempotency, settlement, and failure states in between. AI can generate code for every one of those concepts. But if you don’t understand them yourself, you might not even notice the generated implementation skipped one.

Domain knowledge doesn’t go away just because AI writes the code. It’s what helps you spot when something is wrong.

AI can see the code. You need to see the system behind it

Press enter or click to view image in full size

Point an AI at a repository, and it can understand a lot of it. But we all know production software is more complex than what’s sitting in the repository - undocumented dependencies, legacy services, historical workarounds, data that’s already quietly corrupted, races that fire once every few million requests.

Take something simple:

“Our customer import occasionally creates duplicate accounts”

The AI can inspect the API, inspect the database, and suggest a unique constraint. Reasonable-looking fix.

But maybe the real story is this: a customer record comes in from System A, lands on an SQS queue, and a consumer picks it up and writes it to the database. But before it acknowledges SQS, it times out. SQS never gets the acknowledgment, so it assumes the message wasn’t handled and delivers it again. The app creates the customer again.

The actual question was never “How do I stop duplicate inserts?” It was “What are this system’s delivery semantics, and is this operation idempotent?”

We all know that’s a distributed-systems question. Finding that question is the engineer’s job.

AI can implement queues, retries, caching, and transactions correctly. It just won’t tell you which one your problem actually needs.

AI slops in coding

Press enter or click to view image in full size

Ask for a five-minute cache on GetUserProfile(). A reasonable engineer writes six lines:

public async Task<UserProfile> GetUserProfile(Guid userId)
{
    var key = $"user:{userId}";

    if (_cache.TryGetValue(key, out UserProfile? cached))
        return cached!;

    var profile = await _repository.GetUserProfile(userId);
    _cache.Set(key, profile, TimeSpan.FromMinutes(5));

    return profile;
}

Ask an AI agent, and two minutes later you get a pull request with UserProfileCacheService, UserProfileCacheOptions, UserProfileCacheKeyFactory, cache metrics, a middleware, and 400 lines of tests.

Nothing in there is wrong, exactly. That’s what makes it dangerous, it looks professional.

The solution has just become disproportionate to the problem. And if you don’t understand caching well enough to notice, you might look at six new files and call it “more robust architecture” instead of six new things your team now has to maintain.

I think AI is an affirmation tool

Press enter or click to view image in full size

Say you ask an AI:

“Our dashboard is slow because it checks the user’s permissions on every request. Let’s cache the permission check for five minutes so it’s faster”

As you’d expect, it will write you a clean, well-tested caching layer. It won’t necessarily stop and ask what happens when an admin revokes someone’s access mid-session.

You framed this as a performance problem, so it will solve it as a performance problem. But now, if a user loses access, the five-minute permission cache could allow them to continue seeing and acting on data they’re no longer allowed to access.

You asked for the wrong fix, confidently, and it built the wrong fix, confidently.

A senior engineer in that conversation might push back:

“Wait, if we cache this, how quickly does a revoked user actually lose access”?

That instinct, matters. AI optimizes for what you asked, not necessarily what you actually need. If you tell it your approach is correct, it will generally help you build the correct-looking version of a wrong idea.

That’s the actual risk with AI-assisted engineering. Not that it writes bad code. It’s that it can confidently build exactly what you described, even when what you described was the mistake.

Code reviews are the new bottleneck, not typing

Press enter or click to view image in full size

Code review used to mean “does this look correct”. With AI in the loop, that question matters even more, because the volume has changed. An engineer who used to write 300 lines a day can now push 3,000. So in new era of engineering, the bottleneck isn’t producing code anymore, it’s verifying it.

The reviewer has to catch incorrect assumptions, unnecessary abstractions, race conditions, broken transaction boundaries, missing edge cases, retry storms, and code that’s internally consistent but conceptually wrong, which is probably the hardest kind to catch, because nothing about it looks broken.

Take this:

var users = await db.Users
    .Include(x => x.Orders)
    .Include(x => x.Addresses)
    .Include(x => x.Payments)
    .ToListAsync();

It works. Tests pass.

An engineer who understands Entity Framework asks: how many users, how many orders each, what SQL does this actually produce, and what happens when one customer has 100,000 orders?

Someone without that background just approves it.

AI made typing cheap. It didn’t make understanding cheap and that’s where engineers still matter.

Skill it, let AI fill it

Press enter or click to view image in full size

Say you’re building a feature that touches frontend, backend, and middleware, like adding a new payment method. The first time, you define the shape yourself: how the frontend calls the API, how the middleware validates and logs the request, and how the backend talks to the database. Once that pattern is solid, you turn it into a skill, a set of rules AI can follow.

Next time you need the same kind of feature, say, another payment method or a wallet provider, you just point the AI at that skill instead of explaining the architecture from scratch. It builds inside the shape you already defined, instead of reinventing the wheel.

That’s useful, but it doesn’t remove you as the engineer. If anything, it just boosts your productivity. Once the feature is scaffolded, you still have to add the business logic and verify it.

The time you saved on boilerplate is time you can spend somewhere it actually matters.

Knowing what not to build

Press enter or click to view image in full size

AI makes it very easy to say yes. Real-time notifications, a new Kafka pipeline, a separate service, a vector database, it can build all of it. The harder skill, and the one that’s getting more valuable rather than less, is being the person who says “no, we don’t need this”.

That answer saves infrastructure, maintenance and the debugging time of some future engineer who has to understand why it’s there. When building things gets cheap, building unnecessary things becomes the actual risk.

There’s a related version of this: two implementations can both work, one costs $500 a month and the other costs $20,000 at production scale, and the code can look equally reasonable side by side. A query that’s fine at ten thousand rows can be catastrophic at five hundred million. AI can write either implementation cleanly. Knowing which one holds up under your real traffic, that’s still your call.

Juniors

Press enter or click to view image in full size

Juniors traditionally learn by doing the simple stuff: CRUD, small bug fixes, basic API work. AI already does a lot of that. Which creates a real problem: if AI absorbs all the easy tasks, how does anyone build the judgment I’ve been talking about?

I don’t think the answer is “learn to prompt better.” It’s still the basics: learning the systems underneath: HTTP, databases, concurrency, frontend and backend concepts, coding principles, data structures, networking, authentication, failure modes in distributed systems because that’s what lets you use AI well instead of blindly.

AI lets you produce code before you understand it. The long-term cost is staying ignorant while shipping a lot of it.

You were never meant to be just a coder. You are the engineer

Press enter or click to view image in full size

Engineering used to run on knowledge plus the ability to turn that knowledge into working software. AI didn’t remove the knowledge requirement it removed much of the typing overhead, which means the amount of code someone can produce is no longer a useful measure of how good they are.

What’s left is understanding systems, understanding domains, making architectural calls, catching security gaps, debugging production, reviewing what AI actually generated, noticing unnecessary complexity before it ships, and knowing which requests are quietly asking for the wrong thing.

These are just the things on top of my mind. Engineering is huge. I mean, way, way more complicated than what we were led to believe. And coding was only a part of it.

AI attacks the cost of writing code. It does not touch the cost of being wrong. And because code is now cheaper to produce, it’s also cheaper to be wrong at scale, faster than anyone used to be able to manage.

The question was never “Can AI write this code?”

It’s “If AI writes this code, who knows whether it should exist, whether it’s actually correct, and what happens when it fails?”

That person is still an engineer.

That’s where the value went.

My 2 cents

I didn’t mean to discourage or motivate you, I meant to show you the real picture. This is coming from someone who uses AI for 90% of his work, not someone watching from the sidelines.

If you’re scared of AI, you’re in the wrong industry. This field was never meant to be stable, it never has been. Being an engineer has always meant being a student for life. That part hasn’t changed. It’s just what you’re studying that has.

Change is only constant

I started with basic coding, like everybody else. Then I thought DSA was the holy grail, master that, master everything. Turns out you’re nothing without UI. So I learned WPF for desktop apps. Then Blazor for web. Then a new UI framework replaces the one you just learned React for the community support, Angular because it wanted to own the whole stack. Then obviously I had to go full stack. Then networking concepts I never needed before suddenly mattered. Then the cloud showed up start with AWS, then switch to Azure, then borrow a few services from GCP because why not. Oh, and you need version control Git, sure but wait, we’re already on Azure, so let’s just use Azure DevOps. Then the next thing… then next..

And you know what I absolutely love my learning journey, I can’t wait to get up and learn more.

I hope this article brought a little clarity to the world we’re actually working in. If you’ve been feeling stuck, I hope it helped clear some of the air.

“Even if AI writes our code today, we must still read and understand it or we risk losing something precious: our capacity for logical thinking.”

— Rikam, a lifelong learner