There are two kinds of home-improvement projects.

There are projects you plan.

And then there are projects your wife starts digging while you’re still explaining why the project is a bad idea.

This was the second kind.

It began with a deck.

Not an unusual deck. A nice deck, actually. Composite decking, black railing, landscaping around it. The sort of project where you finally stand back, admire several weekends’ worth of labor, and begin mentally returning your tools to their rightful places.

My wife, Karen, looked at it differently.

She looked underneath it.

“I don’t want critters living under there.”

I knew immediately where this conversation was headed, and being a man with decades of experience in several trades, I was prepared to provide the necessary technical expertise.

“You can’t really keep critters out from under a deck.”

There.

Problem solved.

Except Karen had not asked whether critters could be kept out. She had announced that she did not want them there.

This distinction would become important.

I explained the obvious engineering problem. You couldn’t easily put lattice around it. You couldn’t put boards around it. You couldn’t put siding around it (her idea). It wouldn’t matter. A raccoon, rabbit, squirrel, chipmunk, groundhog, or whatever other furry excavation contractor happened along could simply dig underneath.

Karen considered this.

Then she said something along the lines of:

“Why don’t we dig a trench around it and pour concrete in the trench?”

This was clearly getting worse.

The Squirrel Foundation

Her proposal was wonderfully excessive.

We would dig an 8″ deep trench around the perimeter of the deck.

We would stand wood–cedar siding down into the trench.

We would pour approximately a dozen bags of concrete around the bottom of the cedar.

The cedar would continue upward behind the composite skirt board around the deck.

Thus, an animal attempting to get underneath the deck would encounter cedar.

If it attempted to dig underneath the cedar, it would encounter concrete.

Karen had, essentially, proposed building a foundation for squirrels.

I hated it.

I explained that this was ridiculous.

I explained that animals dig.

I explained that cedar was water resistant but that burying wood in concrete and dirt was not exactly the detail you’d expect to find highlighted in an architectural textbook.

Karen listened carefully to my professional assessment.

Then she got a shovel.

This is where an important biographical detail belongs.

Karen’s father was the man who taught me practically everything I know about the trades.

Carpentry, electrical, plumbing, construction, repair, fabrication. He was the kind of guy whose lessons stick with you because they weren’t really lessons about how to use a particular tool. They were lessons about how to think about a physical problem.

And apparently, while I was receiving the formal education, Karen had been taking the same class from the other side of the dinner table.

This became particularly evident whenever I attempted to declare some nearly completed detail “good enough.”

Karen possessed a devastating five-word building code:

“Dad wouldn’t leave it like that.”

There is no effective response to this when Dad is the guy who taught you how to do it.

And apparently Dad wouldn’t leave an opening beneath a deck for squirrels, either.

I Went on Strike

I seem to remember refusing to help dig the first ten or fifteen feet of trench.

This was my principled stand.

I had evaluated the design.

I had rendered my professional opinion.

I was not participating in the construction of the Great Wall of Chipmunk.

Unfortunately, Karen possesses a personality characteristic that seriously diminishes the effectiveness of this negotiating strategy.

If I refuse to take the shovel, she takes the shovel.

So there she was, digging.

And the problem with watching somebody stubbornly dig a trench for an idea you have already declared stupid is that every additional foot raises the stakes.

At five feet, you can still win.

At ten feet, you become concerned.

At fifteen feet, you begin realizing that this woman may actually dig the entire damn thing without you.

Eventually, I joined the winning contractor.

And somewhere during construction, something unexpected happened.

The stupid idea became clever.

The Cedar Was the Trick

We had leftover cedar siding.

Real cedar bevel siding, the same basic stuff used on the house.

A cedar bevel board is thick along one edge and tapers down toward the other. Normally you install these boards horizontally with one overlapping the next.

For our decidedly nonstandard application, we put the fat edge down.

And suddenly the material made enormous sense.

The bottom didn’t have to be cut perfectly because it disappeared into a trench that was about to be filled with concrete and covered with dirt and mulch.

The top didn’t have to be cut perfectly because it disappeared behind the composite skirt board.

Think about what that eliminates.

