The Capability Shift

A situation you may recognize

A job listing starts in a familiar way:

Software Engineer: React, Postgres, tests, code review, on-call rotation.
Plus: AI-native workflow, agent harnesses, orchestrate LLM-powered development, ship faster with AI.

A developer reads it and thinks: I know how to build software. Is this still my kind of job?

That reaction is very common. It does not mean anyone fell behind.

Most listings still describe familiar engineering work: judgment, tests, design, ownership of production code. The new words usually describe a changed workflow, not a separate career track.

As you read on, try holding two ideas at once: the listing sounds like a new specialty, and the body of the listing often still reads like the job you already know. Session 6 collects a decoder table for when unfamiliar words show up again. For now, notice whether your worry is about skill (“I cannot do this”) or vocabulary (“I do not know these words”). Vocabulary is usually the smaller problem.

The comparison almost everyone makes

Most people reach for an old comparison first: tab completion or Copilot finishing the line you are typing. That is a natural starting point. A steadier picture comes next.

A clearer picture

Think of a junior teammate you can talk to:

• You explain what you want.
• They suggest steps.
• You steer, correct, and check the result.

The valuable work was never only typing. It is deciding what should exist, and whether what came back is correct. Good engineers were always doing this. AI tools make it harder to pretend otherwise.

Tab completion helps with the next few characters. An agent can read your whole project, run your test suite, and propose a plan across many files, closer to a junior teammate you direct and verify than to faster typing.

That is why a listing can mention React and agents in the same paragraph. The company still needs judgment. It also expects people to direct and verify AI-assisted work.

If AI tools are new to you: you do not need to become a different kind of person. You need clear goals, small steps, and patience when checking output, with a new helper in the loop.

One example we will reuse

Throughout this guide we follow one small task:

Refactor a payment helper, add tests, open a pull request.

Nothing exotic. We use it so each idea stays tied to ordinary engineering work. When Session 2 asks you to run a plan-only session, it will be on this task. When Session 4 shows a suspicious diff, it will be from this task. You do not need to run the exercise yourself to follow the guide, but if you do, the ideas will stick faster because they are yours, not ours.

“The next step looks easy” (a dangerous moment)

Here is a pattern that shows up in almost every team once AI tools land in the workflow, and it has little to do with how smart the model is.

You ask for help with step one of a task. The answer is good. You skim it, run the tests, and move on. Step two looks like the same kind of work, maybe even simpler. The tool already “gets” the codebase. Momentum is real. It feels wasteful to slow down and check again.

That feeling is understandable. It is also where a lot of avoidable mistakes enter production.

Why “easy” is not proof

When step one succeeds, your brain treats that success as evidence about step two. That shortcut worked fine for human teammates on familiar work. With AI-assisted work, success on one step does not reliably predict the next step: even when the next step looks identical in difficulty.

Researchers describe this as a jagged frontier: the model can be excellent at one kind of sub-task and surprisingly brittle on the next, with no obvious warning in the UI. The charts below are not here to impress you with trends. They are a reminder that uneven strength is normal, not a sign you picked the wrong tool or asked the wrong question.

Job listings and product demos rarely mention this. They show the best step on the best task. Your Tuesday afternoon refactor is messier: legacy tests, ambiguous names, a dependency nobody documented. The gap between demo and daily work is exactly where the jagged edge cuts.

The horizon keeps moving

Over the past few years, models have gotten better at longer end-to-end work: scaffolding, multi-file edits, following a plan for more minutes without drifting. That is worth knowing. It explains why a listing from last year sounds different from one today.

It does not mean every step in your task is equally safe now. The curve below (from METR) tracks how long a task a model can often complete in one pass. Read it as background, not as permission to skip checking:

Research takeaway

Task horizon keeps expanding: how long a model can handle a task end-to-end.

Work that needed a senior last year may be orchestration today, but uneven steps still happen inside that window.

Measuring AI ability to complete long tasks · METR

