the task isn't the job • Solving the decision problem skip to content

Close

the task isn't the job<br>14 August 2026 a new role, and some questions I want to build my way through

coding agents have given me the stupidest problem: I can now build three wrong things before lunch.

lines of code are a terrible measure of productivity etc etc, but they’re still a signal of what’s going on: tens of thousands of lines in a week, ideas tried in an afternoon that would’ve previously needed a few days of commitment, tests and docs and all the annoying little bits I would’ve solemnly promised to come back to later.

this is dope, genuinely! I like making things and now I can make more things.

buuuut my roadmap is’nt ten times shorter. and I’m definitely not ten times better at deciding what is worth building. teams haven’t started casually shipping a year of product work every month. you can look around and and it’s hard to say what software has gotten meaningfully better in the last year.

mostly tho, I seem to reach the difficult decisions faster. all the implementation that used to sit between these decisions has been squashed, so I can ask an agent to try three approaches and have all of them sitting in front of me before I’ve decided if the problem was worth solving.

are we mixing up the task with the job?

there’s a framework from clay christensen called “jobs to be done”. tl;dr: people don’t buy a product because they woke up wanting a product. they “hire” it to make some kind of progress in their life. almost nobody wakes up with the job “use an ai agent.” they want to figure out whether they can afford a house, make the thing they can see in their head, or organise a holiday with six friends without accidentally becoming the project manager of a small temporary company. the software/tool is an implementation detail (usually temporary). and the relationship with the machine changes depending on the Job To Be Done.

say I need thirty seconds of background music for a presentation. a machine that disappears for twenty seconds and returns with something usable has done a perfect job; I did not want to become a musician here.

but if I sit down because I want to make music, handing me the finished song is a fairly spectacular misunderstanding. I wanted to move the chords around, hear what happened, make it worse, change my mind, stumble onto the thing I didn’t know I was looking for. the process wasn’t “friction” on the way to the result. I really needed to tap into my first breakup and access the pain of adolescence for this chord structure, y’know? same artifact, completely different job.

I wrote recently about wanting the human and the agent to have their hands in the same “goo”, both able to reach into the thing being made. I still like that idea! but that could’ve turned it into a Grand Unified Theory of AI Interfaces, which it absolutely is not.

there are many things where I emphatically do NOT want my hands in the goo. please argue with the insurance company for me, chase the refund, reschedule the meeting across six calendars, fill out the form, and do not invite me into a Delightful Collaborative Experience with the God Computer.

the 12$ word “agency” sometimes means being involved, but it also means being able to make the whole fucking thing go away.

we tend to describe progress in agents as progress in autonomy: first they could do five minutes of work, then an hour, now we talk seriously about agents running for days. that’s impressive, but autonomy is a capability, not a product direction! the Job To Be Done tells you whether to use it. sometimes I want “do this for me,” sometimes “do this with me” or “show me how.” sometimes I just need enough of a boost to do something I couldn’t do before. or the AI could quietly become a feature so I don’t have to learn a new ritual involving prompts at all.

a cybernetic machine can nail the task and completely miss the job. coding makes this very very easy to see because the tasks are so legible (and verifiable!): write the function, migrate the API, fix the tests. models are extraordinarily good at this stuff and will get better still.

but a software team’s job was never “produce implementations.” the job includes noticing that users keep asking for the wrong thing because they don’t have the vocabulary for the right one. it includes deciding that two individually sensible features make the product worse together. it includes choosing between several perfectly defensible directions, getting other people to come with you, shipping one, and living with it. (as an aside, this is why I’m still pro “product manager” as a role, once you’ve worked with a great one, it’s clear how much absurd value they can bring to a team) maybe models get extremely good at all of that too; this is not a sneaky argument for some sacred category of Human Work™ that a machine can never touch. I’m just noticing that when one kind of work becomes cheap, you finally get a good look...