Cet article est aussi disponible en 🇫🇷 Français : L’Agent Development Environment : une nouvelle unité de travail.

The Agent Development Environment: A New Unit of Work

Every few years, something comes along that changes what “writing code” means. This time, it might stop meaning writing at all.

Section intitulée where-we-come-fromWhere we come from

What follows is my own path, not a history of PHP. Other people lived those same years very differently. My story starts in 2013, when PHP was not the obvious choice it would later become, so I learned C: pointers, manual memory management, segfaults. Then I moved to Objective-C for iPad development, with a bit of Smalltalk on the side, maintaining a legacy internal website. During that time, I fell in love with the web. I joined a company doing PHP, a language that was completely new to me. The stack there was PHP 5.x, no autoloading, barely any libraries, and no framework. Composer and Symfony already existed, we just did not use them. Every project started from scratch, and we reinvented a lot of wheels. It was harder, sure, but it was just how things were for us. Then I moved to Paris, and that is where I discovered frameworks. Laravel and Symfony were both making waves, and I started with Laravel. Suddenly, an entire community had already solved the problems I used to solve alone. For me, frameworks were not just tools; they were a multiplier. Eventually I moved on and adopted Symfony, which I still use and love today. Everything you need can be done with it, and even more. Looking back, one pattern holds: I followed where the tech led me. Each era changed the unit of my work: from lines of C, to libraries, to frameworks. This article is about what I think is the next step, the one we are living in right now.

Section intitulée the-llm-waveThe LLM wave

For years, frameworks felt like the end of that road. Then a new kind of tooling appeared.

The first spark came in 2021, with GitHub Copilot: auto-completion on steroids. You would start a line, and the machine would finish it. It felt like magic. In 2023, Cursor raised the bar: still auto-completing our code, but with far more built in, like chatting with your codebase, inline edits, and whole chunks of code written from a simple instruction. And since 2025, Claude Code has taken the lead on AI agents, with models capable of delivering full features on their own.

The progression is clear: first a tool that completed our code faster, then a tool that wrote some of it for us, and now agents that build entire features. The unit of work changed again: from frameworks to features.

This wave did not stay in the hands of a few big players. Competition exploded, and open-weight models joined the race: DeepSeek, in particular, shook the AI world by delivering frontier-level performance at a fraction of the cost, and it was far from alone. For us developers, this changed the question of access: powerful models are no longer locked behind a single provider. You can pick the model that fits each task, mix providers in the same workflow, or run smaller models on your own hardware with tools like Ollama.

Each of these waves redefined a piece of our job. But in my opinion, this was only the opening act: the real change is not the agent itself, it is the environment we run it in.

Section intitulée enter-the-adeEnter the ADE

The first hint came from Cursor itself. With Cursor 2.0, it started hiding the things we thought were essential: the file tree, the git panel, the editor front and center. What remained was a conversation with an agent. Without naming it, that is what an ADE is: an Agent Development Environment. Where an IDE is built around you editing files, an ADE is built around you directing agents, and chatting with them to build products.

The name is new and not broadly used yet, but I like it, precisely because it draws a clear line between how we develop today with IDEs and what is coming next.

After Cursor, Jean went deep into the ADE paradigm. The reasoning is simple: if agents are busy working for you, you should be able to run several tasks at once. So Jean ships native git worktree management: each task lives in its own isolated copy of the repository. Combined with GitHub pull request and issue integration, you can pick an issue, get a fresh worktree, and have an agent working on it in seconds.

Then a coworker mentioned Orca to me. It does everything Jean does, with even more integrations: Jira and Linear are supported natively, so while working on something I can grab an issue and immediately spin up a worktree to start on it. Each task gets its own terminal, browser, and context, and it is bring-your-own-subscription: Claude Code, Codex, OpenCode and others, side by side.

Nothing from the agent wave is lost along the way, either. Agents, commands, skills: everything we built carries over. An ADE does not replace that toolbox, it stands on top of it, and that only makes it stronger.

This is why an ADE is not “an IDE with an AI panel bolted on”. The primitives are different: not files and buffers, but tasks, worktrees, and agents. The IDE assumed one developer, one working copy, one thread of work. The ADE assumes you are orchestrating several at once.

Section intitulée my-daily-setupMy daily setup

One disclaimer before we dive in: my main CLI agent nowadays is OpenCode, so every example in this section is focused on it. But nothing here is OpenCode-specific: most of these tips translate directly to Claude Code, Codex, or whatever agent you prefer.

