How to miss the point of work

The ignominious history of the DeejDrone 9000 // why you can’t just fire your whole team and replace them with named agents

Last week, a product exec asked me a simple question that I thought encapsulated everything we're getting wrong about agents and automation. Not the tech; I don’t think you need AGI to use LLMs well. The key is using them well.

This is the first in a three-part series that explores why we’re getting it wrong, what it’s costing us, and how to fix it. It starts with me speccing a ridiculous vanity drone and ends with a framework that might just save you from building your own.

The DeejDrone 9000

So, I’m talking with a product exec last week - their company builds logistics vehicles - when he asks: "Why do we need PMs when I can generate better PRDs with AI than my team writes?"

"Let's test that," I said. We pull up the LLM he uses for work, hooked up to his company’s shared drive and resources, and I take the wheel.

• We’re going to write a PRD for a new drone (this customer doesn’t even make drones, but the AI wrote a great justification for how easy expanding into the market will be based on absolutely nothing, so we’re all set). I borrow their structure for the PRD, so I don’t miss any steps or line-items - full rigor here.

• I’m calling it the ‘DeejDrone 9000’ (again, not typical naming for the industries in question, but again: LLM’s got me covered on why the market will love it).

• I’m insisting on making it biodiesel-powered-only (tagline: “she runs on corn” because enterprise aviation folks love HIMYM deep cuts? I bet?) and we’re going to paper over any questions about specific energy and setting up a new fuel supply chain and managing for weather conditions and performance at altitude because it’s trivial to do all of those things from the comfort of my browser window¹.

• I get a great PRD. Beautiful structure, great prose, notional PR for release, excellent detail all around². Paste into Word, slap on company letterhead, print 1000 copies, let’s build this thing, right?

I’m narrating as I go, and by this point, it’s obvious to everyone that my DeejDrone 9000 is not a great idea. The top-level “why” is reductive: “because you’re being ridiculous.”

But what made this approach ridiculous? Why does taking this cutting-edge tech and applying it to a tried-and-tested product methodology (adapted specifically to this company and LOB and vetted for rigor) result in such a garbage outcome?

And if this process was extreme, does it mean that all variants on this process are equally ridiculous? Where’s the brightline on doing this work the right way?

Role reversal leads to role erosion

Last time, we explored how sales reps spend hours copying AI content between systems while agents write strategic plans. Today, I want to talk about why this keeps happening and what to do about it.

This is the root of why most companies are getting AI backwards and why it hurts more than they think. Sales reps spend hours copying AI-generated content between systems while agents write their strategic plans. Engineers review thousands of lines of generated code while AI makes their architectural decisions. PMs generate beautiful PRDs with Claude while missing what their customers actually need.

We know we’ve role-reversed. We’ve handed the thinking to the machines and kept the typing for ourselves. One dynamic we didn’t touch on last time: the more we hand over the thinking, the more we cut the thinking out of the process altogether³. That's not just wasting time, it’s actively eroding capability. That’s real damage.

Over the past few months at gigue, I've been iterating on a framework I used in the past to understand why this keeps happening. It's helped me in the past to spot the difference between real work and productivity theater and show it to others. These days it's helped folks figure out where AI actually belongs in the work stack.

Hopefully it’ll help you too.

What our artifacts are supposed to be doing for us

We're getting dangerously good at generating artifacts - code, images, documents - without understanding what for.

Software engineering isn't generating variables and brackets and semicolons; it's building a shared intricate understanding of a problem that transcends the theory or discussion of how you might solve it⁴. Same is true for AI image, video, and audio generation: art isn't arranging pixels or rocks or notes, it's first and foremost a way of conveying meaning and emotion that’s designed to end-run the mental barriers we put up to hearing those messages spelled out in literal, logical form⁵.

The rest of knowledge work is similarly deeper than the sum of its artifacts. Product management and enterprise sales isn't document creation; it's discovering what customers actually need and connecting their needs with what the business can deliver, then playing that back to them in their own terms⁶. Writing documents and updating CRMs is increasing taking over folks’ time, but it’s still not the most important part of the job, and it’s still a lagging indicator of doing your job right⁷.

The backwards approach? Let AI generate different versions for different people, and then-and-only-then try to extract the core meaning from the outputs. Even when you get what seems like a coherent set, this is like getting a random assortment of pre-baked dishes and then trying to put together recipes for a themed meal.

Little late, no? You already have the final results, and you may not even be able to tell all the ingredients that went into them, so it’s silly to back into the lowest-common denominator and pretend like you meant all of this to happen from the start.

It’s Codenames: Career Edition⁸.

And that’s if your team put together coherent AI outputs. Way more often, five great engineers generate ten totally different pieces of software in Cursor and no one has the first idea which is the one we were supposed to be building.

Central to the problem is that coherence in practice depends on longitudinal context, something that our existing context windows make very difficult (if possible at all) and very expensive (when possible). When we write code, generate images, draft documents, or update databases, there are long-running threads and ideas that exist in time and space, outside of the scope of any agent’s context window, but in the heads of the humans tracking the program, project, or deal that the artifacts are about.