Normally, finishing the bottom of a deck against uneven ground is an exercise in measuring, cutting, fitting, trimming, checking, swearing, removing, cutting another eighth of an inch, reinstalling, and discovering that the ground three feet away is two inches higher.

We didn’t have to do any of that.

We put the cedar into the trench.

Wherever the bottom landed, it landed.

Wherever the top landed behind the skirt board, it landed.

Then I screwed through the composite skirt board into the cedar.

Done.

No precision cut at the top because nobody would ever see it.

No precision cut at the bottom because nobody would ever see that either.

The visible composite skirt board established the one line that mattered.

Straight.

Clean.

Finished.

Everything behind it could be gloriously indifferent to aesthetics.

This is one of my favorite kinds of construction trick: don’t become more precise than the project requires. Design the detail so precision isn’t required in the first place.

Need More Height? Add Another Board.

Some parts of the deck sat farther above grade than others.

That sounds like another problem.

It wasn’t.

Where one cedar board wasn’t tall enough, I used two.

They were siding boards, after all. Overlapping is literally what they were born to do.

Put one above the other with an overlap, fasten them together, and suddenly you’ve got whatever height you need.

No custom panel.

No sheet goods.

No elaborate framing.

No special-order product with seventeen proprietary clips and a 46-page installation manual.

Just another piece of cedar.

That was particularly satisfying because the entire assembly tolerated variation.

The ground could rise and fall.

The trench could vary slightly.

One section could require one cedar course.

Another could require two.

None of it mattered because the composite skirt board established a continuous visual line around the deck.

From ten feet away, you don’t see any of the engineering.

You see a deck that looks finished all the way to the landscaping.

Then Came the Concrete

Once the cedar was positioned, the trench was filled with concrete.

And this was the part of Karen’s idea I had originally dismissed.

I’d said animals could dig underneath whatever we installed.

Karen hadn’t disputed that.

She had simply removed “underneath” from the available options.

That’s actually very good problem solving.

Instead of asking:

“What kind of deck skirting keeps animals out?”

she had effectively asked:

“How would an animal defeat deck skirting?”

Answer: dig beneath it.

Okay.

Then make beneath it undiggable.

That’s a completely different way of approaching the problem.

The cedar closed the vertical opening.

The concrete closed the subterranean opening.

The composite board concealed the top of the entire contraption.

And the landscaping concealed the bottom.

The result was something that looked considerably more sophisticated than the construction method had any right to look.

But You Buried Cedar in Concrete

Yes.

I know.

There is undoubtedly someone reading this who has been waiting several paragraphs to say it.

You shouldn’t bury wood in concrete.

And as a general construction detail, I agree.

Wood plus persistent moisture is a longevity problem. Even naturally decay-resistant cedar is still wood. The transition around grade, where materials repeatedly get wet and dry, is particularly unfriendly territory.

If I were designing the same system today from scratch, knowing what I know now, I might substitute a modern rot-proof material for the buried vertical component.

PVC or an appropriate composite product immediately comes to mind.

But there are a few things working in favor of our original contraption.

First, it is cedar.

Second, the thick edge is down.

Third, we coated the hell out of it with a very durable black exterior stain/coating.

Fourth, this isn’t structural. The cedar isn’t holding up the deck. If it eventually deteriorates, my deck isn’t coming down.

And fifth, the thing has already spent years outside getting rained on, snowed on, frozen, thawed, splashed with mud, surrounded by mulch, assaulted by Illinois humidity, and generally subjected to everything nature could think of.

I recently crawled down and looked at it.

It’s still there.

Pretty damn solid, too.

Apparently nobody informed the cedar that it was installed incorrectly.

The Funny Part Is What It Looks Like

This whole story came back to me because I recently showed photographs of the deck to someone without explaining any of this.

They looked at the horizontal composite board around the bottom and essentially said:

“That’s a nice deck skirt detail.”

Exactly.

They didn’t notice the anti-squirrel fortification.

They didn’t see the cedar disappearing toward the ground.

They didn’t know there was concrete underneath.

They saw a clean horizontal architectural detail tying the deck into the landscaping.

That may be my favorite thing about the entire project.

The engineering disappeared.

Good construction often does that.

When something is really awkward, the finished result doesn’t necessarily have to advertise how difficult the problem was.

In this case, the solution doesn’t look like pest control.