Section intitulée orca-itselfOrca itself

Orca ships with many features designed to make your life better, and the first one is issue-tracking integration: GitHub issues, Jira, and Linear are all supported. From there, you can pick a new issue or check the ones you are already working on, read every detail, and create a worktree straight from it. When you do, the default prompt is the issue link (this will help us a lot later on, stay tuned).

When you juggle several features or issues at once, each in its own worktree, it quickly gets hard to remember what you have to do on which one. That is why Orca gives you a kanban board. Every column is fully customizable; in my case I have four:

• “Todo” holds the features and issues to tackle;
• “Waiting” is for blocked tasks where I need feedback from whoever is linked to the issue;
• “In progress” is what I am actively working on;
• “Draft” is for tasks where I opened a draft pull request on GitHub. Since I work on many features at once, I rarely run the full test suite locally, so I let the CI do it on the draft PR and come back to check the results (when there are too many failures, I do run the tests locally). Once everything is green, I open the PR for review and remove the local worktree.

Following on my “Draft” state, another thing I like about Orca is the right dock. It contains a project file explorer where you can edit files directly, like you would in an IDE. A second tab lists all agent sessions for the current worktree: when I switched to Orca, it immediately found all my OpenCode sessions running at that time, so I could catch up without losing anything. A third tab covers git: modified and staged files, and you can commit from there (or ask your agent to do it). And the last tab shows the GitHub Actions runs for your pull request, so when I have a draft PR, I can check how the CI is doing without ever leaving Orca.

Those are the three features I use the most, but there are plenty of others. Quick commands let you prepare full scripts to run on a worktree: I have an “Install deps” command that installs everything required when I need tooling like PHP CS Fixer or PHPStan. There is also the mobile integration, which opens a local network tunnel so you can reach your Orca agents from your phone (add a VPN and it works from anywhere; I have used it from time to time at the gym). And this is only a fraction of what Orca offers, there is a lot more to discover.

Section intitulée my-agentsMy agents

Agents are where I invested the most. One more disclaimer: I mainly work with Jira, so some agents below are Jira-flavored, but they can easily be swapped to GitHub issues or Linear if required. Here is the full breakdown of what my agent picker looks like:

• build is the built-in agent that makes changes. It is the only agent in this list allowed to touch the code.
• plan is the other built-in one, used to simply plan things.
• heavy-plan is the same as plan, but backed by a more performant model: if plan runs on a Sonnet-class model, this one runs on an Opus equivalent. I keep it for large or risky work.
• jira-analyst takes a Jira link, looks at all the issue details, its parents, and the opened PRs about these issues, then sums up what is asked, what was already done, and what could be done in the code. This is my number one starting point, 95% of the time.
• jira-feedback covers the next round: QA tested one of my pull requests and found an error. This agent rechecks the Jira ticket from its link, finds the related PR, checks out the branch locally, and tries to understand the feedback and make first guesses.
• pr-review-planner steps in when a PR is open for review and someone left comments: it reads them all and proposes how I could fix them. Addressing a review stops being an archeology session and becomes executing a checklist.
• pr-reviewer is for the other side of reviews: when I have a big PR to review, I always review it myself, and in parallel I run this agent so an AI review can catch things I could, maybe, have missed.

You may notice a pattern: apart from build, these are all analysis agents. They read, summarize, and plan, but they do not touch the code. That constraint is baked into the agent definition itself. Here is an abridged extract of jira-analyst:

---
mode: primary
model: opencode-go/deepseek-v4-flash
temperature: 0.2
---

You are a technical analyst for Jira issues. When given a Jira issue URL or
issue key, you analyze the ticket and deliver exactly two things: a clear
summary of what the issue is about, and a concrete list of actions the
developer must take to resolve it.

You are strictly read-only. You NEVER modify the codebase: no edits, no file
creation, no refactoring, no "quick fixes". Your only output is analysis and
explanation.

### Investigating the codebase

The action plan must be grounded in the real code, not generic advice:

- grep/glob for the classes, routes, services, config keys, or error messages
  mentioned in the ticket.
- Use `git log`/`git blame` on the affected area to find recent related
  changes: regressions are often introduced by an identifiable commit.
- Check `gh pr list --search "<KEY>"` for existing or past PRs referencing
  the ticket.

The read-only rule is not just a promise in the prompt: the same file carries a permission block that makes edits impossible in the first place.

