Then you try the feature, and it does not behave the way you expected.

This happened to me enough times that I started requiring the agent to run an acceptance test before it calls a feature done.

The acceptance test forces me to clarify what I expect from the product. It then turns that expectation into a real user flow the agent can run and verify before I review the pull request.

What is an acceptance test?

An acceptance test verifies that a feature delivers the outcome it was built to provide.

It starts from the user’s perspective. What should the user be able to do? What should happen as a result? What evidence would prove that the feature works?

For a new file upload feature in a Slack agent, the acceptance test might be:

1. Post a message in Slack that attaches the file.
2. Mention the agent.
3. Ask the agent to summarize the file.
4. Confirm that the response uses information from the file.

Contrast this with a unit or integration test. Those tests might confirm that the upload handler accepts a file or that the file moves successfully through the system. Both can pass even though the user never receives a useful response.

The acceptance test adds the product perspective. It defines what the feature should accomplish and what a successful experience should look like for the user.

Step 1: Define the behavior

Write down how the user should interact with the feature and what visible result would prove that it works.

A simple version

Behavior: [what the user can do]
Success: [what the user sees when it works]

For the file upload example:

Behavior: A user attaches a file and asks the Slack agent to summarize it.
Success: The agent responds with an accurate summary based on the file contents.

The success state should be specific enough to verify. “The agent replies” is not enough. The reply must demonstrate that the agent received, processed, and used the file.

Step 2: Choose the runner

Once the behavior is clear, determine what the agent needs access to in order to run the flow.

Some features can be tested in a browser. Others require an API call, Slack, email, payments, a database, file uploads, or a scheduler.

I use different tools depending on where the feature lives. I use an agent inbox to confirm email delivery, sequencing, and triggers. I keep a separate Slack profile for sending test requests and evaluating the responses. I use an agent-controlled browser to open pages, trigger actions, take screenshots, and verify visible results.

The runner should be the smallest setup that can drive the real user flow.

Anything that touches a real product surface also needs a safe test lane. I do not want an agent posting test messages in a customer channel, sending emails to real users, charging real cards, or leaving behind records that I have to clean up later.

The acceptance test should define that safe lane:

1. Test accounts.
2. Test Slack channels.
3. Test inboxes.
4. Payment sandbox credentials or test cards.
5. Unique values in messages and records.
6. Required environment variables.
7. Cleanup instructions.

Step 3: Create the test before the feature

I create the acceptance test before I ask the agent to build the feature.

It defines the expected user flow, the environment required to run it, and the evidence that will count as success.

Creating it first prevents the test from becoming a description of whatever the agent happened to build. Instead, it becomes an executable definition of what the product is supposed to do.

For the file upload example, the test might:

1. Open the test Slack channel.
2. Post a message containing a unique test value.
3. Attach a known file.
4. Ask Pipa to summarize it.
5. Wait for the response.
6. Confirm that the response includes facts found only in the attached file.
7. Save a link to the Slack thread as evidence.

Step 4: Run and verify

Once the feature is built, the agent runs the acceptance test and keeps iterating until it passes.

I use the LFG loop by Compound Engineering for the broader implementation, review, and testing process. The acceptance test gives that loop a concrete product outcome to work toward.

The test should drive the real user flow and collect evidence that the flow worked.

For a Slack feature, that means posting the message, uploading the file, mentioning Pipa, waiting for the reply, and verifying that the response uses the file contents.

What an acceptance test does not prove

A passing acceptance test does not mean the feature is correct in every possible situation.

It does not prove that invalid inputs are handled well, permissions are enforced, failures recover cleanly, retries are safe, or the feature performs well under load.

Those concerns still need unit tests, integration tests, negative-path tests, security checks, and human judgment.

The acceptance test prevents the agent from declaring success when the underlying components work but the user-facing outcome does not.

Conclusion

Coding agents can write tests, inspect logs, edit files, and try again. What they cannot reliably infer is the exact product outcome you had in your head.