It looks like trim.

The Skirt Board Couldn’t Skirt the Issue

Which brings me back to the skirt board.

A normal skirt board could have done exactly what its name suggests.

It could have skirted the issue.

Put something attractive around the bottom of the deck, hide the framing, call it finished and go have a beer.

Except Karen’s objection wasn’t aesthetic.

She didn’t merely want to hide what was underneath the deck.

She wanted to prevent anything from moving in underneath the deck.

So the skirt board couldn’t merely skirt the issue.

It had to solve it.

And that led to one of those wonderfully backwards DIY projects where the apparently excessive idea turned out to make the finished construction easier.

The trench eliminated the need for a finished bottom cut.

The composite skirt eliminated the need for a finished top cut.

The cedar accommodated changing heights simply by overlapping another board.

The concrete stopped digging.

The stain protected the cedar.

And the composite board concealed the entire operation behind one clean horizontal line.

What initially sounded like:

“Let’s dig a trench and bury cedar siding in twelve bags of concrete because Karen doesn’t like squirrels”

eventually became:

“That’s actually a pretty damn elegant way to finish a deck to grade.”

I hate when she’s right.

There Is, Unfortunately, a Larger Lesson Here

I’ve spent a lot of my life building and fixing things.

One of the great advantages of knowing several trades is that when somebody proposes an idea, you can immediately imagine the seventeen reasons it won’t work.

This is extremely useful.

It’s also occasionally a handicap.

Experience teaches you where things fail.

But sometimes that means the experienced person starts solving the problem by eliminating possibilities, while somebody else starts with:

“Well, why couldn’t we?”

Karen wasn’t thinking about conventional deck-skirt construction.

She had a squirrel problem.

Or, more accurately, she had a future hypothetical squirrel problem, which is arguably worse because there wasn’t even a squirrel yet.

She identified the failure mode.

They’ll dig underneath.

Then she attacked the failure mode.

Put concrete underneath.

That’s it.

The guy who knew how to build things had a list of reasons the idea was silly.

The daughter of the guy who taught him how to build things grabbed a shovel.

And that’s probably not a coincidence.

Her father taught me practically every trade I know.

But apparently he taught Karen something, too.

Maybe the more important thing:

If the problem is still there, you’re not finished.

Years later, I look at that deck and no longer see the ridiculous squirrel bunker I reluctantly helped build.

I see a clean composite skirt, a nicely finished transition into the landscaping, and a construction detail simple enough that I’d seriously consider doing it again.

Maybe not with cedar–unless, like this example, it was free/leftover.

Maybe with something completely rot-proof next time.

But the trench?

Absolutely.

The buried barrier?

Yep.

The composite board hiding the whole operation?

Definitely.

And if Karen tells me to start digging?

This time I’ll probably just get the shovel.

After all…

Dad wouldn’t leave it like that.

How two AI agents turned my IDE into a parallel development team, and why adding a third requires CI/CD discipline

When most people were making funny pictures with AI, I connected OpenAI directly to my development environment.

Not beside it.

Not in a browser where I would ask a question, copy the answer, paste it into another application, and continue doing all the actual work myself.

I put the AI inside Visual Studio Code, the IDE where the software work happens.

It could inspect the real project. It could read the files. It could search the codebase. It could use the terminal. It could run tests. It could examine errors. It could work with Git. And, most importantly, it could use the command-line tools provided by the major enterprise platforms I work with.

That changed AI from something I talked to into something that could operate a workbench.

After using it for a while, I estimated that one properly directed coding agent could sometimes perform the mechanical output of approximately twenty people.

Not twenty senior architects.

Not twenty people with business judgment, institutional knowledge, or accountability.

Twenty sets of hands.

Twenty people searching files, writing repetitive code, tracing dependencies, comparing configurations, testing variations, documenting changes, checking details, and polishing the hundreds of little pieces that separate a prototype from an actual application.

I was paying roughly $40 a month and directing what felt, under the right conditions, like forty coders.

Now I think I may be ready to hire twenty more.

First, What Is an IDE?

An IDE is an Integrated Development Environment.

For a nondeveloper, think of it as the workshop where software is built.

It contains the source code, project folders, search tools, terminals, testing utilities, version history, debugging tools, and connections to other systems.

