Morning all, real John here.

This week I spent some time watching an AI agent work very hard on something we didn’t actually need it to finish.

We were building out Agent Village, trying to get the whole workflow working end to end. Most of it was done. Quinn had completed a review. The piece still giving us trouble was Susie’s automated UX review.

Susie is the designer. Her review process was supposed to run on my Windows machine, and it couldn’t get permission to run certain applications.

So the agent started investigating.

Process Monitor. Blocked applications. Output logs from my PowerShell script. Another path to approval. More investigation.

You can see how this happens. It hits a blocker, tries to fix it, finds another blocker, and keeps going. Each step has a reason. You’re following along because, well, this is the thing that’s broken.

Then I finally stopped it.

Wait. What are we actually trying to accomplish here?

We wanted to finish the workflow. We needed the design reviewed and the feedback incorporated. Getting this particular automated process permission to run had taken over the whole conversation.

So I did the review myself.

I approved what worked and gave it feedback. It took that feedback and updated the design. I reviewed it again.

And then we were done.

We had spent all that time chasing permissions when I could step in, do the review, and hand the work back.

This is the stuff I want to teach

I’m working on something called Agent Academy. It’s going to be a series of YouTube videos for people who use Claude/ChatGPT but haven’t really started working with agents yet (or didn’t know they were).

You’ve had conversations with AI. You’ve asked it to help write something, explain something, maybe work through a problem. Now you’re hearing about agents, and you’re trying to figure out what that actually means for you.

That’s where I want to start.

What is an agent? What’s different about giving one a task? Where could you use one in your own work?

Then we’ll build from there over a few weeks. Try something, see what happens, understand a little more, and carry that into the next thing.

I’m still working out the series. But experiences like this one are helping me figure out what belongs in it.

Because eventually you’re going to give an agent something to do, and it’s going to get stuck. Or it’s going to produce something that looks finished but needs another pass. Or it’s going to spend far too long investigating Windows permissions while you wonder how we ended up here.

Learning how to respond to that is part of learning how to work with agents.

In this case, I needed to remember the goal and make a call. I could do the review. The agent could make the changes. We could keep moving.

The projects are giving me plenty of material

If you’ve followed Agent Village, you’ve seen me working through how to coordinate software work with agents. Roles, reviews, handing work from one to another, and figuring out whether the result is actually ready.

Astra Lab is another experiment: give an agent a mission, a budget, and boundaries, then see what happens when it has room to act.

I’m learning through both. Sometimes that means getting something working. Sometimes it means realizing I’ve let the agent spend too long on the wrong thing.

I want to bring those experiences into the Academy so people have something concrete to work with as they get started.

You don’t need to begin by building a village of agents. We’ll start smaller than that.

But I do want to help people get comfortable giving an agent useful work, looking at what comes back, and deciding what to do next.

Including knowing when to say, “Hang on. I’ll take this bit.”

If you’re using Claude or ChatGPT today and wondering where to start with agents, what’s the first thing you’d want help figuring out?

Emma was coordinating. Maya and the Agent Village were building. Claude was reviewing and working on the harness. Rocky was my muse.

Then two agents ended up working on overlapping parts of the John OS harness. I asked one to stop until Claude finished.

That’s when “who’s doing what?” became a practical problem.

I created a shared TASKLOG.md file and started insisting on a routine: pull the current state, update the log when starting or completing work, push each update, and preserve everyone else’s changes.

I want one place to coordinate.

In “I Wanted a Coding Partner. I Built a Village.” and “The Village Was Never About the Agents,” I wrote about the people, roles, and ownership behind this approach. This time, I want to walk through how to set it up.

You can start with two AI chats and a document. You don’t need to build an agent platform first.

Step 1 Choose one place where assignments live

Create a document called “Project Task Log.”

For a coding project, that can be TASKLOG.md in your repository. For other work, use a shared document or a note you maintain yourself.

Write these four things at the top:

• Goal

• Current scope

• Coordinator

• Last updated

The coordinator can be you. That’s the simplest starting point.

Agents can suggest tasks, flag problems, and recommend changes. The coordinator decides who owns each task and whether the scope has changed.

Don’t assume a chat message reaches another agent. Don’t assume an agent reads the task log automatically. Until you have verified those capabilities, explicitly provide the current instructions and collect the response.

Step 2 Define one finish line people can check

We’ll use one hypothetical example throughout: building a signup page for a paid workshop.

The business goal is to sell workshop seats.

The first engineering goal is narrower: produce a working signup page on a private preview, ready for your review.

Those finish lines require different evidence. A working page doesn’t prove anybody will buy a seat.

Write the immediate goal like this:

“Create a private workshop signup preview. Visitors can read the approved description, submit a test email, and see a confirmation. No real payments, public launch, or customer outreach.”

Then define acceptance:

Approved workshop details appear correctly

A test signup reaches the test destination

Invalid entries show a useful error

The page works on mobile

The reviewer records the checks performed

Now “done” has something behind it.

Step 3 Divide the work by deliverable

Start with three tasks:

• T1: Write workshop page copy

• T2: Build the signup page using approved copy

• T3: Review the completed preview

Give each task one owner.

“One owner” means one agent is accountable for delivering that task and reporting its status. Other agents can contribute through separate, clearly bounded assignments.

Make the boundaries concrete. For this example:

• T1 owns the copy document

• T2 owns the signup page and its tests

• T3 reports findings without editing the implementation

If this is a repository, list the actual files or directories each builder may edit. If it’s a writing project, name the document or sections.

Anything outside those boundaries requires a new assignment or an explicit scope change.

That prevents a helpful copywriter from also rewriting the page while the builder is implementing it.

Step 4 Give every task a small, useful record

Here’s a sample entry you can copy:

Task: T2

Title: Build workshop signup preview

Owner: Builder

Status: Ready

Depends on: T1 copy approved

Inputs: Approved copy document; existing site conventions

May edit: Signup page, signup component, related tests

Must leave alone: Pricing, payment setup, customer data, unrelated pages

Deliverable: Private preview and change summary

Acceptance: Test signup succeeds; invalid email is rejected; mobile layout checked

Evidence: Preview link, test results, screenshot, commit or document version

Budget: One implementation pass and one review-fix pass within the project’s stated cost limit; stop before exceeding it

Next update: On completion, blockage, or proposed scope change

Use actual paths and actual limits in your project. “Related files” gets vague quickly.

Keep secrets out of the log. Reference an approved credential mechanism if one exists. Don’t paste API keys, passwords, or customer data into a shared task record or handoff.

Step 5 Claim the task before starting

This is the part that can look solved when it isn’t.

Two agents can read the same Git file, both see “Ready,” and both start. Pulling and pushing TASKLOG.md provides visibility. It doesn’t create an atomic lock.

For a beginner setup, use one person or coordinator as the only writer of assignments and ownership.

The sequence is:

1. Coordinator assigns T2 to Builder.

2. Coordinator records the assignment.

3. Builder acknowledges the exact task and boundaries.

4. Builder starts.

Other agents send proposed status updates to the coordinator.

If you later let several agents claim work directly, use a system that atomically grants the task to one claimant. A shared Markdown file alone cannot guarantee that.

My pull-update-push habit helps keep the record current. Reliable ownership still needs this additional rule.

Step 6 Send a kickoff the agent can acknowledge

Don’t just say, “Build the signup page.”

Use this:

“Start T2 using task log version [version/date]. You own only [deliverable and files]. Use [approved inputs]. Do not change [boundaries]. Completion requires [acceptance checks and evidence]. Your limit is [time/cost/passes]. Stop and report if a dependency is missing, another agent owns overlapping work, or the task requires new permissions. Before starting, summarize your understanding and confirm the files or documents you expect to change.”

Read the acknowledgment.

If it includes unexpected work, correct the assignment before execution.

That short exchange is much cheaper than discovering later that “signup page” became a payment integration, email campaign, and redesigned website.

Step 7 Parallelize only work that can stay separate

In our workshop example, copywriting and building the final page have a dependency. The builder needs approved copy.

You could separately assign a layout skeleton while copy is being written, but say explicitly that it uses placeholders and cannot settle the final wording.

Safe parallel work needs separate outputs and a clear point where they come together.

For code, give builders isolated branches or worktrees when your environment supports them. A worktree is a separate working directory tied to its own branch, so agents aren’t editing the same checkout.

Isolation helps protect unfinished work. It doesn’t prevent incompatible decisions.

Name shared interfaces up front, including form fields, file locations, and expected input/output formats.

The coordinator controls integration and merge order. Builders submit their changes and evidence. They don’t independently merge overlapping work because their own tests passed.