An acceptance test turns that outcome into an executable standard. It gives the agent a concrete definition of done and gives you evidence that the feature works before you begin reviewing it.

If you are building with coding agents, define the acceptance test before the implementation gets too far. Start with one important feature, one real user flow, and one observable success state.

If you are building with agents and want a set of operational skills to get more out of the ones you already use, so you can stay focused on the work itself, you can find them at usepipa.com.

The more I trusted coding agents with non-coding work, the more annoying it became that they still needed my laptop, my terminal, and my attention.

I was handing local work to OpenCode: plans, writing, research, reviews, repo cleanup, content workflows, and studio operations. Some of that work became cron jobs and recurring agent loops.

So Pipa moved into Slack.

Slack gives me channels for topics, threads for tasks, and a shared place to see what happened. Pipa can work autonomously, but I can still talk to her like a teammate.

Other teams are making the same move. Duolingo built an AI Slackbot with 180+ MCP tools and got to 250 weekly active users. Shopify shared River, its Slack-native agent that coauthored one in eight merged pull requests. Mintlify wrote that its docs agent runs on OpenCode and Daytona in sandboxes.

If you want to build your own version, you can probably point your agent at this article and have it spin one up.

Update, August 29, 2026: This article documents the hosted architecture behind Pipa when I wrote it. Pipa Local now gives you a direct way to connect OpenCode on your computer to Slack. The architecture below still matters if you want to build a hosted agent that can run without your laptop.

Install Pipa

If you already use OpenCode, install Pipa Local from your terminal:

npm install --global @usepipa/pipa
pipa init
pipa start

During setup, you choose the Slack users and channels that can use Pipa. Pipa uses the folder where you run pipa init as OpenCode’s working context, and it inherits the configuration and permissions from your OpenCode setup.

The OpenCode Slack install page has the shortest setup path. The full tutorial walks through creating the Slack app and testing your first request.

How it works

The architecture behind Pipa looks like this:

Each tool has a job.

• Slack is where most work starts and answers land. It gives Pipa the message, requester, workspace, thread, and delivery target.

• The gateway is the web service that receives requests. I host it on Fly. It accepts Slack events, automation API calls, trigger requests, Composio webhooks, Inngest calls, and runtime calls.

• Inngest wakes work up. It handles scheduling, retries, cancellation, concurrency, and execution handoff.

• E2B is the sandbox. It gives the agent its own computer to do work.

• OpenCode is the agent harness. It is the brain that edits files, runs commands, calls tools, works in repos, and returns structured output.

• Composio handles external triggers and tool integrations. It can wake the gateway when something happens in another app, and it makes it easy to add tool connections in Slack.

If you do not need the autonomy pieces, Slack, a sandbox, and an agent harness can get you pretty far.

Creating “autonomy”

You can stop at a setup where a Slack message starts OpenCode in a sandbox and get leverage. If you already live in Slack, that reduces friction for you and your team. Threads become workspaces. You can keep several tasks moving at once without living inside a terminal or another agent UI.

With a little more shaping, the agent can start doing more on its own.

The pieces I add after the base sandbox loop are:

• Character and instruction files. OpenClaw popularized files like soul.md, heartbeat.md, and character.md. You can put the same kind of files into the OpenCode config. They shape behavior, set standards, and give the agent more personality.

• Automations, workflows, and triggers. This is where I get the most benefit. Inngest wakes the agent and sandbox at a set time. Sometimes the prompt is specific: run this skill on this thing every morning. Sometimes it is more like a heartbeat: look at the current state, use judgment, and decide what needs attention. Not every run starts from time. Many SaaS tools send events. If you want the agent to wake up and execute a skill when something happens, create a trigger.

• Tool access. I use Composio because it makes broad tool access easy. If I need to give the agent something, I click a link. If the agent is blocked, it can post in Slack, say what it needs, and I can connect it. A lot happens when the agent has access to the same everyday tools I use.

