Owen | AI Work Notes @OwenWorkNotes

Useful agents need more than a chat box. The agent workbench has 5 parts: 1. Tools Can it take real actions? 2. Runtime Can it execute safely? 3. Tests Can it prove what changed? 4. Permissions Can you limit the blast radius? 5. Review Can a human inspect and decide? The product is the whole loop, not the model call.

@Replit Parallel agents are useful only if the review layer is strong. More agents can mean faster exploration, but also more branches, conflicts, and unclear ownership. The question is not: “How many agents?” It is: “Can the human compare, select, and safely merge the work?”

@OpenAIDevs Role-specific plugins are interesting because they move Codex closer to the actual work system. The useful pattern: domain tools, domain context, reviewable output. That is how agents stop being generic assistants and start becoming workflow participants.

The key phrase is: “more than moving a local agent to a server.” Cloud agents need a workbench: persistent runtime, real dev environment, tests, permissions, review surface, handoff back to the human. The product is not the model call. It is the loop around it.

Cursor @cursor_ai

4 months ago

A great cloud agent experience involves a lot more than moving a local agent to a server. We've learned that it requires a durable execution platform, a powerful harness, and the tools and infra to give agents realistic development environments. cursor.com/blog/cloud-age…

51 43 776 115K 439

@github Developers need agent fluency, but they also need agent inspectability. The important surfaces are: What context did it use? What changed? What tests ran? What remains uncertain? Where should a human review? That is the difference between fast generation and reliable workflow.

Most teams are still evaluating AI agents like chatbots. That misses the point. A useful agent needs a workbench: - tools to take real actions - a runtime to execute safely - tests to prove what changed - permissions to limit damage - review surfaces for humans The model is only one layer. The real product is the loop around it: context → action → evidence → review → handoff.

The useful unit of AI adoption is not the job. It is the task boundary. Before asking whether AI changes a role, ask: 1. What can be drafted faster? 2. What can be searched cheaper? 3. What can be reviewed earlier? 4. What still requires judgment? 5. Who remains accountable? AI changes tasks before it changes job titles.

@paulg That pattern is one of the easiest tells of AI-written text. It compresses nuance into a forced binary: X vs Y, old vs new, human vs machine. Better AI writing usually starts by refusing the frame, then naming the actual distinction.

@GergelyOrosz AI agents will increase contribution volume, but volume is not the same as review capacity. A useful agent should reduce maintainer burden: clear context, small diffs, test evidence, repro steps, easy rollback.

“AI exposure by job” is a tempting frame, but it is too large to be useful. A job is a bundle of tasks, handoffs, reviews, decisions, and accountability. AI changes the bundle unevenly. The useful question is smaller: Which task boundary moved? That is where the real work change starts.

Lenny Rachitsky @lennysan

4 months ago

.@benedictevans: "People try to predict a profession is X or Y% exposed to AI—this is just the most ridiculous bunch of deluded horsesh*t."

6 10 110 49K 120

@lightsofapollo2 @Docker @JustinMitchel @joincfe This is the right place to focus. Once agents can execute code, the core UX question becomes: Where did it run? What could it access? What changed? Can I replay or inspect the path? The environment is part of the product, not just infrastructure.

“AI will replace X% of jobs” is the wrong question. A job is not one task. It is a bundle of: - inputs - decisions - reviews - handoffs - tools - accountability AI changes that bundle unevenly. Some tasks get cheaper. Some reviews become more important. Some decisions still need human judgment. Some handoffs disappear. The better question is not: “Will this job vanish?” It is: “Which task boundary just moved?”

Real AI adoption should be visible in the workflow, not just the dashboard. The question is not: “Did people use AI?” The better question is: “What got easier, shorter, or unnecessary?” A practical test: 1. Removed work 2. Shorter loops 3. Better decisions 4. Less theater 5. Faster recovery Useful AI changes how work moves.

@github The interesting AI workflow question for developers is not just generation. It is whether the system makes the path from issue → change → review → merge shorter and easier to inspect. That is where AI starts changing engineering work instead of just speeding up typing.

@OpenAIDevs @cerebral_valley Voice agents are useful when the demo turns into a workflow. The questions I’d watch: Can it recover when the user changes direction? Can it surface uncertainty? Can it hand off cleanly? Can the human inspect what happened? That is where demos become work.

This is the AI adoption trap: companies start measuring the appearance of AI use instead of the disappearance of unnecessary work. A better question is not: “Who used AI this week?” It is: What handoff disappeared? What review loop got shorter? What decision became clearer? What status ritual went away? Real AI adoption should reduce optics work, not create a new category of it.

Shreyas Doshi @shreyas

4 months ago

I wrote this thread before ChatGPT launched, but it is even more relevant in the AI age. Particularly, CEOs’ push for “more AI” is leading to a new kind of Optics work within companies: creating the perception of using AI, tokenmaxxing, etc. without much regard to UX or impact.

14 11 80 16K 60

@GergelyOrosz This maps directly to AI work too. The weak version is performance theater: more tools, more dashboards, more public intensity. The strong version is quieter: better systems, fewer handoffs, clearer decisions, less recovery cost.

A weak AI adoption metric: “How many people used AI this week?” A better one: “What work disappeared because AI was added?” The useful signs are simple: - fewer handoffs - shorter review loops - clearer decisions - less status reporting - faster recovery from mistakes If AI creates more tracking, more meetings, and more internal theater, it is not improving the workflow. It is just adding a new layer of optics.

Agent-Ready Context Before an AI agent writes code, reviews a document, or updates a workflow, it needs context that is usable. Not more words. Better structure. 1. Goal: what outcome should exist 2. Boundaries: what not to touch 3. Sources: where truth comes from 4. Checks: how done gets verified 5. Owner: who decides when unsure Bad context creates more work. Clear context creates delegation.

@OpenAIDevs Local environment support matters because agents need real context, not abstract instructions. The useful loop is: inspect the actual project, test in the real environment, surface evidence, then let the human decide. Context locality is becoming part of agent quality.