When AI Writes 99% of the Code, What Value Do Developers Have Left?

Over the past year, I’ve been rethinking how I evaluate technical talent.

This shift didn’t come from an article or an industry report. It came from our own team’s experience — as AI coding tools have grown increasingly capable, the value boundaries of many roles are being redrawn.

At first, I treated AI as just a support tool: help write code, look things up, organize documentation, explain errors. At that stage, it felt more like a smarter search engine.

But when Cursor’s Agent mode arrived, I could tell something had fundamentally changed.

From Ask to Agent: More Than a Productivity Boost

Around April 2025, I subscribed to Cursor. I’d been using AI tools before that, mostly through free trials and scattered experiments to solve specific problems. It never occurred to me that writing code would become the first domain where AI approached a near-perfect solution.

What made me realize the acceleration was real was the arrival of Agent mode.

From Ask mode, to Agent mode, to a future where you might not even need to Ask — you just provide goals, constraints, and judgment calls, while AI reads the code, modifies it, runs tests, and fixes errors on its own.

For the software industry, this isn’t a simple productivity improvement. It’s repositioning where technical people sit in the development chain.

Design and Frontend: The First to Feel It

In our team, design and frontend were the first roles to face disruption.

The old workflow: a designer creates mockups, a frontend engineer implements them, then everyone goes back and forth making adjustments. But once AI tools could rapidly generate page prototypes, layouts, and visual styles, that pipeline started to loosen.

Last year we tried to help our designer transition to new ways of working. It didn’t work out. Early this year, we eliminated the role entirely.

What surprised me was that after the change, the design gap we feared never materialized. Instead, colleagues from other roles started using AI tools themselves to build pages, adjust styles, and tweak interactions — and the results were solid.

That experience stuck with me.

It demonstrated something important: when tool capabilities become strong enough, a role that depends primarily on “knowing how to use a specialized tool” loses value quickly. What survives is aesthetic judgment, product understanding, and the ability to own outcomes.

After design, frontend was next in line for disruption.

Admin dashboards, forms, tables, detail views, configuration screens — these standard page types can now be generated by AI quickly. If a frontend engineer is only consuming APIs, building pages, and tweaking styles, their replaceability grows by the day.

So we’ve been encouraging our frontend engineers to move toward a more complete product development loop — not just building pages, but engaging with requirements, product design, data modeling, workflow analysis, and test risk assessment.

In that process, we uncovered two structural weaknesses.

Two Structural Gaps in Frontend Engineering

The first: many frontend engineers have a weak grasp of data structures and modeling.

This isn’t surprising. Frontend engineers have long worked with APIs that backend engineers already designed. They see what the interface returns, what the page displays, which endpoint gets called when a user clicks something.

But the genuinely hard parts of a system usually aren’t about how pages look. They’re about:

• What the core business objects are
• How those objects relate to each other
• How state transitions work
• Which data needs historical records
• Which operations require auditing
• Which exceptions must be handled
• Which workflows can’t be casually overwritten

None of that gets filled in automatically at the UI layer.

The second: many frontend engineers have a shallow understanding of the business, and often lack the habit of actively trying to understand it.

This one concerns me more.

Frontend work is the most visible part of a product — in theory, it should be closest to users and product thinking. In practice, many frontend engineers build the pages without genuinely understanding the business logic behind them.

For example, our team builds cloud migration and disaster recovery software. When we wanted frontend engineers to get involved in a new DR initiative, I found that their understanding of the existing product was thin. They knew what buttons were on the screen and what fields the API returned, but they didn’t necessarily understand:

• Why customers need to migrate, or why they need disaster recovery
• The fundamental difference between disaster recovery and backup
• What drills, takeovers, and failbacks each solve
• What RPO and RTO actually mean to a customer
• Which operations carry high risk for the customer

In other words, they worked every day on the visible parts of the product without truly understanding why those pages exist.

