What remains of the frontend developer when AI writes the code?

Developer update, autumn 2026: How AI has changed my work

In February, I wrote here that the autopilot won’t take over the cockpit. My thesis back then: the role of developers is changing. Less typing, more reviewing, more communication and more decision-making.

Eight months later, I still stand by that thesis in principle. But I have to admit: the shift has happened faster and gone further than I put it at the time. Above all, the question of which work actually takes up most of my time has changed. Time for an update.

What I underestimated in February

Back then, I wrote that AI supports us with rapid prototyping, boilerplate and research. In hindsight, that was too cautious.

Today, AI handles a large part of the actual implementation in our day-to-day work at IDENTIC. Not just individual lines of code or recurring components, but increasingly complete features and coherent changes across multiple parts of a codebase. That doesn’t mean every task automatically becomes faster or better. But it does mean that the focus of my work has shifted significantly.

To make this tangible, it helps to take a simplified look at the classic development process. Roughly speaking, we had three big blocks:

Specs → Implementation → Testing

Implementation often took up most of the time: building components, implementing layouts, wiring up state, connecting interfaces and handling edge cases.

Today, my chain increasingly looks different:

Context Engineering → Specification → Generation → Testing → Verification

Implementation hasn’t disappeared. It is just increasingly becoming a task I can delegate to AI. In return, the steps before and after it are becoming more important. And that, for me, is where the real change lies.

The flight plan is becoming more important

In my last article, I described what pilots do while the autopilot is flying: monitor, communicate and take responsibility. What I left out back then is the part before take-off.

Before an autopilot can fly at all, it needs a flight plan. A route, waypoints, altitudes, constraints and, where necessary, alternatives. An autopilot can fly a route precisely. But that doesn’t mean the route makes sense.

This is where I see one of the most important changes in AI-assisted software development. The question is no longer just:

How do I implement this feature?

But increasingly:

What information, rules and tools does the AI need to implement this feature correctly in our system?

This kind of work now has a name.

From prompting to context engineering

In February, I still recommended good prompting as an important skill. Today, I would put it differently. Prompting remains relevant. But a good prompt is only a small part of what an AI agent needs for a complex task.

The term context engineering describes the broader work: providing the right context for each next step. In 2025, Andrej Karpathy described the term as filling the context window with just the right information for the next step. Since then, the term has increasingly been used to describe exactly this more systematic way of working with LLMs.

In our day-to-day work at IDENTIC, this means, for example:

• understanding architectural decisions and existing patterns
• documenting a codebase’s conventions and anti-patterns
• sharpening acceptance criteria and project rules
• providing relevant files and dependencies in a targeted way
• making tools, feedback loops and testing options accessible

We have developed our own workflows for this, in which planning a new feature only begins once the relevant patterns and structures of the codebase have been captured.

At first, that sounds like extra documentation. In practice, though, it makes a decisive difference: between an AI that produces some working solution and an agent that develops a solution that fits our existing system.

Context engineering is therefore not simply the art of writing better prompts. It is the design of the working environment in which AI develops software.

When implementation gets cheaper, architecture matters more

This leads to a consequence that wasn’t on my radar in February:

When the cost of implementation falls, the relative value of architecture rises.

Today, an agent can build a new API route relatively quickly. The harder question is: Should this API route exist in this form at all?

It can create a database structure. Does the data model make sense?

It can build a React component. Is this the right abstraction?

It can change an existing function across five files. Is this really the architecture we want in the long run?

In the past, a developer had to spend a large part of their time implementing a decision technically. Today, the technical implementation can sometimes be done within a few minutes. That doesn’t make the decision itself any less important. Quite the opposite.

If a wrong implementation used to cost half a day and now costs ten minutes, making mistakes becomes cheaper. But that doesn’t make it any cheaper to drag the wrong architecture along for months.

This also changes the role of code reviews. We need to worry less about whether every single developer masters the same implementation technique. Instead, we need to better understand whether the solution fits the system.

Specification is becoming the new bottleneck

The same thing happens one level up. As implementing a feature gets faster and faster, an unclear specification becomes a relatively bigger problem.

What exactly does “done” mean? Which user group is at the centre? What happens when something goes wrong? Which edge cases are relevant? What constraints are there? Which solution is actually wanted?

When implementation becomes cheap, quickly implementing in the wrong direction suddenly becomes especially expensive.

That’s why I believe good specification needs to be understood as an engineering task again. Not in the sense of long documents that nobody reads, but as a precise description of what should be achieved, why it should be achieved and how we will know it has been achieved.

Incidentally, this is also one of the reasons why I don’t simply see the development of AI agents as “better autocomplete”. Autocomplete waits for a specific line of code. An agent needs context, a goal, rules, tools and feedback. The more autonomous these systems become, the more important the quality of that environment becomes.

Design systems are becoming context for AI

The same principle applies to design. When AI generates interfaces, it can create components and layouts incredibly quickly. Without sufficient context, however, inconsistent solutions quickly emerge: different button variants, inconsistent spacing, new components for problems that have already been solved, or simply interfaces that work but don’t look like your own brand.