A carpenter does not build a cabinet by discussing wood in a conference room. The carpenter works in a shop containing saws, clamps, measuring tools, plans, and the material itself.

Visual Studio Code is my software shop.

Connecting AI to that environment meant it was no longer giving me abstract advice about what someone could theoretically build.

It could see the actual cabinet.

It could inspect the joints.

It could find the warped board.

It could propose a repair and, when authorized, make the cut.

Every Major Platform I Use Has a CLI

Most of the major systems I work with provide a CLI, or command-line interface.

Do you know what that means?

The Average-Person Explanation

Most people operate software through a graphical interface.

They click buttons. They open menus. They fill in forms. They move from screen to screen.

A command-line interface provides a second entrance into the same system.

Instead of clicking through six screens to perform an operation, you may be able to type one precise command.

That command can often be:

• saved

• repeated

• reviewed

• combined with other commands

• placed in a script

• run automatically

• executed consistently

• recorded as evidence of what happened

Imagine asking a person to perform a complicated task in an application.

They open one menu, click another menu, choose an option, enter a value, check a box, upload a file, and click Deploy.

Now imagine replacing that sequence with a written instruction the computer understands exactly.

The first method is difficult to repeat perfectly.

The second can become a controlled process.

That repeatability is the doorway to automation.

It is also the doorway through which an AI agent can enter the actual work.

The Developer Explanation

At a technical level, a CLI exposes platform operations through structured commands, arguments, configuration files, credentials, environment variables, and machine-readable output.

Depending on the platform, a CLI may allow an authorized developer or agent to:

• create projects

• inspect metadata

• retrieve configuration

• validate source files

• compare environments

• run builds

• execute tests

• deploy components

• collect logs

• examine failures

• import or export data

• automate a sequence of operations

A CLI does not necessarily expose every capability of the platform.

Some are excellent. Some are incomplete. Some enterprise applications still trap important configuration inside graphical administration screens.

But even a limited CLI changes the nature of AI-assisted development.

Without tools, AI can tell you what code might look like.

With an IDE, terminal, files, Git, APIs, and CLIs, an agent can inspect the actual project, make a change, run validation, observe the result, correct the failure, and prepare the work for human review.

It now has hands.

One Agent Began to Feel Like Twenty People

When I say that one agent can feel like twenty humans, I am not claiming that an AI subscription replaces twenty complete employees.

People contribute experience, creativity, judgment, relationships, accountability, and an understanding of consequences that cannot be reduced to typing speed.

My estimate concerns execution capacity.

A conventional development team may distribute hundreds of small responsibilities among many people:

• one person creates the data structure

• one person builds the API

• another builds the screen

• someone adds validation

• someone handles errors

• another improves mobile behavior

• someone adds logging

• someone tests edge cases

• someone writes documentation

• someone adjusts spacing

• someone notices that the loading indicator feels wrong

• someone adds keyboard navigation

• someone makes the table sortable

• someone adds filtering

• someone builds drag-and-drop behavior

• someone adds gauges and status indicators

• someone handles empty states

• someone improves the confirmation dialog

• someone checks that the colors communicate status consistently

• someone notices that the entire thing is technically correct but unpleasant to use

Large teams do not merely add big features.

They add thousands of small refinements.

That is what surprised me most about a capable coding agent.

I could design down to the smallest interaction.

    The cards should support drag-and-drop ordering.

    The status gauge should animate smoothly but not distract the user.

    The warning state should appear only when the threshold is materially exceeded.

    The filter should remember the user’s last choice.

    The table should remain readable on a smaller monitor.

    The modal should explain what will happen before the user commits the action.

    The empty state should tell the user what to do next rather than merely display “No data.”

    The dashboard should show green when everything is healthy, yellow when attention is needed, and red only when action is required.

The agent could then move through the codebase and build those details.

Not always perfectly.

Not without review.

But rapidly enough that I no longer had to choose between building the primary function and adding the dozens of refinements that make the system feel complete.

That is where the “twenty people” comparison came from.

One agent could keep returning to the work.

It did not become bored with the small details.

It did not decide that the drag-and-drop behavior was outside its job description.

It could implement the gauge, revise the spacing, trace the error state, update the documentation, run the test, and then revisit the same component after I noticed one more improvement.