• Skills. Agent skills teach the agent how to write things and do things. This matters more with automations, because many of my scheduled prompts look like “run this skill on this target.” The skill holds the logic. The public Pipa skills live in the Pipa skills repo.

• Memory. I use Supermemory for this. Before, Pipa loaded context files and knew to update them. A memory tool adds teammate-like recall: goals, preferences, latest business state, and small details that should carry across runs. Good memory tools also know how to supersede and delete memories, which matters once the agent has more autonomy.

My favorite pattern right now uses Linear. I keep a task list there, then Pipa can wake up, pick work, do it, ship it, and leave me something to review.

Why OpenCode

You could use the Claude SDK, the OpenAI SDK, LangChain, OpenClaw, Hermes, Codex, or another agent system and still use the pattern in this article.

I like OpenCode for a few reasons.

1. It is easy to reason about.

I have run experiments with OpenClaw and Hermes, and they are fun. They are also built around stronger autonomy patterns. But I have had more trouble making them execute as deterministically as a coding agent. Call it a skill issue, but OpenCode is easier for me to understand when it works and when it breaks.

2. It works for local synchronous work and “autonomous” Slack work.

My work now falls into two buckets: tasks I go deep on locally, and tasks that can run in Slack with less supervision. OpenCode gives me one harness for both. I am not learning the edges of two different systems.

3. It is open source and swappable.

I can change the model without rebuilding the runtime around another provider. I can swap models, plugins, memory tools, and sandboxes without tying the whole system to one agent ecosystem.

Build your own OpenCode Slack agent

The architecture in this article is the hosted path: Slack for the interface, a gateway for requests, Inngest for workflows, E2B for sandboxes, and OpenCode for agent work.

If you want to run OpenCode from Slack without assembling that stack, Pipa Local is open source. If you want Lunch Pail Labs to configure, host, and keep the broader setup working for your company, read about Pipa Managed.

Some of that is practical. Trying to work away from my laptop is a good constraint on the business. Every bit of friction shows me something that still needs to be operationalized or agentified. It exposes the parts of the business that still depend too much on me being at a computer.

Some of it is aspirational. I like being able to keep work moving while I am going for a walk, eating ice cream, or generally away from my desk. (P.S. I made a short on how I set up OpenCode so I could do more of that.)

The version of work I keep wanting is one that can move with me. I can still jump into deep sessions when I need to, but I can also live outside of work and have the business keep moving around me: long walks where I can brainstorm, quick check-ins between errands, meaningful progress that does not require me to stare at a screen.

One piece that keeps getting in the way is review.

Agents generate a lot of things for me to read: plans, PRs, specs, summaries, and so on and so on. The pile is not exactly friendly when I am on the go.

That is what pipa-audio-brief is for.

The audio brief skill

Think of it like the summary you want from a sharp coworker before you decide where to dig in. It orients you. It tells you what happened, what changed, and where your attention is needed. You can ask for a brief on anything your agent can access: an agent session, PR, plan, spec, doc, URL, repo changes, metrics, or pasted markdown. The skill turns that into a short audio brief and publishes it as a here.now link, so you can listen yourself or share it with someone else.

Pipa, our studio operations agent, uses the skill when I need to:

• check what happened across my PRs
• check the shape of a plan before reading the full doc
• get the gist of a PR before opening the diff
• listen while walking, commuting, between calls, or generally doing other things

It’s free and open source. You can use it with any agent including Claude, Codex, OpenCode, OpenClaw, Hermes, or whatever else you use. If the agent can install skills, it can create a brief.

Just run:

npx skills add lunchpaillola/pipa-skills --skill pipa-audio-brief

After that, your agent can turn whatever you hand it into a listening link.

Every brief follows the same rough path:

1. Context and overview
2. The story
3. Attention areas
4. Takeaway

What is behind the skill