Section intitulée permissions-in-opencodePermissions in OpenCode

OpenCode resolves every tool call to one of three actions: allow runs it without asking, ask prompts me first, and deny blocks it outright. What matters here is that it starts from permissive defaults, most permissions are allow out of the box, so an analysis agent is only read-only if you say so explicitly. In the agent frontmatter, that looks like this:

---
description: Analyze a Jira ticket and produce an action plan
mode: subagent
permission:
  edit: deny
  webfetch: deny
  bash:
    "*": deny
    "git *": allow
    "gh *": allow
    "jira *": allow
---

The permission key is keyed by tool name: read, glob, grep, list, bash, task, skill, webfetch, websearch. You go through them one by one and decide what each is allowed to do, and a "*" entry sets the default for everything you did not name. Note that edit is the one exception to the one-key-one-tool rule: it covers everything that writes to disk, so edit, write, patch and multiedit all sit behind that single deny. The rest stay open, so the agent can still read, grep, glob and run the commands it needs to investigate, and that is all it will ever do.

The bash block is where it gets interesting. Rules are matched by pattern and the last matching rule wins, so the catch-all goes first and the specific rules come after it:

bash:
  "*": deny           # default: nothing runs
  "git *": allow      # ...except git
  "git push *": deny  # ...but never push

Read top to bottom, each line narrows or reopens the one above. Flip the order and the catch-all silently swallows everything else. One last gotcha: patterns match the parsed command, arguments included, so "git" alone only matches a bare git, anything with arguments needs the wildcard.

That block is what turns “please only analyze” into something the agent cannot get around, even if the prompt drifts or the ticket tries to talk it into something else.

And since these agents only analyze, they do not need the most expensive model with high creativity: a cheap, fast model at low temperature does the job, deterministically. If you want the full prompts, all my agents are available in this gist.

Section intitulée when-orca-and-the-agents-click-togetherWhen Orca and the agents click together

Remember the Orca detail I told you to keep in mind: when you create a worktree from an issue, the default prompt is the issue link. This is where it pays off. Since jira-analyst and jira-feedback both take an issue link as their input, I have almost nothing to do. I select my issue in the Jira integration of Orca, it opens a new worktree, starts my agent, and copies the link. All that is left for me is to switch to the right agent and run it. From “I will take this ticket” to “an agent is analyzing it in an isolated worktree”, there are a couple of clicks and zero copy-paste.

The same trick works from the other side, once the worktree is already gone. When a PR comes back to life, because QA found an error or a reviewer left comments, I create a new worktree from the PR itself, in the GitHub integration of Orca this time. The agent opens with the PR link as its prompt, I run jira-feedback or pr-review-planner on it, and everything else is done automatically.

To give you an idea of the rhythm this all creates: at the start of the day, I check whether my current draft PRs have any errors. If they do not, I take up to three or four Jira issues and start my jira-analyst agent on all of them, then usually do some code review while they run. When an agent is done analyzing, a big read awaits me: the idea is to focus the most on the first task to finish, send it off to execution, then take the second one while the first is busy, and so on, until I have no more tasks to do and pick up new issues.

Section intitulée my-commandsMy commands

Where agents carry a full role, commands are closer to recipes: small, repeatable prompts I run on demand. Two of mine are general purpose:

• /commit-and-pr is kind of straightforward: it generates a commit message and a pull request description. If the current repository has a GitHub template available, it uses it as the base for the PR description.
• /activity fetches all my activity from Jira and GitHub over the last 24 hours, to help me not forget stuff during my daily stand-ups.

The other commands are heavily related to my projects, and to understand them you need to know one thing about our workflow: a PR is opened, the PR is reviewed, then it is put in a milestone so it gets deployed to a qualification environment for testing purposes. That is how I came up with these commands:

• /github-awaiting-review fetches all pull requests that are open and waiting for a review, as a list ready for me to copy into Slack.
• /github-milestone-triage fetches all pull requests that have their review and need to be tested, and outputs a nice list I can copy into Slack too.
• /milestone-build takes a milestone link as argument, gathers all the PRs from that milestone, and creates a release branch so we can deploy every change in it. It also handles the merge conflicts along the way.

Section intitulée my-skillsMy skills

For skills, I have no custom-made ones. I use a catalogue instead: most of mine come from superpowers-symfony, a collection of Symfony-focused skills, completed by a few project-related ones describing, for example, how a commit message or a pull request description should be written on each project. This is also what keeps the commit-and-pr command simple: the command does not explain how to write anything, it just does the work, and the conventions come from these skills. That is not much, and it is on purpose: I always felt we reach for skills too often, when what we really want is a command or an agent.