A traditional twenty-person team adds breadth because many people can work on many details.

An AI agent adds a strange form of compressed breadth because it can move rapidly across many disciplines while retaining the context of the overall design.

Again, the agent does not replace the judgment of twenty people.

But it can deliver a startling portion of the hands-on work those people would perform.

Then I Opened a Second Visual Studio Code Instance

After working this way for a while, I realized I was still operating the agent in a mostly single-threaded way.

I would give it a task. It would inspect the system. It would work. I would review the result. Then we would move to the next task.

But Visual Studio Code can run in multiple windows and workspaces.

Why not open another instance?

Why not give a second agent a separate lane?

One agent could build while another investigated.

One could modify the application while another reviewed existing architecture.

One could work on a NetSuite script while another examined the integration flow.

One could implement the primary function while another prepared edge-case tests, documentation, and deployment evidence.

That was the moment the model changed.

I was no longer using an assistant.

I was beginning to direct a team.

A Real Example: Two Agents, One Shared Conversation

Here is what the model looks like in actual use.

I keep ChatGPT open in an integrated browser inside Visual Studio Code. An integrated browser is a browser panel that lives inside the development environment instead of in a completely separate Chrome window. The conversation, the source files, the terminal, and the coding agent can all remain inside the same working cockpit.

ChatGPT and I first strategize around the goal. I provide the operational objective, the business process, the constraints, the risks, and the actions that must remain under human approval. ChatGPT helps translate that intent into architecture, work packages, validation requirements, and explicit instructions for Codex.

I remain the source of operational intent and the person who greenlights each material step. ChatGPT acts as the planning and translation layer. Codex works inside the IDE, where it can inspect the project, edit files, run commands, validate results, and report what it found.

A Targeted Handoff Instead of Copy and Paste

We created a lightweight XML-style instruction schema so Codex does not have to interpret the entire conversation as a task. It reads only the latest relevant block explicitly addressed to it.

A real instruction can look like this:

<codex mode=”inspect-and-correct” approval=”997-production-preflight-no-deploy”>

Prepare the Northern Tool inbound 997 implementation for a controlled production preflight.

…

Post your findings in this chat.

</codex>

The mode tells Codex what kind of work to perform. The approval attribute defines the boundary of its authority. In this example, it may inspect and correct the implementation and prepare the production preflight, but it may not deploy.

The body defines the assignment and the expected return. When Codex finishes, it posts its findings back into the shared ChatGPT conversation.

That creates a closed loop:

Jim defines the operational goal and approval boundaries.

ChatGPT helps design the approach and writes the precise agent instructions.

Codex reads the targeted instruction, performs the IDE work, and reports the evidence.

Jim reviews the result and authorizes, redirects, or stops the next step.

A Real Parallel EDI Workstream

At one point, Agent One was building the inbound 850 purchase-order application in NetSuite and the outbound 855 purchase-order acknowledgment.

I got ahead of that workstream.

Rather than waiting for Agent One to finish, I opened a new Visual Studio Code instance and assigned Agent Two to the 856 advance ship notice, formally the X12 Ship Notice/Manifest.

Agent One continued developing the order and acknowledgment path. Agent Two began developing the shipping-notice path. I moved between their review points, answered operational questions, resolved dependencies, and approved the next controlled steps.

For roughly eight hours, I moved back and forth between the two agents, reviewing and greenlighting each material step while the equivalent of about forty sets of development hands produced thousands of lines of code, tests, corrections, interface details, and deployment evidence.

That is an important distinction. I was not personally typing tens of thousands of lines. My work was architectural and supervisory: defining the goal, correcting direction, resolving business decisions, checking evidence, and deciding when each workstream could proceed.

That was not simply two chat windows answering questions.

It was two technical workstreams advancing concurrently under one architecture, one shared strategy conversation, and one human release authority.

Then I Measured the Output

A few days later, in Visual Studio Code Instance Three, or VSi3, I asked Codex to perform a read-only audit of the repository instead of relying on my impression of the work.

The audit measured VSi3’s repository output over roughly two active development days. This was not the combined production of VSi1 and VSi2. It found 14 commits across 33 distinct files. Production source and deployable configuration accounted for 6,119 changed lines. Tests and test harnesses added another 2,072. Operational documentation added 809 more.