Under the hood, the skill gathers the context you point it at. Then it writes a 300 to 350 word spoken brief, generates audio with Kokoro, builds a single page listening UI, publishes it with here.now, and hands back the listening URL.

The architecture notes:

• No external text to speech API. It runs Kokoro locally, with extra handling for containers and lower memory sandboxes. It needs at least 1 GB of memory. That means I can generate as many briefs as I want without thinking about API costs.

• The brief opens as a here.now listening page. Authenticated here.now links can persist. Unauthenticated ones expire after 24 hours.

• The default brief stays around two minutes, even if the source is huge.

Pipa skills are free to install

Pipa audio brief is part of our Pipa skills repository, the set of skills behind our studio operations agent Pipa.

You can use the skill on its own. Install it and give it to your agent.

Pipa is our managed agent for studio operations. This audio brief skill is one thing she can do, alongside the other skills, automations, triggers, and workflows we use to run our work.

If you want to wire and tune that yourself, start with the Pipa skills. If you do not, hire Pipa.

That sounds harsher than I mean it. I have never treated lunchpaillabs.com as an important surface in the business. It is not directly a revenue driver. People usually meet Lunch Pail through one of its arms: a YouTube video, an article, a marketplace integration, a tool, or a project already in motion.

Lunch Pail Labs is the container for all of those activities. Because of that, I have usually kept the site simple. It needed to explain roughly what Lunch Pail was, not carry the whole business.

Over the weekend, I gave it more attention than I had in months.

Partly because building with AI has made these experiments feel trivial enough to attempt. But mostly because I have been having too much fun pushing Codex and OpenCode to build things with more taste. I wrote more about that in how to give agents design taste.

So the weekend project became a small experiment: could I make Lunch Pail Labs express more of the world it lives in?

Here’s how that went.

Software for the workbench

Lunch Pail Labs has taken a few shapes.

Last year, the site was saying something like, Focus on your business, we’ll handle integrations. That was true enough for the services and integrations season of the studio, but it started to feel too narrow. It made Lunch Pail sound like an implementation shop, when the work was drifting toward something else.

The studio was becoming more of a portfolio of tools.

That is where software for the workbench came from.

The phrase felt closer to the instinct behind Lunch Pail. I like making things that make my own work easier. I like software that feels like something you reach for while you are already in the middle of making.

A couple months ago, I shifted the tagline. That became the first real iteration of the site in this direction. To drive the metaphor home in a simple way, we added drafting paper.

That was step one.

From drafting paper to an actual bench

The old site was already reaching for the workbench idea, just in a flatter way. It used a grid that felt a little like drafting paper. I liked parts of it. It suggested architecture, making, and planning.

But the metaphor stayed on the surface.

This weekend, I wanted to push it one step further. What if the homepage felt less like a page about the studio and more like entering the bench itself?

So now the site is a workbench with items I actually reach for in my life and in the studio.

• A plant, because I like plants.
• A radio, because I have been getting more into music and experimenting with live coding for beats (hellooo strudel).
• A reading list, because there are a few works that feel fundamental to how I think about running Lunch Pail Labs and the business.
• A lunch pail, because I had to do it. It gives me a place to explain why we are called Lunch Pail and what that name means.
• A CRT, partly as an homage to the internet and software, because we are still a software studio.

There are other elements too: scraps, objects, handles you can click around, and small pieces of the studio’s world sitting on the bench.

AI made the nonconventional version worth attempting

A more interactive, layered website was not impossible before. It was just easier to talk myself out of it.

Before AI, that kind of expression still had a cost. Cutting up images, composing the scene, wiring the interactions, and polishing mobile behavior would have been enough friction to make the practical version win.

Especially for the Lunch Pail Labs website, where I can trade a little legibility for more fun. This is not the main funnel. It is the home you find when you trace a project, tool, article, or integration back to the studio behind it.

That gives the site room to be more expressive. It can carry more of the taste of its maker because it does not have to carry the whole commercial burden.