We also tried having them study competitor products — understanding how others approach similar problems, how pages are organized, how business logic is expressed. That was equally difficult for them. Partly a gap in technical depth, partly a lack of genuine motivation.

Many had settled into a rhythm: wait for requirements, wait for designs, wait for APIs, then implement the pages. Asking them to proactively research competitors, internalize business logic, deconstruct product decisions, and reverse-engineer data structures from user needs felt deeply uncomfortable.

That’s the core structural gap in frontend’s AI-era transition.

The old competitive advantage was being “closest to the user.” But if a frontend engineer is only close to the page — not to the business — that advantage evaporates once AI enters the picture.

Hiring Has to Change Too

These shifts have directly reshaped how we interview.

We used to give candidates coding problems: write something on the spot, see if it runs. But I’ve grown less confident in that approach — writing code is increasingly AI-assisted, and a candidate can use AI throughout and produce something that runs, without actually understanding the system.

So we switched to system design questions.

The problems themselves aren’t complicated. They’re typically scenarios with real business complexity — a billing system where price sources are inconsistent, rules are configurable, and historical data must be traceable. Candidates don’t need to implement anything on the spot. They just need to produce three things:

1. Data structures
2. Core workflow or sequence diagrams
3. Key test scenarios

What we’re really evaluating:

Business decomposition: Can they quickly identify the core objects in a business domain and their relationships? Can they take an ambiguous business description and translate it into clear data boundaries? Many candidates, when handed a problem, jump straight into schema design before they’ve clarified what the concepts even mean.

Modeling judgment: The decisions behind a data structure reveal a person’s engineering depth. Which fields need version history? Which states require auditing? Which relationships change over time? None of this requires code, but all of it requires genuinely understanding where a system will break down.

Edge case and failure awareness: An experienced engineer, during the design phase, will proactively think: what happens when an external dependency fails? How do you trace historical data after rules change? Should anomalous data enter the main workflow at all? These are the judgment calls AI can generate code around but can’t make for you.

Test priority instinct: The quality of the test scenarios someone names says more than the quantity. Can they pick out the truly critical risk paths from a range of possible scenarios?

There’s no single right answer to a design question. What we’re watching is the candidate’s thinking process: Do they define the problem before designing a solution? Does the data structure reflect business understanding? Do the test scenarios target real risk?

These capabilities can’t be outsourced to AI, and they can’t be faked.

A Candidate Who Made Me Think

Last week, a candidate with two or three years of experience seemed puzzled during our interview. He said our questions felt less like a developer interview and more like a product manager interview.

That reaction is telling.

Many developers have internalized a division of labor: the product manager owns requirements, backend owns APIs, frontend owns pages, QA owns validation. Everyone stays in their box. AI is breaking those boxes.

The candidate himself mentioned that AI now handles 99% of his coding work.

So I asked him directly:

If AI is doing 99% of the coding, what can you still do?

It’s a blunt question — but I think it’s one every technical person needs to answer honestly.

If your value is writing code, and coding is now mostly done by AI, what’s left?

Is it understanding requirements? Designing data structures? Assessing workflow risk? Identifying what matters in testing? Diagnosing production issues? Turning AI-generated output into reliable engineering results?

If none of those are your strengths, you’re in a genuinely precarious position.

AI Doesn’t Lift Everyone Equally

After a year of this, I’ve become more certain of one thing:

AI doesn’t raise everyone’s performance uniformly. AI amplifies the strong and packages the weak.

I think about technical people in three categories.

Type 1: The AI-Packaged Developer

These people never had strong analytical, design, or testing skills. They use AI to generate output and can’t reliably judge whether that output is good or bad.

With AI, their visible output increases — but so does their risk. Before AI, their limitations surfaced early because they couldn’t produce much. Now they can use AI to produce something that looks complete and runs, but problems get deferred to code review, testing, deployment, or worse — a customer’s production environment.

AI hasn’t amplified them. It’s packaged them.

What’s worse, some start shifting accountability: when making decisions, they treat AI as the authority; when things go wrong, they treat AI as the scapegoat.