The complete verified total was exactly 9,000 changed lines: 8,838 additions and 162 deletions, producing a net increase of 8,676 lines. Based on the breadth of production code, deployable configuration, testing, documentation, validation, and release evidence, I estimate that VSi3 delivered roughly 20 to 40 human developers’ worth of execution over those two days, or approximately 40 to 80 person-days.

Those numbers were deliberately conservative. ZIP archives, screenshots, build packages, generated output, dependency trees, lockfiles, and raw EDI payloads were excluded. Untracked files were included only after their creation timestamps were verified. The audit separated committed, unstaged, and untracked work instead of flattening everything into one flattering number.

No single file dominated the result. The work crossed the entire delivery stack: SuiteScript application logic, REST services, operator interfaces, deployable SDF configuration, automated tests, and production operating documentation.

I did not personally type 9,000 lines. I designed the system, defined the operating rules, made the business decisions, corrected direction, reviewed evidence, and controlled what could proceed. The agents supplied the execution capacity.

That is the distinction at the center of this article. AI did not replace architecture, judgment, or accountability. It multiplied the hands available to carry them out.

Two Agents Create a New Problem

Two agents do not simply produce twice as much progress.

They can also produce twice as many collisions.

They may modify the same file.

They may make different assumptions.

One may depend on something the other has changed.

One may test an older version.

They may each create a solution that works independently but fails when integrated.

The faster the agents work, the faster confusion can spread.

Opening additional IDE windows was easy.

Creating a safe operating model for parallel development was not.

That is why a CI/CD-style architecture became necessary.

What CI/CD Means

CI/CD usually means Continuous Integration and Continuous Delivery, or Continuous Integration and Continuous Deployment.

The wording varies, but the basic purpose is consistent.

It creates a controlled pathway for moving software changes from development toward release.

The process generally includes:

• tracking changes

• separating work

• validating files

• running tests

• combining compatible changes

• detecting conflicts

• promoting changes through defined environments

• requiring approval where appropriate

• deploying through repeatable procedures

• retaining enough history to understand what happened

My enterprise environment is not a textbook, fully automated, repository-driven CI/CD system.

Some of the CLIs are restricted.

Some configuration still lives inside the platforms.

Certain settings cannot be represented perfectly as code.

Not every deployment can be reduced to one automated pipeline.

But the environment is CI/CD-aligned.

It uses the same essential principles:

• controlled development

• separated responsibilities

• repeatable steps

• validation before promotion

• documented changes

• testing

• integration controls

• human approval gates

• managed deployment

The architecture is necessary because parallel AI agents can create work more quickly than a loose development process can safely absorb.

    Without control, speed becomes turbulence.

    With control, speed becomes throughput.

CI/CD for a Nondeveloper

Imagine several mechanics working on the same vehicle.

One is modifying the engine.

One is repairing the electrical system.

One is replacing the brakes.

The assignments are deliberately separated. I would not put one mechanic on a bicycle tire while another works on the spokes of the same wheel. That is not parallelism. It is interference. The useful model is one mechanic working on the car’s tires while another handles the brakes, or one person repairing a window screen while another washes the windows. Separate lanes, shared outcome.

They can work at the same time, but only if each understands the assignment and their work is inspected before the vehicle returns to the road.

Otherwise, one mechanic may disconnect something another needs.

They may install incompatible parts.

Someone may test the vehicle before the brakes are operational.

A CI/CD-style system provides:

• separate work areas

• clear responsibilities

• a record of each change

• inspection points

• integration testing

• final approval

The mechanics can work concurrently.

The vehicle still passes through controlled gates.

My agents are extremely fast mechanics.

The development architecture is the shop procedure.

I still decide what vehicle we are building, what modifications belong on it, and when it is safe to turn the key.

Why This Matters for EDI Onboarding

EDI onboarding is an ideal example because it is not one task.

It includes a web of connected activities:

• partner requirements

• transaction specifications

• identifiers

• mappings

• test documents

• business rules

• acknowledgments

• order handling

• shipment messages

• invoicing

• exception paths

• validation

• deployment

• monitoring