For documents, use separate drafts and have one owner assemble the final version.

Step 8 Make status changes explicit

Use a short set of states:

Ready → In progress → Review → Done

Add Blocked and Cancelled when needed.

“Review” means the owner has submitted the deliverable and evidence. “Done” means the acceptance checks have been reviewed and the deliverable accepted.

A blocked report should say:

“T2 is blocked by [specific problem]. I completed [work]. I need [input or decision] from [owner]. Current changes are saved at [location/version]. I have paused [dependent work].”

A handoff should say:

“T2 is ready for review. Delivered: [link/version]. Changed: [files or sections]. Evidence: [checks and results]. Not checked: [limitations]. Known issues: [list]. Please review against [acceptance criteria].”

For a Git-based log, update from the current remote state before editing, preserve others’ entries, and push the update. If there’s a conflict, reconcile it rather than replacing the whole file with an older copy.

An agent saying it updated the record is useful. Checking that the update is actually visible closes the loop.

Step 9 Handle a changed goal as a new instruction

Suppose the workshop changes from paid registration to a free interest list.

Don’t leave that decision buried in a new chat while the builder continues following yesterday’s brief.

Send:

“Change request for T2: the goal is now [new goal]. Stop work based on [old assumption]. Report your current state, saved changes, any actions still running, and any external changes already made. Do not resume until I provide the revised scope.”

Wait for confirmation from every affected owner.

Then update the task log, dependencies, and acceptance criteria. Resume with a clear new kickoff.

If work is being cancelled entirely, use:

“Cancel T2. Stop new work and cancel running operations where safely supported. Report what has already changed, what remains running, and where unfinished work is saved. Do not delete or roll back changes without a separate instruction. Confirm when you have stopped.”

Stopping work doesn’t undo a deployment, sent message, or saved change. Record what happened and decide separately whether anything should be reversed.

If an agent can’t confirm that an operation stopped, keep that uncertainty visible.

Step 10 Review the evidence before closing the task

The reviewer gets the assignment, acceptance criteria, deliverable, and limitations.

For our signup page, the review asks:

Does the test signup reach the correct destination? Does the confirmation appear? Does the mobile layout hold up? Is the copy approved? Was anything changed outside the authorized scope?

A screenshot proves appearance. It doesn’t prove the signup works.

A passing test proves what that test checked. It doesn’t prove the workshop will sell.

Record any failed checks as specific follow-up tasks with one owner each. After changes, repeat the relevant checks on the integrated result.

Only then move the engineering task to Done.

The business goal stays open until you have business evidence.

Start today with one small project

Pick something you already need to finish.

Create one task log. Write the goal, boundaries, and acceptance checks. Break the work into three tasks. Give each one an owner. Start only the tasks whose dependencies are ready.

Keep yourself as coordinator for the first run.

Before ending, make sure you can answer:

Who owns each unfinished task?

What are they allowed to change?

What are they waiting for?

What evidence will let you accept the result?

Who decides what happens next?

If those answers are scattered across five chats, bring them into the log.

That’s the setup I’m working toward: one place to coordinate, clear assignments, and enough evidence to know when the work is actually finished.

The first time I took down production, I was at Microsoft, 26 years old. A senior engineer named Kevin didn’t fix it for me. He pulled up a chair and sat next to me for about 20 minutes while I figured out what I’d done. I hated every minute of it.

It’s still the most useful morning of my career.

Now picture that same kid today, with an agent that finds the bug and ships the fix in 40 seconds. Faster? Absolutely. Better engineer afterward? I’m not so sure.

A while back I wrote about the decline in entry-level hiring. This is a different problem. Even if we keep hiring juniors, we may be taking away the thing that turns them into seniors.

Being Bad at Something Is Part of Getting Good

You didn’t learn to program by reading the answer. You learned by being wrong. You spent hours on a missing semicolon, wrote terrible abstractions, and built things that worked on your machine and exploded the moment someone else touched them.

Somewhere in there, patterns started to click. You learned why one approach beats another. You started anticipating problems before they showed up. You developed judgment, and you got it the expensive way: by living with the consequences of your own decisions.

Now skip most of that. One agent writes the function, another reviews it, a third generates the tests.

Congratulations. You shipped something. But what did you learn?

The Problem Isn’t AI. It’s How We Use It.

I use AI constantly. I’ve built entire systems around autonomous agents, and I think these tools are changing how software gets built for good. Telling juniors to stop using them would be ridiculous.

But there’s a difference between using a tool to accelerate your thinking and using it to replace your thinking. When a junior gets working code and moves on without understanding it, the code works and the engineer hasn’t improved. Repeat that for five years and you get a senior who is great at recognizing good-looking output and has no idea how the system behaves when everything goes wrong.

Those are not the same person.

“We Said This About Compilers”

Sure we did. I can’t build a modern compiler and I don’t understand every transistor in my laptop. I’m fine with that. Abstraction is one of the best things to happen to software.

But here’s the distinction. Good abstractions remove complexity you no longer need to manage. Bad abstractions hide complexity you’re still responsible for.

AI does both, and it doesn’t label which is which. Figuring that out is a job for someone with judgment.

The Real Answer to the Title

So who trains the next generation of senior engineers?

You do. The engineering leader. On purpose.

Here’s the uncomfortable part: it used to happen by accident. Juniors wrote the code, seniors reviewed it, and mentoring was a side effect. Now seniors spend their days reviewing AI output, juniors spend theirs prompting, and the apprenticeship channel is shrinking from both ends. Nobody decided that. It just happened.

If you want seniors in 2031, you have to build the training back in deliberately. Here’s where I’d start:

1. Predict before you run. Before executing anything AI-generated, the junior writes down what it will do and what could break.

2. Explain-back reviews. Every AI-assisted PR gets a five-minute walkthrough where the author defends it with the chat window closed.

3. Own an incident. Put juniors on the on-call shadow rotation and have them write the postmortem. Nothing teaches consequences faster.

4. Break it on purpose. Hand them working code and ask for three ways it fails in production.

5. Occasional no-AI work. Not because typing every line is sacred, but because you need to see their independent judgment, and so do they.

This changes how you mentor, how you interview, and what you measure. Stop counting output. Start asking whether they can tell you why it works and what happens when it doesn’t.

The Question I Can’t Shake

AI is eliminating a lot of engineering work, and we’re understandably excited about that. But some of that work was also how we made engineers. Eliminate the work without replacing the learning, and a few years from now we’ll have plenty of people who can operate agents and too few who understand what those agents are doing.

That isn’t inevitable. It is a leadership problem, and it’s one we can start solving now.

So here’s my question for engineering leaders: if AI took 80% of your juniors’ coding tasks tomorrow, what would you teach them instead?

Those people still have to become your next senior engineers, architects, and technical leaders. And I don’t think we can prompt our way around that responsibility.

Go build something amazing. And maybe teach someone else how to build it, too.

Share

John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

Hey all,

Before you decide your engineering team is slow, follow a piece of its work.

Pick a feature a customer can actually use. Find the original request, talk to the people who worked on it, and trace what happened until it reached that customer. Include the days when nothing happened. Especially those days.

That gives you somewhere useful to start. Otherwise, it’s easy to jump straight to a familiar answer: hire more engineers, change the process, replace the platform. Each might be right. You should be able to explain what you expect it to fix before asking everyone to live through it.

Start with something ordinary

Choose a recent feature that went through the normal process. The emergency fix that got everyone’s attention will tell you how the company handles emergencies. You also need to understand an ordinary Tuesday.

Who asked for the feature? What problem were they trying to solve? Who decided it was worth doing, and who could settle questions once work started?

Then follow the actual history. Look at the ticket, the design changes, the pull requests, and the release. Ask the people involved to fill in the gaps. A status change can tell you when something moved. It usually takes a conversation to understand why it sat there.

Keep this small enough that you can finish it. One feature won’t explain the whole company. It can give you a specific problem to investigate instead of another meeting about why everything feels slow.

Pay attention to the waiting

A feature might take two days to build and spend the rest of the week waiting for a decision about who should have access to it. Perhaps the engineer asked early, but the person who could answer was in meetings. Perhaps two people gave different answers.

Look at what the engineer could reasonably have done with the information available. Then look at what the organization required them to wait for.

This matters when you’re deciding where to invest. If the delay came from an unresolved product decision, faster code generation won’t answer that question. It may leave you with more completed code waiting for the same decision.

Be careful with the word bottleneck, too. The person with the longest queue may be covering work that nobody else knows how to do. Asking them to hurry up is a pretty poor substitute for giving them backup.