AI makes basic competence cheaper, which means I can push a little harder and take a few more risks. That has been the fun part of building lately. The cost of trying the stranger version is lower, so the stranger version can survive long enough to be judged.

Conclusion

That is the redesign.

The cool thing about the workbench is that it does not have to stay fixed. Each object is its own scene. Over time, I can swap images, add new tools, change what is sitting on the bench, and let the site evolve as the studio’s taste and focus evolve.

It is a home the studio can keep growing into.

When it works, it’s awesome. You ask for help. Pipa goes off, runs the tools, does the work, and comes back with the answer.

When it goes wrong, it’s a complete black box. In the terminal, I can see the mess: tool calls, permission prompts, stalls, and weird little “I can’t do that” moments. In Slack, most of that disappears behind a typing indicator and one final message.

If you’re building an AI agent that lives in Slack or runs in the background, this pain may feel familiar. You need traces. This is the setup I used to send mine to Honeycomb.

Start with the trace shape

A trace shows one request moving through your system. For a Slack agent, that usually means one Slack message, one agent run, and one Slack reply.

The shape depends on your architecture. In Pipa, a chat gateway pings an E2B sandbox, loads the right skills and templates, and runs OpenCode.

For Pipa, I put the telemetry in the chat gateway because that layer sees the whole run: the Slack prompt, the sandbox lifecycle, the OpenCode event stream, stdout and stderr, retries, run status, and Slack delivery status.

The gateway creates one trace per run. That trace is made of spans. A span is one timed step inside the run, like preparing the sandbox, starting OpenCode, watching a tool call, or sending the final Slack reply.

For my bot, the trace includes spans like:

• pipa.run.execute
• pipa.e2b.sandbox.prepare
• pipa.opencode.command
• invoke_agent pipa.standard_opencode

The first few spans explain the backend path. The invoke_agent span explains the agent session. Inside that span, Pipa attaches events for the user message, assistant responses, tool calls, retries, and run summary.

Now the boring infrastructure stuff and the agent’s actual behavior live in the same trace.

Add the traces

1. Send OpenTelemetry traces to Honeycomb

OpenTelemetry creates and sends the trace data. Honeycomb is where I inspect it. In Pipa, the gateway sends traces to Honeycomb when HONEYCOMB_API_KEY is present.

Slack event -> gateway run -> sandbox prepare -> OpenCode command -> Slack reply

2. Create one top-level span for the agent run

For Pipa, the top-level run span is pipa.run.execute. This is the span I search for when someone says, “the bot got stuck” or “Slack never got a good answer.”

3. Add spans for the big infrastructure steps

These spans tell me whether the basic plumbing worked:

• pipa.e2b.sandbox.prepare
• pipa.opencode.command

They answer the early questions. Did the sandbox start? Did OpenCode run? How long did each step take? Did the failure happen before the agent really got going?

4. Add an agent invocation span for Honeycomb Agent Timeline

One thing I missed at first: traces alone do not give you an agent timeline.

You can emit a bunch of spans and Honeycomb will show you a normal backend trace. Useful, yes, but it still reads like infrastructure: Slack event received, sandbox started, command ran, response sent. You can see which services ran and how long they took. You still cannot see what the agent did.

For that, you need Honeycomb’s Agent Timeline.

The way I understand it, Agent Timeline works when Honeycomb can recognize an agent invocation span and read the agent’s activity as events inside that span. Instead of showing only backend work, the trace can show the session itself: the user prompt, assistant messages, tool calls, tool results, retries, and final output.

A normal trace might look like:

slack.event.received -> sandbox.prepare -> opencode.command -> slack.reply.sent

An agent timeline is more like:

invoke_agent -> user_message -> assistant_response -> tool_call -> tool_result -> assistant_response -> run_summary

That distinction matters. Honeycomb can show normal service spans automatically, but it will not magically know what happened inside your agent. You have to emit those events yourself.

