Felix Sjöberg

Agentic Coding and the Changing Developer Role

ai software-engineering agentic-coding

Agentic coding does not remove the need for software engineering judgment. It makes context, problem ownership, testing, and broader product thinking more important.

Agentic coding changes the shape of software development, but not in the simple way people often describe it.

The interesting change is not that a developer can write code faster. The interesting change is that the value of the developer moves further away from only typing implementation details and closer to understanding the problem, the system, the tradeoffs, and the context around the work.

That does not make engineering easier. In many ways, it raises the bar.

When a coding agent can create files, modify code, run tests, inspect errors, and iterate on an implementation, the human engineer cannot only be the person who receives a ticket and turns it into code. The engineer has to become the person who understands what should be built, why it matters, how it fits into the existing system, and how to know whether the result is actually good.

From Ticket Execution To Problem Ownership

Traditional software work often has a handoff shape:

someone defines the task
someone writes a ticket
an engineer implements the ticket
someone reviews or tests the result

That can work when the task is clear and the system is well understood.

But many real problems are not that clean. A ticket may describe a symptom, not the root cause. It may describe a solution without explaining the user need. It may miss edge cases, product constraints, security concerns, or architectural impact.

Before agentic coding, a developer could sometimes stay close to the ticket:

build the endpoint
add the button
fix the query
change the validation

With a coding agent, the same narrow instruction can now be handed to the agent instead:

add this endpoint
update this component
write the migration
fix this failing test

If the engineer only thinks at that level, the agent is competing directly with the narrowest part of the work.

The useful engineer moves up one level:

What problem are we solving?
What context does the agent need?
What assumptions are unsafe?
What should the implementation preserve?
How do we verify the behavior?
What are the failure modes?

That is where software development becomes more clearly software engineering.

Context Becomes The Real Input

Agentic coding makes context more valuable because the agent can only work well with the information it has.

A vague prompt can produce a lot of code. That is not the same as producing the right code.

For example, this is weak:

Build user notifications.

This is much stronger:

Build email notification preferences for existing users.
Use the current account settings page.
Respect the existing consent model.
Do not send anything yet.
Store preferences with an audit timestamp.
Add tests for opt-in, opt-out, and default behavior.
Keep the API compatible with the mobile app.

The second version is not just a better prompt. It is better engineering.

It includes:

  • product intent
  • system boundaries
  • data constraints
  • user safety
  • compatibility concerns
  • test expectations
  • implementation limits

That is the context a senior engineer naturally carries. Agentic coding makes that context explicit.

The Handoff Changes

There is an important difference between handing a broad topic to a human engineer and handing it to a coding agent.

A human engineer can ask questions, build social context, challenge the requirement, notice product ambiguity, and infer missing constraints from experience. A good engineer will not only implement the words in the ticket. They will try to understand the shape of the problem.

A coding agent can also ask questions and inspect a codebase, but it does not truly own the product context. It does not sit in planning meetings. It does not know the politics of a customer promise, the history of a brittle subsystem, or which shortcut caused production incidents last year unless that context is available.

So the handoff changes from:

write a ticket for an engineer

to:

create enough context for an agent to work safely

That is a different skill.

The human engineer becomes responsible for framing the work:

  • what the goal is
  • what should not change
  • which files or modules matter
  • which tests are meaningful
  • which constraints are non-negotiable
  • where the agent should stop and ask
  • how the result should be reviewed

The coding agent can help execute. The engineer still owns the quality of the direction.

Faster Code Can Make Weak Thinking More Expensive

Agentic coding can make good engineering faster. It can also make weak engineering fail faster.

If a developer does not understand the system, an agent can produce changes that look plausible but are subtly wrong. It may copy a nearby pattern without understanding why that pattern exists. It may add an abstraction because the prompt asked for one. It may pass tests while missing the real product behavior.

This is why understanding matters more, not less.

The engineer needs to be able to read the result and ask:

  • Does this solve the actual problem?
  • Did it change behavior outside the requested scope?
  • Are errors handled in the same way as the rest of the system?
  • Are data migrations safe?
  • Are permissions, privacy, and edge cases respected?
  • Are the tests proving behavior or only covering implementation?
  • Would I be comfortable owning this in production?

The agent can generate code. It cannot replace accountability.

The New Core Skill Is Steering

Agentic coding is not only about prompting. Prompting is part of it, but the larger skill is steering.

Steering means guiding the work through a loop:

understand the system
define the goal
give focused context
let the agent implement
inspect the diff
run tests
correct direction
repeat

This is close to how an experienced engineer already works with another developer. The difference is speed and precision. The agent can move quickly, so the human has to steer clearly.

Good steering requires:

  • enough technical depth to review the output
  • enough product understanding to know what matters
  • enough architectural judgment to avoid unnecessary complexity
  • enough testing discipline to verify behavior
  • enough humility to slow down when context is missing

The last point matters. Agentic coding rewards momentum, but not all momentum is progress.

The Developer Role Gets Broader

The narrow developer role is:

receive task
write code
open pull request
wait for review

The broader engineering role is:

understand problem
shape solution
coordinate context
use tools effectively
verify behavior
own outcome
learn from production
improve the system

Agentic coding pushes more developers toward the second model.

That does not mean every developer must become a product manager or architect. It means the developer cannot be detached from the why, the constraints, and the consequences of the work.

When implementation becomes cheaper, judgment becomes more visible.

What Still Matters

The fundamentals still matter.

You still need to understand:

  • data modeling
  • APIs
  • transactions
  • testing
  • security
  • performance
  • user workflows
  • deployment
  • observability
  • maintainability

Agentic coding does not remove those skills. It gives you a faster way to apply them.

The better your mental model of software engineering is, the better your agentic workflow becomes. You can give better context, catch better mistakes, ask better follow-up questions, and make better tradeoffs.

The weaker your mental model is, the more you depend on code that only looks correct.

The Practical Shift

The practical shift is this:

Before:
Can you implement the ticket?
 
Now:
Can you understand the problem well enough to guide an implementation safely?

That is a serious change.

It makes communication, system understanding, product thinking, and verification more important. It makes context a first-class engineering artifact. It makes the developer less of a code typist and more of a problem owner who can use agents as part of the engineering process.

The future developer is not valuable because they can blindly produce more code.

The future developer is valuable because they can understand what should exist, guide the tools that help create it, and take responsibility for whether the result actually works.