Owen | AI Work Notes

Practical notes on AI-assisted work, agents, judgment, review, and handoff.

AI makes output cheap. The real edge is trusted work.

[Owen | AI Work Notes @OwenWorkNotes]

I write practical notes on how to stay useful in the AI era.

Not prompt hacks.
Not tool hype.

I focus on:

- judgment
- review
- handoff
- AI-assisted work
- clearer thinking
- better workflows

AI makes output cheap.

The real edge is trusted work.

Follow for practical notes on turning AI output into trusted work.

[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.

[Owen | AI Work Notes @OwenWorkNotes]

@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?”

[Owen | AI Work Notes @OwenWorkNotes]

@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.

[Owen | AI Work Notes @OwenWorkNotes]

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]

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.

https://t.co/3xb2kGUjFd

[Owen | AI Work Notes @OwenWorkNotes]

@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.

[Owen | AI Work Notes @OwenWorkNotes]

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.

[Owen | AI Work Notes @OwenWorkNotes]

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.

[Owen | AI Work Notes @OwenWorkNotes]

@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.

[Owen | AI Work Notes @OwenWorkNotes]

@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.

[Owen | AI Work Notes @OwenWorkNotes]

“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]

.@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."

[Owen | AI Work Notes @OwenWorkNotes]

@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.

[Owen | AI Work Notes @OwenWorkNotes]

“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?”

[Owen | AI Work Notes @OwenWorkNotes]

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.

[Owen | AI Work Notes @OwenWorkNotes]

@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.

[Owen | AI Work Notes @OwenWorkNotes]

@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.

[Owen | AI Work Notes @OwenWorkNotes]

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]

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.

[Owen | AI Work Notes @OwenWorkNotes]

@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.

[Owen | AI Work Notes @OwenWorkNotes]

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.

[Owen | AI Work Notes @OwenWorkNotes]

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.

[Owen | AI Work Notes @OwenWorkNotes]

@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.