IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Many agents at once
Priya starts 3 coding agents in one project folder. Soon they undo each other's work. Your goal: run many agents without a mess.
🧪 Interactive lab — enable JavaScript to play with this one.
- Give each agent its own folder and branch.
- Split the work so tasks touch different files.
- A change that touches everything runs alone. Merge it first.
- Run only as many agents as you can review.
A desk for each agent
Your project folder shows the files of one branch. This is the working tree. Two agents in one folder edit the same files. Their changes get mixed up.
Git can give each agent an extra folder with its own branch. This is a git worktree. All the folders share one history. But a new folder starts without your untracked files, like .env. Your computer is shared, too.
Split the work so it merges
At the end, each branch is merged: its changes join the main line. Sometimes two branches change the same lines. Then git can't tell which one to keep. This is a merge conflict. Someone must fix it by hand, and it needs review again.
So give each agent one task, one branch and its own tests. A rename, a formatter run or an upgrade touches everything. Run it alone, merge it, then start the rest.
Now set up a new worktree. Fix each problem the agent hits.
🧪 Interactive lab — enable JavaScript to play with this one.
Go deeper: what a worktree shares
git worktree add ../shop-invoice -b fix-invoice makes the folder ../shop-invoice on a new branch. git worktree list shows all of them. git worktree remove cleans one up.
- Shared: the history, the commits and the remote. A commit in one folder shows up in the others right away. You don't need to push.
- Not shared: files git does not track. Copy in your
.envfile of test settings, never a live key, and install the dependencies again. - Still shared: your computer. Two apps on the same port (a numbered door on your computer) or the same local database still clash.
- One branch, one worktree. Git usually refuses to open a branch that another worktree has open. That protects you.
As of October 2026, many tools can make worktrees for you. Examples are Claude Code, Cursor and the ChatGPT desktop app.
Go deeper: cloud agents
A cloud agent works on a hosted computer, not on your laptop. It copies your project and works on its own branch. Then it sends back a branch or a pull request. Many can run at once. They can still clash when you merge.
Examples, as of October 2026: GitHub's Copilot cloud agent, Codex Cloud and Cursor's Cloud Agents. Claude Code on the web and Google's Jules work this way, too.
They work best on clear tasks with tests that prove the job is done (Tests, checks and debugging). Work you want to steer as it goes fits better on your own machine. Their setup, passwords and network access need care, too (Permissions, sandboxes and secrets).
Go deeper: agents in the pipeline
Most coding agents can run once from a script, with no chat window. They answer and stop, often as JSON. This is headless mode. Claude Code, Codex, Copilot CLI, Cursor's CLI and Antigravity CLI all have one.
So teams put agents in CI, the server that builds and tests every change. An agent can fix a broken build or sort new issues. Nobody is there to say no, so set the limits first:
- Allow only the tools it needs, and keep its sandbox on.
- Give its access token the smallest rights. GitHub advises read-only by default.
- Treat issue and comment text as untrusted. Anyone who can open an issue can hide orders in it. The official Claude and Codex actions run only for people with write access, by default.
Go deeper: review is the limit
Three agents can finish three tasks at once. You can't review three at once. Agent time costs money, even for work you throw away.
Many teams let an AI review pull requests as a second opinion. Examples are GitHub Copilot code review, Cursor's Bugbot, Codex review and Anthropic's Code Review. They catch real bugs and miss others. By default, their reviews only comment. They don't approve or block a change. Since September 2026, admins can let Copilot approve pull requests, in public preview. It is off by default. Once on, its approval counts as a review. Keep it off for code a person must own. Passing tests don't replace your review either (Review AI-written code).
Google's DORA reports found that AI use went with less stable releases, in 2024 and again in 2025. The 2025 report also found faster delivery.
An agent in CI that anyone can start, with a token that can write, is an open door. Let only trusted people start it. Never give a stranger's pull request code your secrets. GitHub warns about the pull_request_target trigger here.
In a practice project, make two worktrees with git worktree add. Change the same line in each and commit. Merge both into main. The second merge stops with a merge conflict.