Owning the whole path alone became possible not because people suddenly got smarter, but because leverage appeared. AI takes on the execution volume that used to require a separate pair of hands at each stretch. But leverage is an amplifier, not a replacement: it multiplies what you put into it, and it equally happily multiplies both the right direction and the mistake.

That's why the whole prior conversation about problem, contact, outcome and slice didn't become obsolete with AI's arrival — it became more important. The more powerful the amplifier, the costlier it is to get the direction wrong. A product engineer wins not because they have AI — everyone does — but because they know what to put into that AI.

What AI takes on, and what it doesn't

AI is good at taking on volume: writing code from a clear spec, breaking it into layers, sketching options, doing the routine that is plentiful and mechanical. Here it saves days and weeks, and it's exactly this that lets one person reach the stretches there weren't enough hands for before.

What AI doesn't take on is the decisions about what to do and why. Which problem we're solving, what contact with the user will show, which outcome we count as success, what we don't build — these are questions of taste, responsibility and understanding people. AI can help think them through, but it can't decide them for you: it has no skin in the game and no contact with reality of its own. Hand it these decisions and you'll get, quickly and well made, the wrong thing.

What to give the agent, what to keep for yourself

The boundary runs roughly like this. To the agent — execution and search: write from a spec, generate options, check code against rules, comb through the details. To yourself — framing and judgement: name the problem, choose the outcome, decide what goes into the slice, and assess whether the result actually relieved the pain.

A practical sign: anything that can be checked against clear rules can be given to the agent; anything that requires contact with the user and responsibility for the consequences stays with the human. A product engineer doesn't write less code by hand on principle — they move themselves higher up the path: to where it's decided what to build, while the building itself is increasingly handed to the lever.

One day: agent tasks and human tasks

A bug report came in: for some users, the reports page takes 8–12 seconds to open.

What I did myself. Read several complaints — the slowdown only hit users working with large datasets covering a year or more. Wrote to two affected users and asked: does this block them in a specific workflow or just annoy them? It turned out it blocks: one of them opens the report at the start of a meeting in front of colleagues, and 10 seconds of waiting creates discomfort. I decided the "acceptable" threshold was 2 seconds for a typical volume. After shipping the fix, I wrote to them again.

What I gave to the agent. Profiling queries against existing logs, locating the bottleneck in the schema, three optimization options with the trade-off of each explained, a regression test on response time. The agent found it: the problem was a missing composite index and N+1 when assembling nested records. It proposed three approaches. From the three options I picked the third myself — because only I knew that in a quarter these users would move to twice the data volume and the simplest option would have become a bottleneck again.

This is the structure of almost every task. To the agent: "find X," "check against rules Y," "write a test for Z." To yourself: understand who's hurting and how much; what's acceptable; confirm that the result actually helped. The boundary isn't in the complexity of the task — it's in who bears responsibility for the consequences of the choice.

Why the lever breaks without methodology

AI without methodology has a treacherous property: across three sessions on one task it gives three different solutions. All three work, all three incompatible. For a one-off sketch this doesn't matter; for a product that lives for years and is carried by one person, it's a slow collapse: each piece is good on its own, and together they don't add up.

Methodology fixes this by giving a shared context that outlives a single session. It sets the framework — how to describe the task, how to break it into layers, which rules to hold — and the agent applies the same framework over and over. Here is the key to the whole concept: one piece of knowledge exists in two forms — the article explains to you why and how, while the paired executable rule holds the same for the agent at every step. You steer, the methodology holds consistency, the agent executes the volume. Without the middle link, the lever tears the product apart faster than you can assemble it.

What this means in practice

Common mistakes when working with AI as leverage:

  • Delegating the framing. "AI, what should we build?" — the fastest road to getting the wrong thing done quickly and well. The model doesn't know what hurts for your users or what you've already tried. The framing is yours, always.
  • Accepting the result without verification. Code looks right — doesn't mean it works right. The agent is optimized for plausibility, not correctness. Every significant output needs checking for meaning, not just form.
  • Working without a standing contract. If the agent has no framework — no task description, rules, constraints — it reinvents them from scratch every session. A month in, the codebase looks like it was written by five different people, even though one person did it.
  • Waiting for the agent to figure it out. Working with agents is a professional skill: how to frame the task, how to break it into parts, how to verify an intermediate result. The more precise the input, the better the output. This isn't a metaphor, it's the mechanics of the model.

Closing the arc

Six essays add up to one path: the problem, contact, the outcome, the slice, ownership, leverage. Each step rests on the previous: the lever without a problem strikes wide, ownership without a slice drowns, an outcome without contact is made up.

This is a working instrument, not a concept. An engineer who has mastered all six steps takes a task from a user's problem to a verified outcome — alone, with methodology and AI at hand. That is what the product specialization means in the product engineer concept.

What's next

How to specifically verify the agent's output — where the model makes mistakes invisibly and how to catch them. How working with agents is structured in practice: framing, iteration, the boundary of control.