Not only are the agents not able to hang onto these threads in any detail outside a given session… you don’t really want them to, otherwise you start burning large amounts of cash on every API call. You compact and hope the important parts make it into the summary, or you reset and take each task as a wholly new challenge, reforming new context windows each time, accepting the context loss as you go.

All of this means when you tap agents to build documents as a proxy for doing the job that emits those documents as byproducts, you put yourself in danger of creating artifacts for their own sake. You’re LARPing doing business.

Products and byproducts

So this comes back to the example of the PRD. Why does the PRD I wrote not work? (Despite being ridiculous?)

It’s because the job of a PM is not to write PRDs. (Hopefully this is what the PMs reading this have been yelling for the past few paragraphs).

PRDs are a byproduct of PMs doing their job. The fact that I can use a word combobulator to fill one in “convincingly” means absolutely nothing when it comes to actually building something people want. I didn’t do the job.

A PM’s job is to figure out what the customer wants - what the customer says they want, what they actually need, what they’d like to have, what they think they want but would actually not use or even hate⁹ - and then figure out how the business should go about building that thing. Or - in many cases - to recognize that we shouldn’t build it at all.

PMs take all this synthesized information and structure it into a coherent plan the business can process, aligning with stakeholders, checking feasibility, knife-fighting prioritization, and generally realizing an amorphous “concept-of-a-plan” that can turn into real value.

But because businesses don’t run well on amorphous stuff, and people don’t remember the details of amorphous stuff well, PMs document. That’s what the PRD is. The PRD is not the key output. It is an artifact that keeps people from forgetting or mishandling the key output. It’s not the Holy Grail; it’s the Ark of the Covenant¹⁰ - it’s what’s inside that counts.

What counts

The DeejDrone 9000 isn't going into production. (Sorry to disappoint). But it clarifies something crucial: we can generate perfect-looking artifacts without any of the thinking that's supposed to go into them. We can create PRDs without product sense, code without architecture, emails without human empathy.

The more we hand over the thinking, the more we cut thinking out of the process altogether. That's not just inefficient, it's actively making us worse at our jobs. It’s role erosion, skill rot.

Next time, I'll delve into how to figure out which documents and activities “count” and which ones don’t. I’ve been refining a framework for a while now that explains exactly which parts of your job deserve attention (human or agentic) and which don't. There’s a couple “gotchas” I’ve picked up over time that will hopefully help.

See you then.

1. Not that there aren’t perfectly viable cargo drones capable of using biodiesel - there are - but this is not how you go about designing one.

2. For your enjoyment, recreated and anonymized here.

3. No, “thinking mode” on an LLM doesn’t substitute.

4. The functions and types and classes of it all are a byproduct of this process, and the quality of the end result depends not on pure beauty of the syntax (which is why SWE teams are not evaluated by the sum of their LeetCode scores) but on the ability of the code to map the shared understanding of the problem and the ability of the team to map the problem to the customer’s reality with minimal excess complexity. CC and Codex are great, but they’re not checking this for you. This is not to say that agentic codegen is bad: it is to say that agentic codegen in the absence of software engineering is bad. I’m not alone in thinking this: if you read some of the “tips and tricks” on r/vibecoding, for example there are a slew of folks trying out techniques for rigor in planning, architecture, orchestration, control, CI/CD, QC,… essentially, re-inventing software engineering from the ground up to get their vibe-coded results to actually work. They’re realizing what many engineers have been saying for a while now: writing the code is a small fraction of the time and effort involved in engineering.

5. Tools like Midjourney and Runway let you choose with high precision the lens and lighting and scenery of the generations you’re creating, but you’re fundamentally approaching the flow backwards: your choices in technique and style are driving the heart of the output, not the other way around. There’s a ton of good use cases for quickly generating images and videos and songs in industry - upscaling, interstitials, brainstorming and temp generation, remastering, procedural customization - but attempting to substitute for the soul of actual art isn’t one of them.

6. Obligatory We Don’t Sell Saddles Here reference.

7. It may not sound like it at first, but play it out and this is common sense: if you update your CRM to pass the qualification gate before you take the qualification call, that’s a problem.

8. This game, if you’re not familiar. Party game where you need to pick out common underlying concepts from unrelated words in as few turns as possible. The picture version in particular is a great way to learn how someone’s brain works.

9. This is called the Voice of the Customer, and the gap between problems customers elucidate well and solutions they imagine poorly is startups’ happy place. This is the nuance to the cliche Henry Ford quote: in real innovation space, customers are usually great at describing their problem and terrible at coming up with the right solution. That’s ok: that’s not their job, it’s ours.

10. This is more an Indiana Jones reference than an actual discussion on religious iconography. Which I guess means the amorphous concept-of-a-plan / “spirit of the product” melts faces when you look at it directly? I don’t know, don’t extend the analogy too far.