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.