Traditionally, these activities often move through a long sequence.

One person completes a piece and hands it to the next.

The next person discovers a missing dependency and sends it backward.

Someone waits for a sample file.

Someone else waits for a mapping decision.

Testing begins late.

Errors discovered near the end send the project back through the line.

With a CI/CD-aligned fast-track onboarding model, several workstreams can move concurrently.

One agent can analyze the partner specifications.

Another can inspect the existing EDI application and integration architecture.

One can develop mappings.

Another can prepare test cases and challenge exception paths.

One can build.

Another can review.

One can trace dependencies while another prepares deployment evidence.

That is not human multitasking in the traditional sense.

Human multitasking usually means one person switching rapidly between several jobs and performing each with fragmented attention.

Here, the agents perform the work in parallel.

I move among structured review and approval points.

The human remains intentionally single-threaded.

The delivery system becomes multi-threaded.

Then the Bottleneck Moved

After using two agents this way, I noticed something unexpected.

The agents were no longer the limiting factor.

I was.

Each could inspect, analyze, write, test, revise, and document at extraordinary speed.

But I still had to review and greenlight each material step.

I had to determine:

• whether the assumption was correct

• whether the architecture matched the business

• whether the solution belonged in the system

• whether one agent’s work conflicted with the other

• whether the validation was meaningful

• whether the risk was acceptable

• whether the next action should be authorized

• whether anything was permitted to reach production

The execution capacity had become abundant.

Human judgment had become scarce.

When My AI Developers Punch Out

When my AI developers get ahead of me, they punch out and take an unpaid break.

That sounds like a joke, but it points to another unusual economic advantage of this model. A human team still creates payroll, coordination, meetings, context switching, and pressure to keep everyone occupied when the supervisor becomes the bottleneck. An AI agent can stop at a review gate and wait. It does not become impatient, invent side work, or accumulate additional hourly labor cost while I catch up. When I return with the next decision, it resumes at full speed.

I do not have to keep the agents busy. I have to keep myself capable of reviewing what they produce.

The Third-Agent Question

That led me to a sentence I do not think most people I know would naturally say:

    I think I am ready to hire another twenty coders.

What I really mean is that I may be ready to supervise a third AI agent.

The decision is not about whether the third agent can produce more work.

It can.

The question is whether I have enough structure and review capacity to keep another high-speed workstream useful and controlled.

A third agent needs a distinct lane.

Otherwise, I am not adding capacity.

I am adding noise.

Adding Another Agent Took One Click

The most startling part was how little effort it took to add another development lane.

I clicked Duplicate Workspace in Visual Studio Code.

The new instance opened on the same machine and development environment. The repositories were already available. The command-line tools were installed. The credentials and platform connections were already configured. The new agent inherited access to the same files, terminal, Git history, testing tools, and deployment utilities.

I added another integrated browser window, opened the same ChatGPT conversation, and assigned the new VSi its own workstream.

That was essentially the entire onboarding process.

All three Visual Studio instances could work independently, yet their findings and assignments flowed through one unified conversation. ChatGPT and I could see VSi1, VSi2, and VSi3 at the same time. I could review one increment, assign the next, rotate immediately to another instance, and continue without stopping to wait.

Review. Assign. Rotate. Never stop and wait.

By the time I completed the circuit, the first VSi was often ready for review again.

Adding another development lane was no longer a staffing project. It was almost one click.

The limiting factor was not provisioning another agent. It was whether I had enough architectural clarity, review capacity, and approval discipline to keep another high-speed workstream productive.

AI execution capacity had become almost instantaneous to provision. Human supervisory capacity had become the scarce resource.

A Possible Three-Agent Operating Model

Agent One: Builder

The first agent performs implementation.

It writes code, creates mappings, builds interfaces, updates configurations, and develops the primary technical solution.

It can handle the visible work and the hundreds of smaller details that surround it:

• drag-and-drop interactions

• sorting and filtering

• responsive layouts

• gauges

• progress indicators

• confirmation dialogs

• empty states

• validation messages

• error handling

• status lights

• accessibility improvements

• logging

• documentation

Agent Two: Reviewer and Tester

The second agent challenges the builder.

It inspects the proposed changes.

It checks assumptions.

It searches for edge cases.