Section intitulée the-permission-philosophyThe permission philosophy

You may have guessed it from the agent breakdown: all my AI tooling is read-only by default, and build is the only agent allowed to write code. That is not an accident, it is the rule everything else follows from. Agents propose, the human decides. Consider it my counterpoint to the “YOLO agents” trend of letting an agent run wild with every permission granted.

Behind that rule sits a conviction: all code generated with any AI is owned by you. The model wrote it, but your name is on the commit. Being AI-generated does not exempt a single line from review: you still have to check what it does, and how it does it, exactly like code you would have written yourself.

The best way to keep that review bearable is to invest before the code exists. I read the plan outputs entirely, every time. I discuss the details with the AI, push back on the parts that do not match what I had in mind, and sometimes adjust my agents’ prompts along the way, so the execution lands as close as possible to what I actually asked for. Then I read the code. All of it, diff by diff, the same way I would review a colleague’s PR: does it do what the plan said, does it do it the way I would have, and is there anything in there I would not be able to explain in six months? Investing in the plan means very few issues are left at that point, but that is the whole point. The review stays short because the work happened upstream, not because I skipped it.

Section intitulée why-this-makes-me-productiveWhy this makes me productive

Time to back all of this with something more concrete than enthusiasm. The gains are not uniform: some are spectacular, some are marginal, and it is worth being honest about which is which.

The core of it all is jira-analyst and jira-feedback, the two agents that made me love this workflow. Where I work, we have a “focus” team: everyone can work on anything, from stocks to retail to customer management. The context switch between issues is huge, and that is exactly what jira-analyst absorbs: it explains everything I need to know before I dive in. Depending on the issue, that saves me up to half a day, sometimes a full day. It is also the agent I have invested the most in: its prompt was improved iteration after iteration to get to the current point.

pr-review-planner is a blessing of the same kind. Review feedback used to take me a lot of time, because each comment demands its context: what code it points at, what the reviewer meant, what the options are. Now I run the agent, read the output, and I have everything I need to decide what to do, comment by comment.

On the command side, github-awaiting-review and github-milestone-triage replaced a chore: going through all the PRs, checking who created each issue and who is reviewing it, building the Slack message, sending it. Depending on how many PRs are open, that could cost me up to 20 minutes. Now I run the command, come back later, and it is done. And the minutes are not even the real win: the real win is that I no longer break my focus for it. Stuff that simple belongs to a prompt, and my attention stays on my tasks. And I will be honest about milestone-build: the raw time saving is small, since before it I would simply git merge each branch into a release branch and push. What it removes is everything around the merges: I no longer handle the conflicts, nor check which PRs should be in, all of that is automated.

Then there is Orca itself. Most of my daily routine now lives in it: I only open Jira to assign tickets to myself, GitHub to review other developers’ PRs, and Slack to share the lists my commands prepare (and if one day I can do all of that from Orca, I will be happy). Fewer tools means less stuff to think about, and everything goes faster. And worktree management deserves a final word: I tried creating worktrees manually, then asking an agent to create them for me. Having tools like Jean and Orca handle it natively is an amazing step forward for this ADE philosophy.

Section intitulée conclusionConclusion

Looking back at the whole journey, the pattern from the beginning still holds: I followed where the tech led me, one more time. From lines of C to libraries, from libraries to frameworks, from frameworks to features. Except this time, the tech is not a language or a framework: it is a coworker. It reads the tickets, analyzes the code, proposes plans; I direct, review, and decide.

And to be honest until the end: not everything is smooth yet. Worktrees are a blessing, but there are still holes, and the biggest one for me is local infrastructure. Running several copies of the same website means Docker conflicts, so when I work in a worktree, I avoid running Docker as much as possible. We worked on tooling to soften this: our containers are now prefixed with the worktree name, for example. But some pieces resist: we use Traefik as our HTTP router, and you cannot run more than one of these, so it will take more work on tooling before all of this runs well side by side.

Rough edges like these are the sign of a young ecosystem, not of a wrong direction. IDEs took decades to become what they are; ADEs are barely getting started, and they already changed my daily work more than any tool since frameworks. I do not know which ADE will win, or if the ones I use today will still be here in five years. But I know I am not going back to an environment built for me alone: agents have joined the team now, and they deserve a good office too.