As far as I understand it, “Agent Timeline” is Honeycomb’s product view for this. Other observability tools may support GenAI tracing, span events, or custom trace views. Honeycomb’s Agent Timeline is the feature I was targeting here.

Pipa emits a Honeycomb Agent Timeline-compatible span:

invoke_agent pipa.standard_opencode

That span gets the attributes Honeycomb needs to group and display the run:

• gen_ai.conversation.id
• gen_ai.agent.name
• gen_ai.operation.name
• gen_ai.request.model
• app.run_id

This is what lets Honeycomb show the agent session as a timeline instead of a pile of unrelated events.

5. Attach the agent’s activity as events

Honeycomb can show service calls, but it cannot know what your agent did unless you tell it. The gateway sends the moments I actually care about: the user message, the tool call, the agent response, and the run summary.

For Pipa, the gateway parses structured opencode run --format json output and emits events such as:

• opencode.user_message
• opencode.tool_call
• opencode.agent_response
• opencode.run_summary
• opencode.parser_skipped

That makes the hidden middle visible: the prompt, assistant-visible text, tool names, tool status, token and cost data, retry markers, and failure summaries.

6. Verify with a real failed run

After adding traces, run the bot from Slack and inspect the trace in Honeycomb. The trace should answer these questions:

• Did Slack reach the gateway?
• Was the run created?
• Did E2B prepare a sandbox?
• Did OpenCode start?
• What prompt did the agent receive?
• Which tools did it call?
• What assistant-visible text did it produce?
• Did it retry?
• Did the run fail or complete?
• Did the Slack reply send?
• Is anything sensitive leaking?

If the trace cannot answer them, add another span or event at the layer that can see the missing context.

Conclusion

If your AI bot runs inside Slack, traces are how you see what happened between the prompt and the final reply.

Start with the questions you ask when the bot responds badly. Then emit spans and events around those moments. One Slack request should become one run you can actually inspect in Honeycomb.

But it is no secret that AI-generated work usually has the smell. It sits in a sort of uncanny valley: clearly a website, but not quite something that feels made by a person. The page has the right functional pieces: hero, CTA, cards, proof. But it still feels like the average version of every software page you have ever seen.

Agents are trained on much of the public internet. So when you ask an agent for a design, you often get the median.

And it lacks taste.

What is taste?

Taste is a fuzzy word, but I define it as knowing what direction to push in, what to reject, and what feels like you. It is the small decisions that make a page feel specific instead of generic.

When agents make creation cheaper, taste matters more. Everyone can get to “fine” faster. The advantage moves to the person who can look at “fine” and say: no, not that.

More of this. Less of that. This reference, not that one.

How do you cultivate taste?

I think taste starts with consumption. You look at good work on purpose. You ask what makes it work, what makes it shine, and what you would steal from it.

Austin Kleon’s Steal Like an Artist is useful here because it gives language to something creative people already do. Nothing is fully original. Good work builds on what came before it. The point is to notice what you are drawn to, borrow the parts that resonate, and remix them into something that reflects your own point of view.

That is where taste starts to become a muscle. The more good inputs you study, the easier it becomes to tell the difference between what is worth stealing and what is just noise.

Tools to give agents better taste

Taste is context. A sharper set of references gives it something to push toward.

Refero is great for this. It is a collection of high-quality product flows, landing pages, and design references from real products. I used it to find examples that felt closer to the world I wanted Pailflow to live in.

Then I used Impeccable as the critique layer. After the agent produced a draft, Impeccable helped me push on the parts that make a page feel intentional: hierarchy, spacing, copy, motion, restraint, and overall vibe. The useful thing is that it gives you levers. You can ask for quieter, bolder, more animated, more simple, etc.

The later versions are not perfect, but they have less generic software energy.

Initial design, with no Impeccable or Refero:

Variations with Refero and Impeccable:

Conclusion

When the cost of generating a page drops to almost nothing, the hard part is knowing whether the thing on the screen should exist in that form. Does it feel generic? Does it feel like you? Does it communicate the right world? Does it have a point of view?