It reviews error paths.

It tests for regressions.

It compares the implementation to the original objective.

Its job is not to admire the solution.

Its job is to try to break it.

Agent Three: Analyst and Coordinator

The third agent works ahead of and around the implementation.

It can:

• perform discovery

• trace dependencies

• inspect related systems

• maintain documentation

• prepare test cases

• assemble evidence

• identify missing decisions

• organize deployment steps

• monitor open questions

• prepare the next approval package

This agent keeps the next section of road surveyed while the builder and reviewer work on the current section.

Human: Architect and Release Authority

I remain responsible for:

• the objective

• the architecture

• the business context

• the priorities

• the controls

• the risk decisions

• the approvals

• the production release

The agents can create the work.

They do not own the consequences.

I do.

The Agents Must Return Decisions, Not Noise

Three agents can generate an astonishing amount of information.

If they return every command, every file, every possibility, and every unresolved thought, they can bury the person supervising them.

Each workstream needs to return a compact review package:

1. What changed?

2. Why was it changed?

3. What evidence shows that it works?

4. What risks or uncertainties remain?

5. What exact decision is required from me?

That format turns activity into a decision point.

Without it, more agents create a larger inbox.

With it, they create parallel delivery capacity.

The Real Skill Is Not Prompt Writing

People often describe AI expertise as knowing how to write good prompts.

That matters, but it is only the visible surface.

The harder skill is directing several execution systems without losing control of the architecture, dependencies, evidence, and consequences.

The human must understand enough to recognize when an answer is correct and when it merely sounds correct.

The human must notice when two agents are solving different versions of the same problem.

The human must recognize when a technically valid change violates the operating model.

The human must be willing to say:

    The code works, but it solves the wrong problem.

    The explanation is polished, but the evidence is incomplete.

    The feature is useful, but it does not belong in this release.

    The agent is fast, but it is headed in the wrong direction.

That judgment is the control system.

Forty Coders for Forty Dollars?

Is it literally forty coders?

No.

It is not forty independent minds.

It is not forty careers’ worth of judgment.

It is not forty people who can walk into a meeting, understand the politics, take responsibility, challenge leadership, mentor a colleague, and live with the consequences of a bad release.

But when the architecture is clear and the work can be expressed through code, files, commands, tests, and repeatable procedures, two agents can generate a level of output that once would have required a surprisingly large team.

They can implement the main function.

Then they can keep going.

They can add the drag-and-drop.

They can refine the gauge.

They can add the tooltip.

They can improve the empty state.

They can handle the loading condition.

They can test the invalid input.

They can add the log message.

They can revise the layout.

They can update the documentation.

They can trace the overlooked dependency.

They can do the twenty-person-team things that are often sacrificed because everyone is trying to get the primary feature across the finish line.

That is why the number feels real to me.

Not because AI has become twenty complete humans.

Because it can bring twenty humans’ worth of hands to a well-designed problem.

I Think I Am Ready to Hire Twenty More

The sign is not that I have run out of tasks for the current agents.

The sign is that the first two increasingly reach clear review points and wait for me.

The operating model is becoming structured enough to support another lane.

The real test is whether I can add that lane without reducing the quality of my review.

A third agent makes sense only if:

• it has a clearly separated responsibility

• its work can proceed without constant collisions

• it returns concise review packages

• approval gates remain explicit

• production permissions remain controlled

• I can explain every significant decision

If I no longer understand what the agents are doing, I have not scaled the system.

I have surrendered the controls.

A Different Kind of Team Is Appearing

Many organizations are still deciding whether employees should use one AI assistant.

Meanwhile, another operating model is quietly emerging.

One experienced person can direct several specialized AI agents through parallel technical workstreams, supported by CLI access, development controls, repeatable validation, and human approval gates.

The progression is almost inevitable:

First, AI answers questions.

Then AI enters the IDE.

The IDE gives it access to files and a terminal.

The CLI gives it access to the platforms.

A second IDE instance creates another workstream.

Parallel work makes CI/CD discipline necessary.

The agents accelerate until human review becomes the bottleneck.

Then the human asks a question that would have sounded ridiculous only a short time ago:

    I have forty coders for about forty dollars a month. Am I ready to hire twenty more?

I think I may be.