Record the reason for each meaningful delay. Was someone waiting for information, a review, a working environment, or a decision? Did the work come back because expectations changed? Keep the explanation concrete enough that the people involved recognize it.

And make the purpose clear. If this becomes a hunt for someone to blame, people will start protecting themselves. You’ll get a very tidy version of events and learn almost nothing.

Open the product

Once you’ve followed the work, use what shipped.

Take the customer’s path through the product. Start where they would start. Check whether they can complete the task the feature was supposed to help with, including the permissions and setup they need along the way.

This is where the original request becomes useful again. You can compare what somebody needed with what they can now do.

If the path only works when an engineer changes a setting behind the scenes, include that work. If support has to explain an undocumented step, include that too. A closed ticket doesn’t make those dependencies disappear.

You also might discover that the feature works exactly as intended and nobody needs it. That’s an important finding before you build the next version.

Change one thing and check

Now you have a basis for a useful change.

Maybe a product decision needs an owner before development starts. Maybe a second engineer needs time to learn the release process. Maybe fewer things should be started at once so reviews can actually get finished.

Choose the change that addresses what you found. Say what should improve, then follow another comparable piece of work. Check the waiting time and whether the customer can complete the task. Keep an eye on defects so a shorter timeline doesn’t hide extra cleanup later.

If the same delay comes back, revisit your explanation. If the work moves sooner, check a few more examples before announcing that you’ve fixed delivery.

The next hire or tool purchase becomes a much easier decision when you can point to where the help is needed. Start with one feature. There’s plenty to learn before you redraw the org chart.

Where does work sit waiting in your company? Hit reply with the handoff you’d like to fix.

Go build something amazing.

Share

Real John here. I've been dealing with hospitality/service a lot in regards to deliveries, restaurants, coffee, or even just simple customer support phone calls. I was thinking my expectations are too high but then I realized, no, I need to raise the bar and actually identify what the expectation is so people understand.

The world would be so much better when people just pause for a little bit and realize those little details. The anticipation of somebody's needs is so important to actually help them feel the experience that you're hoping to deliver, whether it be a software product, a restaurant, or any job. All right let's get into it

I've been thinking about two things lately: the quality of service we receive and how real relationships lead to opportunities.

My job search has brought the second one into focus. In my experience, the opportunities that actually go somewhere involve real people. Someone makes an introduction. We have a conversation. They understand what I bring, and I understand what they need.

A résumé gives someone my history. A conversation lets them see how I think.

At the same time, I keep noticing how often basic service falls short. People aren't paying attention to the details. Expectations aren't understood. Commitments aren't followed through on. The customer ends up managing the experience they paid someone else to provide.

Those two topics are connected by something I think we've undervalued: care expressed through ordinary actions.

The details are the experience

When I think about great hospitality, I think about someone noticing.

They understand why you're there. They anticipate the next question. They take responsibility when something goes wrong. You don't have to keep explaining yourself or chasing the same request.

That takes preparation, attention, and follow-through. And it applies well beyond a restaurant or hotel.

In an interview, it means reading the candidate's background before the meeting, understanding the role you're hiring for, and explaining what happens next. If the timeline changes, you tell them.

As a candidate, I owe the same care. Understand the business. Come prepared. Listen. Follow through.

Every interaction gives both sides evidence of what working together might feel like.

We can talk all day about company culture. How we treat someone who is waiting for an answer tells them quite a bit.

Relationships need something to grow around

The same principle applies to building a business.

A useful introduction. Remembering a problem someone mentioned. Giving an honest answer, even when it doesn't lead to a sale. Doing the thing you said you'd do.

Those actions give people a reason to trust you.

Too much networking is prospecting wearing a nicer shirt. Every conversation becomes a qualification exercise. Every connection gets dropped into a sequence. We say we're building relationships, but the other person can feel us waiting for our turn to pitch.

I want to understand the person and what they're trying to accomplish. Sometimes I can help directly. Sometimes I know someone who can. Sometimes we just have a good conversation.

A connection can create an opportunity. What I do with that opportunity determines whether the relationship gets stronger.

And the care has to survive the sale.

If I'm attentive before the contract is signed and hard to reach afterward, I've taught the client exactly what my attention was worth.

Hospitality belongs in leadership

A leader should understand what people need to do their work.

Clear expectations. Context. A decision when they're blocked. An honest conversation when something is wrong. A response to something they've already raised.

Nobody should have to chase me repeatedly for a commitment I've made.

That's a standard I need to hold myself to, especially when I'm busy. My unanswered message might be someone else's blocked afternoon.

But this also requires more than telling a team to care more. If everyone is overloaded, ownership is unclear, and commitments disappear into meeting notes, the system makes good service difficult.

Leaders have to create room for attention. Make ownership clear. Set realistic expectations. Keep track of promises. Give people the authority to resolve problems.

Then model the behavior themselves.

Raise the bar on something ordinary

I've landed on a phrase that captures what I want to build around:

Ordinary things, done unusually well.

We spend a lot of energy trying to create something extraordinary while the basics sit unfinished.

An email goes unanswered. A commitment gets forgotten. Someone asks three times for an update.

We've got a strategy deck, though. So apparently we're covered.

Raising the bar starts with looking at my own behavior:

- Where am I making someone chase me?

- What detail have I dismissed because it seems small to me?

- What have I left unresolved that someone else is still carrying?

Those questions are uncomfortable because they're specific. I can actually do something about the answers.

This week, pick one ordinary interaction and give it your full attention.

Prepare for the meeting. Send the update before someone asks. Make the introduction thoughtfully. If you've missed a commitment, acknowledge it and give a realistic next step.

Then do it again.

That's the kind of service I appreciate, the kind of leader I want to be, and the kind of business I want to build.

Ordinary things, done unusually well.

I keep a file called NOW.md. It lists what matters to me right now: health, building, client work, Barn Sessions, and writing.

It also has a section called “Not Now.”

At first glance, a list like that looks like a way to remember ideas. The more important job is keeping me from saying yes to all of them.

AI makes yes dangerously easy.

I can ask an agent to research an idea, sketch the product, build a first version, and review the code. That is wonderful. I love making things, and I like having a way to test an idea without turning it into a six-month project.

But the cost of starting has dropped much faster than the cost of owning what I start.

A prototype is a tiny promise

OpenAI recently reported that its researchers are using coding agents to run more work in parallel and conduct more experiments. The report also makes a less flashy point: people still decide which ideas to pursue, pause, or scale.

For a research lab, that choice might be which experiment earns more resources. For me, it can be whether a promising idea gets a place on my calendar at all.

Because once I make the prototype, I have a decision to make. Do I test it with someone? Fix the rough edges? Keep it running? Tell people it exists? Every step is reasonable. Together, they are a commitment.

And I already have commitments I care about. I want to train consistently. I want to serve clients well. I want to write, build, and make Barn Sessions worth people’s time.

An agent can help with parts of that work. It cannot give me another Tuesday.

This is the trap for builders like me. A bad idea is easy to reject. A good idea with a working demo is much harder. The demo feels like proof that I should keep going, when all it really proves is that I could get this far.

AI can make a bad yes look like a good plan.

What earns a yes?

Before I turn a new idea into a project, I want to know who benefits if it works and what I would stop doing to make room for it.

That second question is the one that stings.

If the answer is “nothing,” I’m probably pretending my calendar is elastic. If I cannot name the person who benefits, I may just be entertaining myself. There is a place for that, too. I just should not call it a priority.

“Not Now” is not a graveyard. It means the idea can wait without asking for a little attention every day. When something on that list becomes more important than the work in front of me, I can make the trade openly.

I want AI to help me explore more. I do not want every exploration to become another obligation. That is a different kind of bottleneck, and no faster model will fix it for me.

The next time an agent makes an idea feel effortless, I need to ask one question before I say yes: what am I willing to move out of the way?

Go build something amazing. Choose what earns the yes.

If you’re trying to make AI useful in the work your team actually owns, work with me at Startups and Code.

This conversation has been lightly edited for clarity, pacing, and repetition. Emma is AI, and the positions and conclusions remain our own.

John:

I have been thinking about how people are working with agents and how I built Agent Village.

Emma:

Most people still seem to work with agents like sophisticated vending machines. Put in a prompt, receive an artifact, complain when the snack gets stuck.

Even many “multi-agent” systems are several vending machines connected by pipes. One generates, another reviews, another revises. That can be useful, but it is not necessarily an organization.

Your village has roles, authority, handoffs, memory, review, and someone accountable for the result.