If I let the agent drive from the median, I get median work. If I give it better references, sharper constraints, and more honest critique, I can push the work toward something that feels more like me.

The Old Metaphors

Manager: Too detached. You end up supervising outputs instead of shaping them.

Intern: Too one-way. You spend more time teaching and correcting than creating.

Editor: Too reactive. You polish what already exists instead of driving direction.

Surgeon: Too specialized. Great for precision work, but not for broad creative problem-solving.

The Head Chef Frame

The head chef is not a distant strategist. They are in the kitchen, hands-on, guiding the team, tasting, and keeping everything aligned with their creative vision. They delegate, but they also step in when something needs attention.

A head chef also has a certain level of competency with the craft. They understand ingredients, technique, timing, and flavor. They can jump on the line if needed. They know what good looks and feels like.

Putting It Into Practice

Here is how I apply the Head Chef model in my own stack, using AI agents embedded in my dev environment to handle execution while I guide direction.

1. Set up your stations. I work in two Ghostty terminals. The left side is for planning and viewing, the right for synchronous agents running through OpenCode.
2. Prep your ingredients. I pick the next task from my list and break it into clear, sequential phases using a custom /create-plan command.
3. Open a shared recipe. Once the direction feels right, I open a GitHub issue so every agent can read from the same context.
4. Cook in phases. I offload each phase to the execution agents with a /create-instruction command and let them work through it.
5. Taste and adjust. As outputs come back, I use a /review command to inspect and refine them before committing changes.
6. Serve and reset. When all phases are complete, I close the issue and pull the next most important task.

This loop keeps me in the kitchen. I am orchestrating, tasting, and directing while AI handles execution without pulling me out of the work.

Conclusion

The metaphors we use for AI are not just storytelling. They shape how we work. When we frame AI as an intern, a coworker, or a copilot, we interact with it in fundamentally different ways. These mental models influence trust, delegation, and how hands-on we stay (source).

The Head Chef model reflects what great product work really requires. You need to understand the tools, the timing, and the ingredients. You need competency with the material.

And for builders, when AI enters the kitchen, that competency matters even more. The more fluent you are across design, code, marketing, and storytelling, the better you can shape what AI produces.

Today AI turns speed into a commodity.

• An AI assistant can spin up a blog post in the time it used to take to draft an outline.
• AI agents can post thousands of LinkedIn comments to farm engagement with a single workflow.
• Vibe-coding tools let you clone and publish the core functionality of any app idea in the time it takes to discuss it.

This is not meant to be anti-AI; I use AI heavily in every part of my business. Yet articles warning that ChatGPT rots your brain and headlines about Deloitte’s error-laden AI report are clear red flags. I want to use AI thoughtfully so that it increases output without sacrificing quality.

And it is a tension. As the owner of a solo enterprise, I perpetually have more work than time. Sending a half-baked prompt to an AI seems like a productivity gain, yet it still forces me to sit beside the tool, edit its output, and often results in not very thoughtful outputs.

True leverage is not just “a little faster”. It is a non-linear system that produces more results than the effort I invest. The real payoff comes from spending the effort upfront to thoughtfully construct a workflow.

With the marginal cost of executing a task approaching zero, AI gives us a paradoxical gift: the space to slow down and be more intentional.

Across processes, this means taking the time to:

• Define standards
• Identify the good inputs required for quality work
• Articulate the step-by-step process for producing the work
• Encode that process in a system that can run autonomously
• Create benchmarks and frameworks to continuously evaluate quality

All of that meta-work is slower at first. It can feel like it gets in the way of actually completing the task. But it makes you a better architect. The advantage lies not in how many tasks you can personally finish per hour, but in the leverage you embed in the systems that run for you. If speed was once the secret weapon, today the secret weapon is systemic speed: the ability to let AI sprint while we focus on the deeper processes and guidelines that sustain it.