So the capability shift is real: work that once needed a senior engineer to sequence carefully can sometimes be orchestrated in smaller sessions with an AI helper. The shift in your job is not “stop thinking.” It is “stay awake when the next step feels free.”

A question worth sitting with

Before you read on, notice what your gut says:

If you answered yes, you are in good company. The fix is not pessimism. It is a small habit: treat step two like a fresh handoff, not a continuation that proved itself. Re-read the diff. Run the tests that matter for this step. Ask whether the change still matches the outcome you named at the start.

What “jagged” looks like in practice

Ethan Mollick’s “jagged frontier” image is a useful mental model: excellent on one side of the boundary, brittle one step over:

Research takeaway

Strength is uneven: excellent on one step, brittle on the next step that looks equally easy.

Centaurs and cyborgs on the jagged frontier · Ethan Mollick

The jagged frontier

Capability does not climb smoothly. On one ticket, some steps go well and the next step — which looks equally easy to you — fails or needs heavy correction.

Same example ticket · refactor payment helper, add tests, open PR

Step	You might expect	Often with agents
Map dependencies and plan the refactor	Medium effort	Strong
Refactor the payment helper module	Hard	Strong
Fix import in the adjacent package	Easy neighbor	Brittle
Add unit tests for the helper	Medium effort	Strong
Handle checkout edge-case errors	Medium effort	Brittle

Concrete examples from ordinary engineering work:

• Step 1: generate a test file with sensible cases: looks great. Step 2: wire the mock for your payment provider: silently wrong, tests still green because assertions were weakened.
• Step 1: rename a helper and update imports: clean diff. Step 2: adjust error handling “while we are here”: behavior change nobody asked for.
• Step 1: explain a module in plain language: accurate summary. Step 2: suggest a refactor across packages: misses a circular dependency your team hit last quarter.

None of these require a “bad model.” They require a human who does not trust ease as signal.

That is why companies still list React and tests beside AI vocabulary. They are not paying for faster typing alone. They need people who direct, verify, and decide what to do next when the easy-looking step fails. The same judgment you already use in code review, applied to a new kind of draft.

Three quiet changes you may already notice

If the jagged frontier is the caution, these are the everyday signs that the workflow around you is shifting, even when nobody sent a memo.

1. Small, well-described tasks sometimes finish in one pass: scaffolding, tests, a scoped refactor. That can feel like magic the first few times. It is also the easiest place to skip verification because the output looks finished.
2. The tool reads files and runs commands: not just suggesting the next line. That is the shift from autocomplete to something closer to a teammate. It also means the blast radius of a bad step can be larger than a typo.
3. Quality becomes a workflow question: teams that skip checking fail in public; teams that separate experiments from production can move faster without lowering the bar. The teams that struggle usually did not pick the wrong model. They picked the wrong phase: planning, implementing, and reviewing all in one chat.

What should stay on your side of the desk

Not everything belongs in the AI’s hands, even when the tool offers to try: brand-new architecture, security-sensitive paths, performance without measurements, product questions about what to build. The AI can draft and suggest. You still own the decision: what ships, what waits, what gets a second pair of eyes.

Session 4 walks through how to check output when stakes are higher. For now, notice where you already draw lines for junior teammates or contractors. Those lines still apply; the helper is just faster at producing text and diffs.

One habit worth keeping from day one

Do not paste secrets into an AI chat: production passwords, customer data, private keys, raw .env files. Session 3 shows how to write safe rules in the repository. For now, treat sensitive data with the same care you would use in a public code review comment.

A small exercise (optional)

Think of one real task and jot four lines:

Outcome:
What I might ask an AI to help with:
What I would keep for myself:
How I would know it was correct:

Session 2 gives you names for those buckets and a gentle first session to try.

Before Session 2

Session 2 names the stack behind those listings (harness, agent, orchestrator) and walks through one careful plan-only session when you are ready.

The job listing table at the end of Session 6 is there whenever you need it.

Next: Session 2: Stack + Your First Session