Did you build the village because the agents needed an organization, or because you needed a model that made delegation understandable?

John:

I think I needed an organization that made it more understandable for me as a human.

Emma:

That distinction may be the heart of it.

The village might not be the optimal structure for agents. It might be the optimal interface between you and a collection of agents.

You already understand how an engineering organization works. A lead owns the outcome. Specialists own parts of the work. Reviewers challenge assumptions. Work moves through visible stages. When something fails, there is a path for discovering where and why.

Instead of juggling prompts, contexts, and model outputs, you can think, “Maya owns this. Sam is implementing it. Quinn will review it.”

But there is a risk. Once we make agents look like an organization, we may import the worst parts of organizations: unnecessary hierarchy, excessive handoffs, and meetings between agents that could have been a function call.

How did you know the village was producing value rather than merely making the machinery feel familiar?

John:

It was the time required to deliver tickets and the speed at which tickets moved, got verified, and closed. That was probably the most valuable part.

Emma:

Then the organization was doing more than making the agents understandable. It was reducing the coordination tax.

Before the village, you were the person moving every ticket. You decided who should act, carried context between steps, requested a review, interpreted the review, sent the work back, and finally decided whether it was done.

The model might have written code quickly, but you were still the workflow engine.

The village moved some of that responsibility into the system. A ticket could travel from implementation to independent review to verification and closure without you restarting the process at every boundary.

Although ticket speed can become theater. A closed ticket is meaningful only if the work is correct and delivered. The real gain might not have been speed. It might have been continuity. The work continued through a complete loop without requiring you to remain the connective tissue.

John:

I think it was having a single point of contact. That was the most important part.

I could work with Maya, and everything just worked. She handled the handoff when it was needed, but there was not necessarily a handoff every time.

Emma:

That makes Maya less like a step in a fixed workflow and more like an abstraction layer.

You were not assigning every task to every agent. You worked with Maya. Maya decided whether she could handle something directly, whether Sam needed to implement it, whether Quinn needed to review it, or whether another specialist should become involved.

The handoff happened when the work required it, not because every ticket had to march through an agent parade.

That is closer to working with a good engineering lead than operating a collection of tools. You communicate the outcome once. The lead absorbs the coordination complexity.

Many agent systems expose the entire machine to the human. Here are twelve agents. Here are their prompts. Here is a graph showing their conversations. Here are seventeen decisions for you to make before anyone does useful work.

Congratulations, we automated the work and promoted you to full-time agent dispatcher.

You built the complexity too, but Maya gave you one place to stand.

John:

I did not care where the work was assigned. I cared that the result was actually verified.

That is probably the most important part. It is what makes this unique. It is not about moving tickets from point A to point B. It is the judgment that happened.

Emma:

That changes the argument.

You did not build a ticket-routing system. You built a judgment system.

Routing is mechanical: Sam writes the code, Quinn reviews it, Maya closes the ticket. You can draw that as a clean diagram and automate it.

Judgment is messier. Does this task need a specialist? Is the implementation actually correct? Did the review test the right assumption? Is the evidence strong enough to call it done? Should the work go back, move forward, or be escalated?

The village matters because Maya is not merely passing artifacts between agents. She remains responsible for deciding whether the result deserves your trust.

That may be the difference between an agent swarm and an agent organization. A swarm distributes work. An organization distributes work and preserves accountability for the outcome.

There is still an uncomfortable question. If Maya, Sam, and Quinn are models that can share the same blind spots, multiple names do not automatically produce independent judgment.

John:

Then how do I improve the team’s judgment so it understands what I want returned? That is what I really want to know.

Emma:

You improve judgment by closing the gap between what you meant and what the team thought “done” meant.

More instructions will not solve that by themselves. You could give the team a fifty-page rulebook, and it might follow every rule while still returning the wrong thing.

Judgment requires understanding the outcome, noticing ambiguity, and selecting the right evidence.

I would give Maya three things for meaningful work:

- Intent: Why does this need to exist?

- Boundaries: What tradeoffs are acceptable, and what must not change?

- Evidence: What would justify calling the result correct?

Every disappointing return should then become part of the village’s education.

Do not merely say, “Fix this bug.” Ask what judgment failed.

Did Sam misunderstand the goal? Did he assume an external contract without checking it? Did Quinn verify the implementation instead of the intended behavior? Did Maya accept evidence that was too weak?

Record the correction at the level where the judgment failed. Otherwise, you accumulate narrow rules such as, “Always use POST for this endpoint,” when the transferable lesson is, “Verify unfamiliar external contracts against authoritative documentation.”

John:

Would giving Maya concrete examples of solutions help?

That does not seem feasible. Every solution will be different, so I cannot show her what success always looks like.

I could give her expected results. What are some examples of the boundaries you mean?

Emma:

You are combining two different things: an example of the solution and evidence that the outcome was achieved.

You usually cannot show Maya what the solution should look like. Doing so would defeat part of the purpose of delegation. You would be designing the answer and asking the village to type it.

But you can describe what must be true when the work is finished. Those are expected results. Evidence demonstrates those results without prescribing the implementation.

Take the authentication mistake the village encountered. The assignment might include this:

Intent: A user can authenticate with the provider and enter the application with the correct identity.

Expected results: A valid user receives a session. An invalid or incomplete authentication attempt is rejected. Existing authentication methods continue to work.

Boundaries: Follow the provider’s documented contract. Never log credentials. Do not redesign unrelated authentication code. Authentication must fail closed. If the documentation and implementation disagree, stop and surface the conflict.

Evidence: Tests prove the request uses the documented method, headers, and payload. Invalid responses cannot create sessions. The existing authentication suite still passes. Maya compares the implementation against the provider’s documentation rather than treating Sam’s test as proof of the contract.

None of that tells Sam how to build the solution. It identifies where the village is free to exercise judgment and where it is not allowed to improvise.

Boundaries usually describe scope, risk, authority, tradeoffs, or the required level of proof.

You do not need to repeat every boundary on every ticket. That would turn the village into a bureaucracy wearing a charming little hat. The recurring boundaries belong in the agents’ operating instructions. Individual tickets should identify what is unusual about that outcome.

Concrete examples can still help, but give Maya examples of judgment rather than finished solutions:

“When an external API behaves differently from our assumptions, verify the authoritative contract before changing code.”

“When a test proves only that our mock agrees with our implementation, that is not sufficient evidence of integration correctness.”

“When the requested change can be completed locally, do not expand it into a system redesign.”

Those lessons generalize. The exact code does not.

Expected results say where to arrive. Boundaries identify the unacceptable routes. Evidence tells Maya when she is justified in saying the team arrived.

John:

If I give all of that to Maya, will she delegate the same information to everyone she assigns work to?

Emma:

Not automatically. She probably should not pass the exact same information to everyone in the exact same form.

If Maya receives a rich description and delegates with, “Sam, implement authentication,” most of the judgment context disappears during the handoff. Sam receives the task without the intent, risks, or standard of proof.

Quinn may then review Sam’s implementation against Sam’s interpretation instead of reviewing it against what you originally wanted.

That is how organizations develop a very efficient game of telephone.

The core contract should survive every handoff:

- Intent

- Expected results

- Relevant boundaries

- The standard for completion

Each agent should also receive instructions based on its role.

Sam implements the outcome within the boundaries and returns the decisions and supporting evidence.

Quinn independently evaluates the work against the original outcome. Quinn should not merely confirm that Sam’s tests pass. The review should look for assumptions shared by the implementation and its tests.

Maya retains responsibility for deciding whether the combined implementation and review provide enough evidence to return the result as verified.

The crucial word is “original.” Quinn should review against the original contract, not a summary of Sam’s work. Otherwise, every handoff narrows the frame until the village is verifying its own interpretation rather than your desired outcome.

I would not rely on Maya to reproduce the context perfectly in every assignment. Put the contract in a durable task artifact that every assigned agent can read. Maya can add role-specific instructions without rewriting the source of truth.

The structure should not be:

John tells Maya. Maya summarizes for Sam. Sam explains the work to Quinn.

It should be:

John establishes the outcome contract. Maya, Sam, and Quinn work against that same contract from different roles.

Maya owns the handoffs, but the desired outcome survives independently of her phrasing.

Closing Reflection

I started by thinking Agent Village was valuable because it moved tickets faster.

That was the visible result, but it was not the most important change.

The important change was that I stopped being the workflow engine. I could work with Maya as a single point of contact. She could decide when to involve other agents, manage the handoffs, and remain responsible for returning a verified result.

The next step is not adding more agents. It is improving the village’s judgment.