“That’s what AI generated.” “I asked AI and it said it was fine.” “The test cases were AI-generated, so this edge case wasn’t covered.”

In an engineering organization, none of that holds up. AI can participate in the production process, but it cannot be the responsible party. The person who chose the approach, committed the code, merged the branch, and deployed the system owns the outcome. It’s the same as copy-pasting from Stack Overflow: the code doesn’t have to be original, but the person who uses it is responsible for it.

Type 2: The AI-Tooling Developer

These people use AI effectively and do see real productivity gains — writing code, researching topics, generating scripts, writing tests, organizing documentation. That’s all legitimate.

But I think they’ll gradually settle into competent execution roles. The gains AI gives them are mostly about completing their existing work faster, without meaningfully improving judgment quality.

Reliable for tasks, not for decisions. You can hand them work, but not judgment calls.

Type 3: The AI-Amplified Developer

These people came in with structured thinking, engineering judgment, and risk awareness. AI helps them expand, validate, and express that judgment faster.

They define the problem before touching AI. They give AI clear context, ask it to generate multiple options and compare them, actively challenge AI’s conclusions, translate AI output into their own judgment, know which steps require human verification, and close the loop on data structures, workflows, tests, logs, error handling, and deployment risk.

For these people, using AI improves both velocity and quality — because AI isn’t amplifying their typing speed. It’s amplifying their judgment system.

Technical Value Is Shifting from Implementation to Judgment

In the past, a technical person’s core value was implementation: writing code, building APIs, constructing pages, debugging, getting things done. These skills still matter — but they’re no longer sufficient.

In the AI era, what matters more is judgment: defining problems, designing data structures, mapping critical workflows, identifying failure boundaries, assessing test risk, evaluating whether AI output is trustworthy, and owning the results.

That’s why I find myself caring more about something that’s hard to quantify — what I’d call engineering taste.

And what I mean by engineering taste is, at its core, judgment.

Taste isn’t aesthetic preference or personal style. It’s a form of discernment: using first principles to understand what a customer actually needs, then expressing that understanding well — in a way that most people can recognize as right.

The first layer of taste is seeing through to the real need.

A customer says “I need this button.” But the real question is: why do they need it? In what situation will they use it? What do they expect to happen after? If it fails, what should they do next?

An engineer with taste doesn’t just satisfy the stated requirement. They work backward from the user’s situation: when should this system make a judgment for the user, when should it give the user enough information to decide for themselves, and when must it stop the user from making a mistake?

The second layer of taste is expressing that well.

This isn’t visual decoration. It’s the professional quality a system projects: error messages that tell users what happened, rather than “System error — contact your administrator”; empty states, loading states, and failure states all handled properly, rather than a blank screen; users who know what to do next after something fails, rather than being left confused; backend logs that support debugging, with trace IDs that let you trace any issue back to its source.

These aren’t accumulations of detail. They’re the physical form of taste.

The third layer, and the hardest, is being accepted by most people.

A design that only engineers can appreciate isn’t taste — it’s self-indulgence. Real taste means translating an insider’s judgment into a quality that non-experts can feel: users glance at it and think, “this seems solid.”

AI can generate the happy path reliably. It almost can’t replicate taste. Because taste isn’t a rule — it’s judgment. It requires engineers to genuinely inhabit the user’s situation, understand what they actually need, and make the right call.

That’s the real gap between seasoned engineers and ordinary executors.

A Final Thought

When I interview technical candidates now, I’ve stopped asking “do you use AI?” — that question doesn’t tell me much.

The question that matters is:

Has your judgment been amplified by working with AI?

If AI has only helped you complete your existing work faster, you’ve just become a faster version of where you were.

If AI has amplified your business understanding, structured thinking, engineering judgment, testing instincts, and risk awareness — then you have genuine, durable value in an AI-native organization.

So the question I now want to ask every candidate is:

After AI finishes writing the code, what can you still be responsible for in that system?