Design systems can play an important role here. They don’t just provide colours, spacing and typography. They describe reusable components, rules and shared design decisions.

Figma itself now describes exactly this development: design systems are increasingly understood as the context AI agents need to generate consistent, on-brand code. The Figma MCP server can bring components, variables and layout information, among other things, from Figma into agentic development workflows. That’s an important step.

But a design system alone doesn’t solve the problem. An interface can use all the right components and still feel completely wrong. An agent doesn’t just need to know which button to use. It needs to understand which hierarchy, density, interaction logic and brand character are intended. For me, this is exactly where frontend development and design meet.

And the way these systems are created is changing, too. AI can already help develop tokens, components and initial rules. Figma, for example, describes workflows in which AI derives structured design system rules from existing code. The work is thus shifting in part from manually creating every single variant to defining the principles from which a consistent system should emerge.

That doesn’t mean design is becoming less important. When creating interfaces gets cheaper, good design becomes more important, if anything. Because when anyone can generate a working interface in a few minutes, the quality of the decisions is what makes the difference.

Testing is becoming more automatable. Verification isn’t.

Another change concerns the end of the process. In February, I recommended reviewing AI-generated code line by line. That recommendation still makes sense for learners, critical changes and many specific situations. In everyday work, however, it doesn’t scale indefinitely when an agent produces large amounts of code in a short time.

For me, the answer isn’t less control, but a different form of control. Testing can increasingly be automated: unit tests, end-to-end tests, visual regression tests and agentic browser checks. But a passing test doesn’t answer every relevant question.

That’s why I distinguish between testing and verification.

Testing asks: Does it work according to the defined checks?

Verification asks: Is it the right thing?

Does the interaction fit the brand? Is the flow understandable for real people? Is the visual hierarchy coherent? Is the page accessible and usable under real-world conditions?

An automated check can find important errors. But it doesn’t automatically replace an understanding of the product’s intent. Human sign-off doesn’t become redundant. It changes.

We no longer necessarily check every line of code with the same intensity. Instead, we need to make sure that our automated checks are meaningful and that we assess the result at the right level.

More AI doesn’t automatically mean more productivity

That’s also why I’ve become cautious about sweeping claims about AI productivity.

A randomised METR study from 2025 looked at experienced open-source developers working on tasks in repositories they were familiar with. In this specific setup, the developers took 19% longer with the AI tools available at the time than without them. At the same time, they had expected to be faster.

At first glance, that sounds like a contradiction of my own experience. But it isn’t necessarily. The study looks at a specific period, specific developers, specific repositories and the tools available at the time. METR itself explicitly points out that it doesn’t allow conclusions about whether AI speeds up the majority of developers or software work.

And that’s exactly what I find interesting. The value of AI apparently depends heavily on how we use it.

The Stack Overflow Developer Survey 2025 shows this tension, too: 84% of respondents were using or planning to use AI tools in their development process. At the same time, 46% said they didn’t trust the results. 66% named “almost right” AI solutions as their biggest frustration.

So the question isn’t just how much code AI can generate. The question is how well we can build the environment it works in.

Broader, not just deeper

In my last article, I named deep specialist knowledge as an important differentiator. That still holds. But I now see a second dimension that is becoming at least as relevant: breadth.

An agent implementing a feature may not just be working on React components. It changes API routes, data models, authentication, SEO metadata, deployment configurations or other parts of the system. Whoever is responsible for these changes doesn’t need to be a specialist in every one of these areas. But they need enough understanding to recognise connections, assess risks and verify results.

“I only do frontend” doesn’t become meaningless as a result. But the boundaries of the frontend are becoming more permeable. And perhaps that is one of the more interesting developments for frontend developers. We won’t necessarily become worse specialists. We just increasingly need to understand what happens outside our area of expertise when we trigger a change.

So: How relevant will I still be in 2026 and 2027?

At its core, my answer from February still stands: relevance depends on how we adapt to the changing nature of the work. Today, though, I would put it more concretely.

If a large part of the job consists of translating clearly defined tickets into code, that part of the work is becoming increasingly automatable. That doesn’t mean frontend development is disappearing. It means that producing code alone will increasingly cease to be a sufficient reason for a developer’s role.

Instead, skills like these are becoming more important:

• sharpening requirements and product intent
• designing context and working environments for AI
• understanding architecture and how systems fit together
• developing design systems and interaction principles
• building meaningful automated checks
• verifying results technically, visually and from a domain perspective

None of these skills are entirely new. Good developers have always needed them. But their weighting is changing.

And perhaps that is the real answer to the question of how relevant my job will still be in 2026 or 2027. The ability to produce code is becoming less and less scarce. The ability to know which code should be produced in the first place remains scarce.

The autopilot is flying more today than I would have expected in February. And it will probably take on even more tasks in the future. But where it flies, which flight plan it gets and how we know it has arrived at the right destination remain our job for now.

The cockpit remains occupied. Only the work inside it is changing.