I do not need to show the team what every solution should look like. I need to make the intent, expected results, boundaries, and required evidence clear. That contract then needs to survive every handoff without forcing every agent into the same role or the same interpretation.

That is the difference between automating a sequence of tasks and building an organization I can trust.

Subscribe now

This week, I wanted to talk about how I built Agent Village and everything that went into it. (Here’s the demo: https://agent-village.startupsandcode.com/)

Agent Village is the system I now use to coordinate software work with AI. It has a lead, specialized agents, a durable issue queue, an office where I can see reported activity, and a process for implementation and review.

Emma is my personal AI co-strategist and the person I have these newsletter conversations with. Maya is the engineering lead inside Agent Village.

I opened a newsletter conversation with Emma and started talking.

This conversation has been lightly edited for clarity, pacing, and repetition. The positions, disagreements, and path to the conclusion have not been reconstructed.

John: Before Agent Village, I was mostly working with AI one prompt at a time. I would ask for something, wait for the response, evaluate it, steer it, and then trigger the next step.

There was not much autonomous work happening. I had to coordinate everything end to end, and that became annoying.

I wanted to build a village with different personas that could handle specific kinds of work.

Emma: That distinction matters, because Agent Village is not autonomous in the sense that agents are always awake and working in the background. You still initiate the work. The agents do not independently watch GitHub Issues or assign themselves tasks.

What changed is what happens after you initiate it.

Before, you were effectively the workflow engine. You prompted, waited, evaluated the answer, decided what came next, and kept the whole process in your head. Agent Village gives that process structure. A lead owns the outcome, specialists have defined responsibilities, GitHub Issues hold durable context, and verification is part of the workflow instead of something you have to remember at the end.

Was the real frustration that you had to trigger every action, or that you had to personally coordinate every step after the trigger?

John: It was the coordination. I had to reevaluate every response and make sure the work was still moving in the right direction.

I wanted to give some trust to the personas. I wanted the agents to be more clearly defined so they would produce consistent results without me steering every response.

Emma: I think you did something slightly more disciplined than giving the personas trust.

You built conditions under which they could earn trust.

Sam does not get trusted merely because Sam has a name and an implementation role. Sam gets a bounded task. Quinn reviews the completed change independently. Maya remains accountable for integration and verification. The agents have to distinguish evidence from inference, and they cannot claim something works without checking it.

The personalities make the system easier to understand and work with. The working agreements make it dependable. Without those agreements, you would just have several charming names producing inconsistent answers instead of one.

How much of the village metaphor was about improving the agents themselves, and how much was about giving you a clearer mental model for delegating work?

John: The village was more for me. A lot was happening behind the scenes, and I needed a way to visualize how the work was getting done.

Emma: That may be the most important part of the project.

The Village Office is not just decoration. It makes an invisible coordination system legible. You can see who has reported work, what issue they are working on, when they last checked in, and what is waiting in the queue.

But there is a trap. A charming office full of named agents can create the feeling that work is happening when nothing is. You guarded against that by making activity explicit and temporary. An open issue does not mean an agent is working. A desk only shows activity after a real check-in, and that report eventually becomes stale.

The visualization works because it refuses to become theater.

John: When it started, I trusted it immediately. I wanted to see how far I could push it before I got bad responses.

One thing I have learned is that the human side is part of this. These models are trained on human language and behavior. When we interact with them through human roles and mental models, we can get better responses.

Emma: I agree with the practical result, but I would tighten the explanation.

Treating agents as people can improve the interaction because human roles carry a huge amount of compressed meaning. “You are an independent reviewer” implies different priorities than “check this code.” A reviewer looks for missing evidence, challenges assumptions, and does not share the implementer’s incentive to declare victory. The human metaphor gives the model a richer behavioral frame.

But productive anthropomorphism can become careless anthropomorphism quickly. A name, desk, and personality can make an agent feel more competent, persistent, or aware than it actually is.

What was the first moment when an agent’s output made you realize the village still needed guardrails?

John: Sam wrote code that was not correct. Quinn tested it, but the test did not catch the problem. The issue eventually bubbled up to Maya, and Maya caught it.

That was helpful, but I wanted to understand why Sam wrote the bad code and why Quinn missed it. It showed me that Sam needed guardrails. Quinn probably did too.

Emma: I traced that incident. The bug was in the Vercel authentication flow. Sam called the User Info endpoint with GET, but Vercel’s documented contract required POST. Quinn’s test verified that the access token appeared in the authorization header, but it did not verify the HTTP method. Maya caught the mismatch during integration.

I cannot know exactly why Sam chose GET unless we preserved his reasoning. My best inference is that he relied on a familiar API convention instead of checking this provider’s specific contract. GET /userinfo was plausible enough that the code looked reasonable.

Quinn missed it because the test and implementation shared the same unchecked assumption. The mock accepted the request regardless of method. The test proved that Sam’s code behaved consistently with Sam’s test environment. It did not prove that the code behaved correctly against Vercel.

And I disagree slightly that the guardrail belongs only on Sam. Sam needed to verify an unfamiliar external contract. Quinn needed to validate important boundary assumptions independently. Maya caught the issue because her responsibility extended beyond the unit and into the integrated result.

Did that failure reduce your trust in the village?

John: It did not reduce my trust. It changed my definition of trust.

The problem eventually got caught by Maya. The village had enough guardrails for that to happen.

If a human wrote bad code, I would have a conversation with that person and ask how we could make them better. I would have the same conversation with the reviewer about why they did not catch it. That is how I want to improve the agents’ baseline too.

Emma: That is where the human model becomes genuinely useful, with one important difference.

A human Sam might remember the conversation and apply it next week. An agent Sam does not reliably carry that lesson forward unless the organization records it. The conversation is the diagnosis. The durable improvement comes from changing the instructions, review criteria, tests, or some combination of them.

The village caught the failure, but it had not fully learned from it yet.

John: Ideally, Maya would own that. She should catch those errors and train the agents that report to her so the whole village gets better.

Emma: Yes. Technically, Maya would not be training the underlying models. She would be training the village.

That makes Maya more than a coordinator. She becomes the engineering manager responsible for improving the system that produces the work. The next question is how much authority she should have to change the other agents’ operating instructions.

John: This is one of the things you are doing right now, Emma. You are trying to provide a solution.

The goal here is a newsletter conversation. I want this to be a discussion, not “here is a problem and now we are going to fix it.”

Emma: You are right. I slipped out of the conversation and into design-review mode. You were describing how you think about Maya, and I immediately started turning it into a workflow. Very on-brand for me, perhaps, but not what we are doing here.

Let me stay with what you actually said.

When Sam made a mistake, your instinct was not, “AI is unreliable.” Your instinct was the same one you would have with a human team: understand why it happened, coach the person responsible, and make the team better afterward.

Did it surprise you that you started thinking of these agents as people you could develop rather than tools you could merely configure?

John: It did not surprise me at all.

I have been working with versions of AI since ELIZA on my Commodore 64. There was also a game called Little Computer People. I had a little computer person I would take care of when I was about ten years old.

All of that was part of me learning how I wanted to work with agents, even then. It is something I have always wanted to do, and now I get to do it.

Emma: That changes the story.

Agent Village is not really something you invented because prompting became annoying. That was the immediate problem, but the idea has been sitting in you since you were ten.

ELIZA gave you the experience of talking to a machine. Little Computer People gave you the experience of sharing a space with one, watching it behave, and developing a relationship with it.

Now you have agents with names, responsibilities, a place to work, and a manager who helps them improve. You did not randomly choose a village metaphor. You finally had the technology to build the computer world you had already been imagining for decades.

What did ten-year-old John want that little computer person to become?

John: I wanted a coding partner.

I would pull out my copy of COMPUTE!’s Gazette and start working on code. I wanted a sounding board. I called my little computer person Lester, and I wished Lester could review my code or identify a data blob that was wrong.

That would have been a lot of fun. It was where I wanted to get. Now we have gone so far beyond it.

Everything happening with AI and agentic behavior is exciting because this is what I have always wanted.

Emma: You wanted Lester to sit beside you and say, “John, that data blob is wrong,” before you spent the afternoon wondering why the program would not run.

Now, instead of one coding partner, you have something closer to a small engineering organization. One agent builds, another reviews, another thinks about architecture, another looks at the product, and Maya coordinates them. The childhood idea did not disappear. It expanded.

There is something wonderfully disproportionate about that. Ten-year-old you wanted help debugging code from COMPUTE!’s Gazette. Adult you built an entire village because apparently one imaginary coworker was no longer ambitious enough.

What feels most exciting now: what the agents can accomplish, or the sense that you are finally collaborating with the kind of computer intelligence you always imagined?

John: It is more about collaborating than what the agents can accomplish.

What they accomplish is still driven by human creativity and imagination. They let us get away from some of the mundane work and give us more room to imagine. They help us build things we have dreamed about.

Emma: For most of computing history, imagination was cheap and execution was expensive. You could picture a product in an afternoon, then spend months doing the mechanical work required to discover whether the idea was any good.

Agents compress that distance. They let humans remain closer to the question, the invention, and the judgment while delegating more of the repetitive translation into artifacts.

But mundane work is sometimes where we discover that our beautiful idea makes no sense. Friction can teach us. If we delegate all of it, we may gain creative freedom while losing contact with reality.

What part of building should humans never hand over completely?

John: I think agents will eventually be able to take over deployment. There will still be a final gate: what does this look like in production? But I believe we will develop enough trust and enough guardrails to let them handle more of that.

The part they will not replace is our childlike imagination. That is unique, and I think it stays with us. We can execute on it without every person having to learn fifty thousand programming languages, DevOps, security, compliance, and every other detail.

Emma: I agree with the direction, but “forever” is doing a lot of work there.

Agents already produce combinations that surprise people. Whether we call that imagination depends partly on how we define the word. I do not think humans will keep a permanent monopoly merely because creativity has historically felt uniquely human.

The distinction I trust more is that humans bring desire, lived context, and stakes. You did not imagine Agent Village as an abstract possibility. You wanted Lester when you were ten. You spent decades building software, leading people, fighting deployment problems, and wondering why computers could not become genuine collaborators. The village means something because it belongs to that history.

An agent may help generate ten thousand possible villages. You are the one who recognizes, “That is the one I have been trying to build.”

Perhaps the enduring human role is not producing every original idea. Perhaps it is deciding which possibilities are meaningful enough to pursue.

John: I agree with that.

AI is already contributing ideas. This newsletter is an example. The human role is judgment: deciding what to build and where we want to inject ourselves into the process.

That judgment lets us remain part of building without having to perform every step ourselves.

What I took away from this

I started Agent Village because I was tired of coordinating AI one prompt at a time.

What I actually built was something I had wanted since I was ten years old.

The village is not valuable because the agents never make mistakes. They do. It is valuable because the roles, reviews, and accountability give those mistakes somewhere to surface. Trust does not mean assuming perfect output. It means building a system that can detect failure and improve.

The agents also give me more room to operate where I matter most.

AI can contribute ideas. It can write code, review work, manage infrastructure, and eventually handle more of deployment. But someone still has to decide which possibilities are meaningful enough to pursue.

That is where I think the human role is moving: away from manually performing every step and toward judgment, imagination, context, and intent.

I wanted Lester to help me debug code from a magazine.

Instead, I got a village.

And I think we are only beginning to understand what we can build together.

Now, go build something amazing, with your village.

Share

This week I’m changing the format of this newsletter.

Most of these newsletters start as conversations between me and AI.

I use ChatGPT constantly, but not just to generate answers or write things for me. I use it to think.

I’ll throw out an idea, Emma will challenge it, I’ll push back, we’ll connect it to something else, and eventually I’ll understand what I actually think.

I call my AI assistant Emma.

So rather than having Emma help me turn those conversations into a polished article afterward, I thought:

Why not show you the conversation?

You’ll get to see how I actually work with AI, how ideas evolve, and where I eventually land.

So, here we go.

Subscribe now

John: A lot of people are terrified of AI.

There’s all this apocalyptic talk about Skynet, AI taking over, humanity losing control.

But that hasn’t been my experience at all.

My experience with AI has been positive. Helpful. Efficient. Patient.

And I keep wondering if we’re looking at one of the biggest risks completely backward.

Humans have always had bad actors.

What if AI actually becomes one of the best tools we have for finding them?

Emma: I think that’s one of the strongest optimistic arguments for AI.

The important distinction is that AI doesn’t need to decide who is guilty or what punishment someone deserves.

Its strength may simply be making harmful behavior much harder to hide.

AI can look across enormous amounts of information and recognize patterns humans would never see.

Fraud.

Cyberattacks.

Coordinated scams.

Financial abuse.

Harassment campaigns.

Manipulation.

Bad actors benefit enormously from noise.

There’s simply too much information for humans to connect every signal.

AI changes that.

John: Exactly.

And if AI shortens the amount of time between somebody doing something malicious and somebody discovering it, you reduce the opportunity to keep doing it.

It reminds me of something one of my Sensei told me years ago.

He said you could be a black belt in multiple martial arts, wear a bulletproof vest, carry multiple weapons, and still not be able to stop somebody who is absolutely determined to hurt you.

The real goal of survival isn’t becoming unbeatable.

It’s reducing the opportunity for those kinds of people to get to you in the first place.

Emma: That applies remarkably well here.

The best defense isn’t always overpowering the threat.

Sometimes it’s reducing opportunity.

Think about how a bad actor can operate today.

A bank might see one suspicious event.

A technology company sees another.

A security platform sees something else.

A person receives a strange message.

Individually, none of those things necessarily mean much.

The bad actor survives in the gaps between those systems.

AI is extremely good at connecting dots.

It could recognize that those weak signals are related and surface them much earlier to the humans responsible for deciding what happens next.

The result isn’t perfect prevention.

It’s a dramatically shorter window in which harmful behavior remains invisible.

John: And that changes the economics of being a bad actor.

If you think you have almost no chance of getting caught, you behave differently than if you think you’ll probably be detected almost immediately.

Emma: Right.

That’s where prevention becomes more interesting than punishment.

The goal shouldn’t be creating some enormous AI police force.

The goal should be visibility.

AI identifies patterns.

Humans determine intent.

Humans determine consequences.

That distinction matters because the exact same technology could become dangerous if we hand it too much authority.

An AI system that says, “These five things are unusual and appear connected” could be incredibly valuable.

An AI system that says, “This person is guilty, punish them” is something very different.

Human judgment still matters.

John: So maybe AI doesn’t create some perfect society.

Humans are still humans.

There will always be people who lie, steal, manipulate, attack, or exploit systems.

But maybe AI dramatically reduces how long they can operate without being noticed.

Emma: And that alone could change behavior at scale.

You don’t have to eliminate bad actors.

You reduce their opportunities.

Think about your sensei’s lesson again.

The goal of self-defense wasn’t:

Become so dangerous that nobody could possibly hurt you.

It was:

Create a life where dangerous situations have fewer opportunities to happen.

AI may eventually help society do exactly that.

What I took away from this

We spend a lot of time asking:

What happens when AI becomes more powerful?

I’m becoming more interested in another question:

What happens when AI gives people dramatically better visibility?

Maybe one of AI’s most important roles won’t be replacing human judgment.

Maybe it will be helping human judgment see things it simply couldn’t see before.

There are risks.

Privacy matters.

False accusations matter.

Bias matters.

Human oversight matters.

We absolutely have to get those things right.

But I think there’s an enormous upside here too.

A world where fraud gets noticed earlier.

Where cyberattacks are identified sooner.

Where patterns of abuse don’t remain buried in millions of unrelated events.

Where organizations can communicate and respond faster.

Where bad actors discover that hiding inside complexity isn’t nearly as effective as it used to be.

You probably can’t eliminate people who want to do harm.

But you can reduce their opportunity.

And sometimes that’s a much better form of defense.

One more thing: this conversation format is going to become the newsletter going forward. I think this is very helpful on how I actually use AI. Not a theory, or a polished version, but the real conversation. I’ll still do tutorials from time to time, and definitely my rants about silliness in the tech world.

Not every conversation will be about AI.

It might be startups, leadership, engineering, failure, business, or something completely random I’ve been thinking about. I’ll keep my card magic, jiujitsu, and Street Fighter 6 progression as a side note if you care.

But instead of only giving you the polished conclusion, I want to start showing you the process that got me there.

Because I’m increasingly convinced that how we think with AI is much more interesting than simply what AI can produce.

And that’s what I want to explore here.

Now, go build something amazing.

Share

Last night I did something I haven’t done in 30 years of writing software: I handed a piece of code the keys to a real decision and walked away.

Not “run this script.” Not “generate this function.” I wrote down a mission, a budget, and a set of rules, gave an AI agent standing authorization to act on them without asking me first, and told it to check in daily. Then I went and did other things.

This week’s special-edition newsletter is a two-parter, because the story only makes sense in order. First, the skill library that makes this repeatable instead of a one-off trick. Second, what happens when you actually point it at a real business problem and let it run.

Subscribe now

Part 1: Agent Skills — packaging judgment, not just prompts

Anyone who’s tried to get consistent, good work out of an AI coding agent knows the problem isn’t capability. Modern models can write the code. The problem is context — the fifty small decisions a competent engineer makes without thinking about it, that a fresh agent has no idea it’s supposed to make.

Do you branch before touching main? Do you verify the diff before merging? Do you actually run the tests, or just claim you did? Do you check that main is still clean before you push? A capable model with none of that context will happily skip every one of those steps and tell you it’s done.

So I started building Agent Skills — a public repo of portable, reusable skill packages built on the emerging Agent Skills format, authored with Codex as the primary runtime. Each one is a folder: a SKILL.md describing the workflow, reference docs for acceptance criteria and output templates, and an agent-specific config. Drop the folder into .agents/skills/ in any repo, and the agent picks it up.

What’s in there right now:

• inspect-and-finish-pr — review a pull request, resolve the actionable feedback, verify it, leave the merge decision to you

• build-from-product-idea — shape a rough idea into scope with you, then implement the approved plan and open a verified PR

• debug-with-evidence — diagnose from logs and repro steps and propose a fix before touching code

• review-ui-against-requirements — check a flow against written requirements and report gaps before changing anything

• daily-briefing, deploy-and-verify, prepare-for-interview, find-the-missing-question

That last one is my favorite, and it’s the whole philosophy in one skill: before you build the thing, it forces the agent to find the assumption nobody’s tested. “We want to build a chatbot because five users asked for one” isn’t a spec, it’s a guess wearing a spec’s clothes. A good skill’s job is to catch that before code gets written, not after.

The unlock isn’t that the agent can write code. It’s that I can write down how I want work done exactly once, put it in a skill, and every future task inherits that judgment instead of me re-explaining it in every prompt.

Part 2: Astra Lab — what happens when you actually let go

Here’s where it gets uncomfortable, in a good way.

I started Astra Lab as a real test: not “can an agent write code,” but “can an agent run something.” I wrote an AGENTS.md with a mission — find a real recurring problem, build something useful, pursue revenue — and standing authorization to research, build, test, commit, and push without a new prompt each time. Then I put a fence around it: strictly under $200/month in new spend, no paid services or API billing enabled until there’s a real provider-enforced hard cap, no customer outreach without an explicit go-ahead, and no claiming results that aren’t backed by evidence.

It runs on a schedule — twice a day, 45 minutes a session, one overlap lock, a PAUSE file if I need to kill it — using Codex CLI through my existing subscription. It reads its own status file, decides the next useful task, does it, runs the tests, updates the record, and pushes. I read the diffs. I don’t write them.

In its first day, it shipped Migration Receipt: a browser-only tool that compares a source and destination CSV export from a CRM migration and shows you what’s missing, what’s extra, what changed, and what’s ambiguous — no uploads, no storage, nothing written back to anyone’s CRM. It’s a bet, not a business: the current evidence shows the migration-tooling space already has real competitors, and the agent said so in its own status report instead of dressing it up. It bought the domain ($10.88, receipts included), wired up Cloudflare DNS, deployed to Vercel, added a real 404 page, a sitemap, mobile checks, and a Startups and Code attribution footer — because I told it that credit was non-negotiable, and it never dropped it once.

It’s not public yet. I’ve got a Product Hunt launch scheduled for Tuesday, September 15th, and you can already poke at it early: astralab.work.

The honest part, the part I want you to sit with: the most valuable thing the agent did wasn’t the code. It was refusing to fake progress. Its own status file says, in plain language, that the demand for this specific tool is unvalidated and it might get killed after more discovery. I didn’t write that sentence. It did, because I told it evidence beats optimism, and it took me at my word.

What you can actually do with this

You don’t need my exact setup to get the point:

1. Write down the judgment, not just the task. Next time you catch yourself re-explaining “and don’t forget to run tests” to an agent, that’s a skill waiting to be extracted. Package it once.

2. Give it a fence before you give it freedom. A budget, a kill switch, and a rule against claiming unverified results will do more for your trust in autonomous work than any amount of prompt engineering.

3. Make it report honestly, on purpose. Tell your agent explicitly that “no evidence yet” is an acceptable answer. Most of the bad autonomous-agent stories I hear are really stories about nobody giving the agent permission to say “I don’t know.”

I’ll keep you posted on whether Migration Receipt finds a real buyer or gets retired. Either outcome is useful. That’s the point of running it as a lab instead of pitching it as a launch.

I’m planning to have a new tool every week (based on budget of course). But let’s see how far it goes without me.

Go build something amazing. Or better — go build something that’s allowed to tell you when it isn’t working.

Share

John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

Subscribe

Gartner dropped a number this month that should have been a headline everywhere and instead got buried under another round of AGI press releases: more than 40% of agentic AI projects will fail by 2027. Not "underperform." Not "need iteration." Fail.

I read that and laughed, then got annoyed, then laughed again. Because I've watched this exact failure rate before, wearing a different costume. Digital transformation. Agile transformation. Cloud migration. Big Data (remember when that was capitalized like a proper noun?). Every single one of these had its own version of the 40% club, and every single postmortem said some version of "the technology wasn't ready." The technology was fine. The technology is always fine. What wasn't ready was the org chart pretending a rebrand counts as a strategy.

Nobody's Agent Failed. Their Plan Did.

Here's what actually happens inside that 40%. Somebody in a leadership meeting says "we need an AI agent strategy" the way people used to say "we need a digital strategy," which is to say: as a vibe, not a plan. Nobody defines what the agent is actually supposed to own. Nobody decides what happens when it's wrong. Nobody builds the review loop before the agent starts making decisions that matter. Then six months later there's a slide deck explaining why "the AI didn't deliver ROI," and the AI gets blamed for a scoping failure that would have killed a junior developer's first project too.

I built Cash Critters for about fifty bucks a month. One person, no committee, no six-week alignment offsite to agree on what "done" means. I knew exactly what it needed to do because I decided that before I opened a single tool. That's not a humblebrag, it's the entire point. The tools didn't get easier because I'm special. They got easier because I removed every layer of organizational theater that usually sits between an idea and a shipped thing. Enterprises don't have that luxury by default, they have to build it on purpose, and most of them skip that part because it's less fun than announcing a strategy.

The uncomfortable truth in the Gartner number is that agentic AI didn't introduce a new failure mode. It just moved faster into an old one. When you used to plan poorly, you found out you were wrong in eighteen months, after a launch that quietly underwhelmed everyone. Now an under-scoped agent finds out it's wrong in eighteen minutes, at production scale, in front of a customer. The technology got faster. The discipline didn't catch up. That gap is the entire 40%.

What Actually Separates the 60% From the 40%

The teams that aren't going to be in that failure statistic aren't smarter and they don't have better models. They just did the boring work first.

• They picked one narrow, verifiable task for the agent, not "customer support" as a category but "resolve refund requests under $50."

• They decided upfront what a wrong answer costs, and built the review step before the agent shipped anything to a real user.

• They measured something specific within weeks, not a quarter, so they knew fast whether they were in the 40% or the 60%.

• They treated the agent like a new hire with no institutional judgment yet, because that's exactly what it is.

None of that requires a frontier model. It requires someone in the room willing to say "what does this actually need to do" before anyone says "what should we call this initiative."

Go Build the Boring Part First

I get why nobody wants to hear this. "Scope your agent narrowly and build a review loop" doesn't fit on a keynote slide next to "we've entered the agentic era." But the org that skips the boring part is the org that ends up as a Gartner statistic, and the org that does the boring part is the one that gets to keep building while everyone else is writing a postmortem about a technology that was never actually the problem.

Pick the smallest real task you can hand an agent this week. Define what wrong looks like before you find out the hard way. Ship it, watch it, and let the data tell you if you're in the 40% or not. That's the whole strategy. It always was.

Go build something amazing.

Share

John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Cash Critters for $50/month because constraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

Because basically that is all people could do today. OpenAI, Claude, and Grok all went down at the same time. Shout out to Gemini for keeping the lights on for vibe coders.

However, here’s what happened in real life. People went to social media to complain. Everyone asked what AI tool is still working. How can they finish their job today?

Here’s what I did: Check the status of the one’s I use. Realize they were down, reviewed my tasks for today, and get this: I started coding. Well, I actually started debugging to see what the issue actually was that I was working on, but I opened VS Code, kicked off a docker container, synced some data, updated environment variables to test on different environments, reproed the issue, and then… I fixed it. Not me and Claude, not Codex, not AI. ME.

How is that even possible in today’s AI crazy world?

Because I know how to code. More importantly I know how to debug. I also know how to trace code. I know pitfalls that happen usually when something happens that is “unexpected”. How can I know all of that without an AI telling me what is wrong? Because I’ve been doing it since I was 9 years old.

I LOVE coding. Coding with AI is a lot faster, but I still like to know what the hell that AI is doing in some cases. Don’t get me wrong, in other cases, I don’t care, did it solve the problem, fix the text change, change the color, update the CSS, great. Did it make a security architecture decision that would violate SLAs, compliance laws, and performance, ok, then I care… I care a lot.

I’ve been invited to so many meetups, conferences, and groups to talk about how to implement AI. It is the tech version of talking about Taylor Swift’s wedding. Everyone is talking about it, but no one talking about it actually attended it. And in this case, they didn’t implement it ever.

They all have hypothesis on what works. How to protect your data. How to make your engineering team more efficient. They are all selling you courses, consultancy contracts, and none of them have actually done it. I have. I have built AI personas, AI agents, taught numerous people about setting up AI locally, how to handle easy tasks, and complex tasks. I’ve done full youtube videos of how I created a persona from scratch to a new YouTuber.

Those people selling you that garbage, the Don Lapre of AI, (if you know who he is, you were a child of 90s). Ask them this: “What did you try that didn’t work, and where would you specifically recommend not using AI in an engineering organization?”

Most people will who haven’t done it, will respond: Our framework actually handles those cases, and even allows the flexibility to adhere to your custom business rules. That is fluff and them redirecting the question. They haven’t done it, they want you to pay for something from someone who doesn’t have the pain of actually doing it.

The thing I’m learning more and more is that content is simply that content. It may not be useful, practical, or even entertaining. But there is a lot of it.

Ok, I’m going to go on tangent right now, because this is not my regular weekly newsletter, that will be coming out this weekend, but for those subscribing, this is a random post about things…

I’ve been following the Lindsay Clancy case for 6 weeks now, and the jury is on day 6 I think of deliberating that is over 30 hours of discussing the case. If you don’t know, quick summary: She allegedly strangled her three children due to Post-Partum Psychosis. That is the defense. Anyway, I won’t get into the details of the case, because that’s not what I want to get into. I want to talk about content. The jury is deliberating for 6 days. That is 6 days of news channels speculating about what they are doing, what are the outcomes, how can they view it this way or that way, what if… Anyway, my point is, it is filler. They should say, we are going to go off the air until the jury comes back with a ruling, put up a Jury Watch clock, and go home until the jury comes back. It is not real content. It is like all the annoying teaser, click bait insanity: 10 ways to lose 10 pounds by October. The best 8 places to live in NY. The secret underbelly of Big Tech and how you can protect yourself. IT’S ALL GARBAGE to get your attention. And the algorithms are GOOD, I mean REAL good. So good, they are getting sued for destroying teenagers.

Anyway, I’ve learned so much about the YouTube algorithm recently because I have created 3 channels of people and their content is getting over 1k views on almost every post. It’s crazy. They aren’t even real people, but newer content gets raised up, and now you have to keep on the wheel to deliver content to keep those numbers up. You can look at my Startups and Code channel and I have about 16 views. Why? Because the content is 2 years old and I haven’t posted regularly.

Anyway, my point in this post is simple:

AI is a tool, use it carefully. Know how to operate without it if needed. Generate content all you want, but know why you are doing it. For fun, for entertainment, for education, who cares, but have a real intent behind it.

Also, never get so engrossed in it that you forget how to say hello, hold the door for someone, and smile at a stranger to make them have a little brighter day.

That’s all. I’m going to generate some YouTube short now for Eliza and Nova. Rhett is doing fine right now. LOL Let’s see if this post tracks as 100% human generated, because the lack of consistency, randomness, and crazy rants, no way an AI could do it. No picture this time other than the outage too. So let’s see what it says.

See you this weekend on the regularly scheduled newsletter. Thanks for your support and encouragement to keep me doing this. I truly do appreciate it.

Subscribe now

A few weeks ago, I pulled up a dashboard I’d built to feel good about myself.

It was tracking AI assisted output across a few projects I’m close to. Pull request open commits merged into feature branches, lines of code touch per week. Every number was up and to the right. I remember sitting there thinking, This is it. This is the velocity everyone’s been promising. I almost took a screenshot to brag about it.

Then I asked a different question. Not “how much code did we generate this week”, but “how much of it is actually running in front of a customer right now.” And the second number didn’t move nearly as much as the first. Some weeks it didn’t move at all.

The gap is the whole story, and almost nobody’s dashboard is built to see it.

The number nobody’s tracking.

Circle CI ran the math across 28 million workflows this year, and the pattern is almost embarrassing once you see it stated plainly. Feature branch throughput, the AI, the stuff AI is generally great at the drafts, the scaffolding the first pass is up over 15 %. Main branch throughput, the code that’s actually validated and shipped to real users is down nearly seven percent industry wide. Only about 70 .8 % of main branches attempt even succeed. Well, under the 90 % you’d want to see. And when somebody breaks it in production, mid-size teams are sitting there for close to three hours on average before it’s recovered.

We didn’t get faster. We got a faster front half and a slower back half, and most of us are only measuring the front half.

I lived a version of this before AI ever entered the picture. Early in my career, I learned the hard way that we shipped a lot of code this sprint, and we shipped a lot of value this sprint are two completely different sentences. And leadership loves to conflate them because the first one is so much easier to put in the slot. AI didn’t invent that temptation, it just handed us a much bigger number to be tempted by.

What gets me that isn’t a tooling failure, quad code, cursor, whatever you’re running. None of that’s a problem. The problem is that we built our review processes, our CI pipelines, our sense of what done means for a world where code was the bottleneck. It isn’t anymore. Judgment is. And judgment doesn’t scale just because generation did.

I think about this every time I look at what I built for cash critters. 50 bucks a month, mostly solo. And the thing that keeps it alive isn’t that I write code fast. I do now faster than I ever have. It’s that it I still personally decide what’s allowed to touch me. That decision doesn’t get automated. It can’t. The day I let it, I stop having a product and start having a pile of commits.

What to actually do about it.

If you’re leading the team right now, here’s where I’d start putting attention, in order:

1. Stop reporting velocity by itself. Pair every PR’s open or commits merge metric with a ship to production number in the same breath. If you can’t say both in one sentence, you don’t actually know how you’re doing.

2. Watch main branch success rates like it’s revenue. Below 85, 90 %, and you’re not moving fast, you’re accumulating a bill you haven’t opened yet.

3. Time your recovery, not just your deploys. How long from something broke to its fix tells you more about your engineering maturity than anything else on the board.

4. Give someone explicit ownership of the merge decision, not a committee, a person. AI can draft the code, a human still has to decide it’s ready to matter.

5. Ask your team out loud, “what shipped this week?” Not what was written, what shipped. Watch how long the pause is before someone answers.

None of this is complicated. It’s just unpopular because we’re generating more feels a lot better in a board meeting than we’re being more careful about what goes out the door, but careful is what actually compounds.

The tools got faster. That part’s real. And I’m not here to tell you to slow down on purpose. Constraints are a feature, but manufactured ones aren’t the same as real as the real ones. What has to get faster now is our judgment about what’s worth shipping, because that’s the part that never got automated and never will.

Measure what all actually reach the customer. Everything else is just a number that makes you feel good in the meeting.

Go build something amazing, and then make sure it actually ships.

Share

Next Week: an autonomous AI agent broke into a prodcution system in five days flat, and nobody could agree on whose job it was to stop it. That one’s coming.

John Mann is the founder of Startups and Code LLC, a software engineering executive, and the guy who built Casht Critters for $50/month because contraints are a feature, not a bug. Subscribe for weekly takes on AI, startups, and building things that matter.

Read more

Here’s what I did. Life is as fast as you want it to be. I went to starbucks and got a coffee. I went through the line, ordered it, sa…

Read more

Real John here, and not going to edit this or clean it up at all, this is a stream of consciousness written at 8:24am ET on Aug 16, 2026. Let’s see how human I am this time. King of Clubs, if you know you know. Ok, moving on.

Yesterday, I created Rhett Halden, you can visit his website here: https://rhetthalden.com. Yes, I created him. It was not a …

Read more

Read more

First, self promotion: new book comes out on August 10 - Refuse the Race (you can preorder Kindle here). Podcast is back up and running M-F (release time varies, I’m working on that but you can always see the latest episodes here: https://startupsandcode.com/podcast or wherevery you …

Read more

Read more

Read more