DEV Community: Angélo Lima

The AI Bubble: Before the Storm

Angélo Lima — Fri, 30 Oct 2026 23:08:00 +0000

Strained credit, punished earnings, shrinking GDP, fewer juniors hired: what late October 2026 signals for tech, France and employment

On Arrakis, a storm rarely arrives all at once. The wind shifts, the air thickens, a dark line rises on the horizon, and people who live in the desert know that by then, they should already have chosen their shelter.

Arrakis is the desert planet of Dune, Frank Herbert's 1965 novel. The whole economy of the Empire depends on a single resource there, the spice, extracted at great cost under the constant threat of storms. The image fits AI uncannily well: an entire economy hanging on one scarce, expensive resource, compute, and companies investing fortunes on the bet that the sky will stay clear.

This week had that color. On October 29, Alphabet lost 12.6%. The next day, Intel fell 28.6% and the Nasdaq 2.9%. That same Friday morning, Insee announced that French GDP had shrunk. None of this is a bubble bursting yet. These are gusts, and they tell you which way the wind is blowing.

In brief

What: a sharp correction in AI stocks on October 29 and 30, 2026, triggered by results from Alphabet, Amazon and Intel. Not yet a bubble bursting.

Key figures: Alphabet -12.6% in one session and -$9.1 billion of free cash flow in Q3. Intel -28.6%, its worst day since 1974. Nasdaq -2.9% on October 30.

What the market punished: the cost of AI. Demand keeps growing (Google Cloud +103%, AWS +39%, Azure +48%).

The most worrying sign: credit. CoreWeave and Oracle are paying for their debt at the price of fragile companies.

In France: GDP -0.1% in Q3, unemployment at 8.3%, 10-year OAT yield above 5%. And Capgemini is cutting 2,409 jobs in France while growing worldwide.

The wind shifts

The first signs came from the debt market, which few people watch. In mid-October, the cost of insuring against a default by CoreWeave, which rents computing power to AI companies, went above 1,000 basis points according to LSEG data. That is distressed territory. Oracle's, which builds data centers for OpenAI, hit a record 288 basis points on October 15. An Evercore ISI trader quoted by CNBC put it in two words: the market is saying "no más" to AI debt without operating cash flow behind it.

Elsewhere, the storm has already passed. In China, the STAR50 AI index has lost about 40% since its July peak, wiping out some $480 billion according to Yahoo Finance.

At the center of it all is compute, the spice of this economy. According to estimates in circulation, Alphabet, Amazon, Microsoft and Meta will spend between $725 and $760 billion on capital expenditure this year. Nvidia is financing up to $105 billion for an OpenAI data center in Ohio, according to CNBC. The supplier lends to its customer so the customer can buy its product. That kind of arrangement holds up fine as long as money keeps flowing. The bill is physical too: data centers used 448 TWh in 2025 and are projected to reach 945 TWh in 2030, roughly Japan's consumption, as I detailed in my piece on AI's ecological footprint.

The first gusts

They came with quarterly earnings. On the evening of October 28, Alphabet reported 103% growth at Google Cloud. But the group spent $51.4 billion on capital expenditure in the quarter, leaving free cash flow at -$9.1 billion, far from what analysts expected. The 2026 budget stays at $195-205 billion, and management expects a "significant" increase in 2027. The next day, the stock lost 12.6% and nearly $500 billion in value, its worst session since going public.

Amazon followed on the evening of the 29th. AWS posted its fastest growth since late 2021, at 39%, with a $578 billion backlog. But trailing twelve-month free cash flow fell to -$42.4 billion. The stock fell as much as 7% after the close, before limiting the loss to 1.4% on Friday.

Intel, on the 30th, is a separate case. Its 28.6% drop, which CNBC tied to the PC slowdown, also stems from a manufacturing incident, with no direct link to AI. In this climate, the market didn't sort things out.

Microsoft was spared. Azure grew 48%, capital spending came in below what the company had guided, and free cash flow beat expectations by $10 billion. The stock rose as much as 4% after the release, then ended the next session almost flat (-0.2%), the day Alphabet lost 12.6%. The gusts hit those who pay for AI without being able to show the return yet.

Last year, I wrote about Sam Altman's statements on the bubble. The OpenAI CEO spoke of a "grain of truth" that gets smart people overexcited. The grain of truth is still there, as cloud growth rates show. Its price is what worries people.

What would be swept away

The S&P 500 lost only 1.8% on October 30, and most analysts quoted by CNBC call this a correction like others before it. For the real storm to arrive, funding would have to dry up: a heavily indebted player unable to refinance, an OpenAI partner pulling out, or a giant announcing it is cutting capital spending. A bubble usually bursts when money stops flowing.

If it came, it would first take whatever has no foundations: compute providers financed on credit, and hardware suppliers whose entire growth depends on data centers. It would also hit Anthropic's IPO, expected around November 16, whose S-1 I went through this week. Listing on the Nasdaq in this climate will be a test.

France, exposed

France goes into this period with few reserves. On October 30, Insee reported that GDP fell 0.1% in the third quarter, after stagnating in the second, and unemployment stood at 8.3% in the second quarter. Since October, the state has been borrowing at more than 5% over ten years, a first since 2002 according to Boursorama. In August, ECB economists warned that if tech valuations corrected, European authorities would have little room to cushion the shock (CNBC). For France, the danger would be an AI correction driving investors away from anything that looks fragile, government debt included. The Paris stock exchange ended October almost flat: AI hardware names fell, IT services stocks rose.

The ground after

A storm moves things as much as it destroys them. When the wind drops, the terrain has changed. That is already happening to tech jobs, before the storm is even here.

On October 30, Capgemini reported quarterly revenue of €6.07 billion, up 11.7% at constant exchange rates, and raised its full-year target. The group has 417,500 employees, 18% more than a year ago, mostly thanks to the acquisition of WNS, which is largely based in India. In France, it signed a collective voluntary departure agreement in May covering 2,409 jobs, about 7% of its French workforce. One figure goes almost unnoticed: bookings grew only 3.4%, three times slower than revenue.

The rest of the sector is moving cautiously. Numeum, the French digital industry body, forecasts 3% growth for the French digital market in 2026, but only 1.4% for IT services firms, and 35% of them expect lower margins. Sopra Steria posted 4.3% organic growth in the third quarter.

The youngest feel the ground move the most. According to the 2026 Numeum-KPMG survey, 62% of French IT services firms say AI is already weighing on their hiring, 47% require AI skills from the start of a career, and 22% see junior hiring falling sharply, versus 9% rising. In the United States, a Stanford study based on ADP payroll data found employment 19% lower in June 2026 among 22-25 year-olds in AI-exposed jobs. According to Indeed, 71% of the increase in developer job postings between May 2025 and May 2026 was for senior roles. The French executive recruitment agency Apec still forecasts about 61,000 IT executive hires in 2026, up 4%, but those projections predate the negative GDP figure.

A market correction would speed this up. Companies under pressure look for savings, and AI is the easiest promise to sell to a board. In my analysis of whether AI will replace developers, I noted that AI excels at repetitive tasks, scaffolding, test generation and documentation, and that the profession is shifting toward architecture. Those are exactly the tasks juniors used to learn on. In May, before the French National Assembly, Arthur Mensch said AI consumption already amounted to 10% of Mistral's payroll (I analyzed that hearing). Behind that ratio, there are jobs.

The profiles that hold are the ones with foundations: architects, tech leads, security and cloud specialists, and people who know how to orchestrate models instead of competing with them. The Forward Deployed Engineer role, which AI vendors are hiring by the hundreds to plug their models into customers' systems, is one example.

What I'm watching

November 3, the US midterm elections, with the risk of escalation with Iran right after. Around November 16, Anthropic's IPO. November 17, Nvidia's earnings. November 27, the detailed French GDP figures, with the budget vote and the spread over Germany in the background.

And above all, two signals worth more than any trading session: a tech giant cutting its capital spending, or an indebted player like CoreWeave failing to refinance. If either shows up, it will no longer be gusts. And on Arrakis, once the wall of sand is visible, it is already too late to look for shelter.

Figures come from the financial press (CNBC, Reuters, Yahoo Finance, Bloomberg, Boursorama), Insee, Numeum, Apec and company releases, accessed on October 30, 2026. Stock moves are closing prices unless stated otherwise.

Illustration: "Le Simoun", lithograph by E. Warnots after Jean Portaels, Salon of 1848 (British Museum, public domain, via Wikimedia Commons).

Frequently asked questions

Did the AI bubble burst in October 2026?

No. In late October 2026, AI stocks went through a sharp correction: Alphabet lost 12.6% on October 29, Intel 28.6% and the Nasdaq 2.9% on October 30. But AI demand kept growing and the S&P 500 fell far less (-1.8%). Analysts called it a correction, with more worrying signs of strain in credit markets.

Why did AI stocks fall in late October 2026?

Investors punished the cost of AI rather than its demand. Alphabet reported negative free cash flow of $9.1 billion in Q3 2026 despite 103% growth at Google Cloud, and Amazon's trailing twelve-month free cash flow fell to -$42.4 billion. Microsoft, which spent less than expected, was spared.

What are the warning signs of an AI bubble bursting?

The most closely watched signals in October 2026 were in credit: CoreWeave's credit default swaps traded above 1,000 basis points and Oracle's hit a record 288 basis points on October 15. A real burst would more likely show up as a heavily indebted player unable to refinance, or a tech giant cutting its capital spending.

Is France exposed to an AI bubble correction?

France is exposed mostly indirectly. French GDP shrank 0.1% in Q3 2026 according to Insee, unemployment stood at 8.3% in Q2, and the 10-year OAT yield went above 5% in October for the first time since 2002. In August 2026, ECB economists called a correction in tech valuations likely, warning that European authorities would have little room to cushion its effects.

Are IT services firms and junior developers at risk?

Capgemini signed a collective voluntary departure agreement covering 2,409 jobs in France in May 2026, while reporting 11.7% growth in Q3. According to the 2026 Numeum-KPMG survey, 22% of French IT services firms see junior hiring falling sharply versus 9% rising, and 47% require AI skills from the start of a career.

Originally published on angelo-lima.fr.

Forward Deployed Engineer: the job AI borrowed from Palantir

Angélo Lima — Fri, 30 Oct 2026 23:07:41 +0000

Origins, day-to-day work, pay and criticism: what we know about the FDE, the role OpenAI, Anthropic, Google and AWS are all hiring for in 2026

For a long time, this job title was a Palantir thing. In 2026, OpenAI, Anthropic, Google, AWS and Microsoft are hiring them by the hundreds, and every career site has published its own "complete guide to the Forward Deployed Engineer". I wanted to understand what sits behind the label, because a lot of the job descriptions read like what developers who spend their careers on client engagements have been doing for years.

In brief

What: a Forward Deployed Engineer (FDE) is a software engineer sent to a customer by a product vendor, to integrate that product and get it into production inside the customer's systems.

Origin: Palantir, which has used the title since at least 2009 and calls these engineers "Deltas".

Key figures: according to data cited by the Financial Times, FDE job listings jumped more than 800% between January and September 2025. In 2026, OpenAI, Anthropic, AWS ($1 billion) and Microsoft ($2.5 billion) created dedicated organizations.

What it really is: a hybrid of developer, consultant and project lead, directly accountable for results at the customer.

The catch: travel, pressure, technical debt left behind at customers, and a less clear-cut career path than product engineering.

First, where the word comes from

"Forward-deployed" comes from US military jargon, where it describes a unit positioned forward, as close to the action as possible. Palantir picked it up in the 2000s to name the engineers it placed physically at customer sites, starting with government and defense agencies. Its data analysis software was useless until it was connected to each organization's databases, formats and habits. Instead of waiting for customers to do that themselves, Palantir sent its own developers.

Palantir's engineering blog explains that internally, it distinguishes "Devs", who build the product, from "Deltas", who deploy it at customers. The name "Delta" is a leftover from the company's early days, when every Business Development team was named after a letter of the NATO alphabet. Deltas also reported to business development rather than engineering.

Why AI brought the model back

Generative AI recreated Palantir's exact problem. A language model looks impressive in a demo, but before it can take orders, answer customers or process files, someone has to connect it to internal data, APIs and business rules, and evaluate its answers on real cases. That work does not come off the shelf.

In June 2025, Andreessen Horowitz partner Joe Schmidt published an essay that got passed around a lot, Trading Margin for Moat. He argues that enterprise AI startups are wrong to chase classic software's 80% gross margin right away. He points out that ServiceNow had a 63.2% gross margin at its IPO and Workday 54.1%, because both vendors did a lot of integration work for their customers. By 2024, their margins had climbed back to 79% and 75%. Integration is expensive at first, but once the software sits at the heart of a customer's processes, it becomes very hard to rip out. When the essay came out, 22 of OpenAI's 311 open roles were forward deployed or solutions positions.

Another figure, reported by AFP from a McKinsey study, explains the current rush: at the end of 2025, nearly nine in ten companies had deployed AI in at least one business function, yet 94% reported no significant benefit. Vendors sell licenses that customers don't know how to use, and they now send engineers to do it for them.

2026, the year everyone joined in

The job posting numbers are spectacular, though they deserve some caution. According to data cited by the Financial Times, monthly FDE listings rose more than 800% between January and September 2025. Indeed figures reported in the press show 643 postings in April 2025 and 5,330 in April 2026.

More importantly, the big players built whole organizations around the role. According to The Pragmatic Engineer and the business press:

Date (2026)	Company	Announcement
May 4	Anthropic	A separate FDE consulting company, funded with Blackstone, Hellman & Friedman and Goldman Sachs, to bring Claude into mid-sized companies
May 11	OpenAI	The OpenAI Deployment Company, a standalone entity funded with $4 billion from TPG, Advent and other firms, valued at $14 billion
May	Google Cloud	A new AI organization within the go-to-market teams, hiring FDEs directly
June 30	AWS	A Forward Deployed Engineering unit backed by $1 billion
July 2	Microsoft	Microsoft Frontier Company, $2.5 billion and 6,000 experts and engineers

OpenAI also acquired Tomoro, a UK company founded in 2023 that employs 150 FDEs across the UK, Asia and Australia. Gergely Orosz points out a detail that matters to candidates: at OpenAI and Anthropic, FDEs are hired by these separate companies, so any equity they get is not equity in the lab. Google hires its FDEs directly, with Google stock.

At Anthropic, this new structure sits alongside the Applied AI team, which was already hiring FDEs who "embed directly with our most strategic customers", according to its job postings. The same logic shows up in Anthropic's IPO filing, where the number of large enterprise customers is one of the headline metrics.

What an FDE's week looks like

The job descriptions all look alike. The FDE spends time with the customer's business teams to understand the real problem, which is not always the one they describe. They write prototypes, then integrations meant to last: connectors to databases, calls to internal APIs, agents, evaluation sets to measure the quality of the model's answers. They debug in environments they don't control, under the customer's security and network constraints. And they report back to the product team whatever keeps coming up from one customer to the next, so the next integration needs less custom work.

Gergely Orosz estimates that an FDE role at Google splits roughly into 25% coding, 50% integration and plumbing, and 25% meetings and customer work. It's an estimate, but it gives a good sense of the balance.

The required skills follow from that. You need a general-purpose language (Python and TypeScript come up often), a good grasp of APIs and data, and for AI roles, experience with LLMs in production, agents and evals. You also need to talk to a business director as easily as to a sysadmin, run a demo, and say no to a request that makes no sense. People who already practice agentic development day to day have a head start, because they already know where a model goes wrong and how to keep it in check.

What it pays

Lots of numbers are floating around, and most come from sites selling training or recruiting services. I only keep the ranges visible in actual job postings.

At Anthropic, Applied AI FDE postings published in 2026 in San Francisco and New York listed a base salary of $200,000 to $300,000 a year, not counting equity.

France is another planet. Paris startups such as Gladia advertise ranges around €45,000 to €70,000. OpenAI has posted an FDE role in Paris, but I couldn't find a verifiable salary for it.

The on-site consultant, vendor edition

Reading all this, a developer who has worked for a French IT services firm (an ESN) will get a strong sense of déjà vu. Being placed at the customer, learning their business, integrating a product into an information system you didn't design, living with its security rules and habits, all of that has been the daily life of tens of thousands of consultants in France for decades.

The difference lies in who sends the engineer. The ESN consultant works for a services company, independent of the tool being integrated. The FDE is sent by the vendor itself, and part of the job is to improve the product based on what they see in the field. When that feedback loop works, every deployment makes the next one easier. When it doesn't, the FDE is doing custom services work under a flashier title.

The criticism

That is exactly the best-known complaint. In May 2026, on the 20VC podcast, Chris Degnan, Snowflake's former chief revenue officer turned investor, called the FDE "a glorified professional services person". According to Business Insider, he added: "If you're a really good engineer, you do not want to be a forward-deployed engineer." His point: the best engineers want to work on the product, and FDEs leave custom code behind at customers, who then have to maintain it. "There's a lot of technical debt that forward-deployed engineers are going to leave, and there's a lot of risk."

The other complaints come up in most first-hand accounts:

Travel: LeadDev cites an OpenAI posting that called for up to 50% travel, and sees an earlier burnout risk in it.
Pressure: when the system goes down, the customer is in the same room.
Scattered focus: constant context switching means you rarely master one codebase in depth, which can make it harder to move back into a pure R&D role.
Vagueness: the title covers very different realities from one company to the next, from senior developer to technical salesperson.

One question is missing from the job descriptions. Will AI replace developers? asked what would be left for developers if AI wrote a growing share of the code. What's left looks a lot like the FDE's work: understanding a real problem, scoping it, integrating, owning what goes to production. You can see that as a new job, or simply as the part of a developer's job that models can't do yet.

My takeaway

The Forward Deployed Engineer is not a 2026 invention. Palantir has been doing it for more than fifteen years, and French IT services firms have known a version of it for much longer. The scale and the money are new, though. The biggest AI players are putting billions into it, because they've understood that a model is of little use without someone on site to make it work.

For a developer, the role has real appeal. You see the effect of your work at the customer, and the big vendors pay above market. In return, you have to accept the travel and a less mapped-out career. Before applying, I would ask the employer one question: will what I see at customers actually make it back into the product?

Frequently asked questions

What is a Forward Deployed Engineer (FDE)?

A Forward Deployed Engineer is a software engineer sent to a customer by a product vendor to build and ship production solutions on top of that product. The FDE scopes the need with business teams, writes the integrations, deploys them, and feeds back to the product team whatever could help other customers.

Where does the Forward Deployed Engineer role come from?

Palantir popularized the role and was using the title by 2009 to deploy its platforms at customers such as US government agencies. Internally, Palantir calls these engineers "Deltas", as opposed to the "Devs" who build the product. The phrase "forward-deployed" comes from US military jargon.

Why are AI companies hiring FDEs?

An AI model only creates value once it is wired into a company's data, APIs and processes, and that integration work is hard to standardize. In 2026, OpenAI, Anthropic, Google Cloud, AWS and Microsoft all set up dedicated organizations to send engineers to their customers.

How much does a Forward Deployed Engineer earn?

In the US, Anthropic's 2026 job postings for an Applied AI Forward Deployed Engineer listed a base salary of $200,000 to $300,000 a year. In France, Paris startups advertise roughly €45,000 to €70,000. Pay varies enormously by employer, level and country.

What is the difference between an FDE and a consultant?

A consultant works at the customer's site on behalf of a services firm, whatever tool is involved. An FDE is sent by the product vendor itself and is expected to improve that product based on what they see in the field. Critics such as former Snowflake CRO Chris Degnan see the role as professional services with a new name.

Originally published on angelo-lima.fr.

I went looking for an IDE built for coding agents. I stayed with Orca.

Angélo Lima — Thu, 15 Oct 2026 14:34:06 +0000

IntelliJ and VS Code weren't designed to drive agents. Zed was, but I was missing everything around the editing. Six weeks with Orca, one worktree per session, scheduled tasks and a home-made plugin to keep an eye on the bill.

For years, my IDE was a settled question. IntelliJ at work, VS Code for everything else. Then agents showed up, and the question reopened without warning.

My days had changed. I write less code in a file and spend more time launching tasks, reading diffs, and answering an agent that is waiting for my go-ahead while another one works away in its corner. IntelliJ and VS Code weren't built for that. You bolt on a Claude Code plugin, a chat panel, an integrated terminal, and you end up juggling windows, branches and forgotten git stash entries.

Zed is a different story. It was designed for the agentic era: the Agent Client Protocol (ACP) to plug Claude Code, Codex or Gemini CLI straight into the editor, and since its 1.0 release in late April 2026, parallel agents each isolated in a worktree. It was the closest to what I was after. What I was missing sat around the editing: tasks that run without me on a schedule, a tool the agent itself can drive from the command line, and an easy way to extend it.

I tried quite a few things. Since mid-August I've been on Orca, and for the first time in a long while I don't feel like looking elsewhere.

In brief

What: Orca is an open-source (MIT) desktop development environment built to run several coding agents in parallel. Made by Stably AI, available on macOS, Windows and Linux.

The idea: every session gets its own git worktree, agent terminal and browser tab. Agents stop stepping on each other.

Supported agents: Claude Code, Codex, OpenCode, Cursor CLI, GitHub Copilot CLI, Gemini, and in practice any agent that runs in a terminal.

What sets it apart: an agent dashboard, scheduled automations, a CLI and skills the agent itself can use, a plugin system.

The catch: each worktree duplicates dependencies (disk, memory), and more agents in parallel means more tokens and more diffs to review.

What Orca is, in two sentences

Orca calls itself an "agent development environment". In practice, it's a desktop app where every task lives in a dedicated git worktree, with a terminal for the agent, a file editor, a diff viewer, a built-in browser, and access to GitHub pull requests (and Linear tickets).

The project is open source on GitHub, made by Stably AI, a San Francisco startup. It started in spring 2026 and gathered tens of thousands of stars within a few months, shipping releases almost daily. It's a young tool, and sometimes it shows. More on that below.

What Orca isn't: an agent. It has no model of its own. It orchestrates the ones you already use. For me that's mostly Claude Code, but nothing stops you from running another one in the next tab.

One worktree per session: the click

If I had to keep just one thing, it would be this.

A git worktree, for those who've never needed one, is a second working folder attached to the same repository but on another branch. Same history, separate files. I mentioned them in the article on Claude Code and Git workflows as a trick for advanced users. Orca has made them its foundation since the first commit: every new session creates its worktree, its branch, its terminal. Zed adopted the same approach for its parallel agents, which says a lot about the idea. In Orca it applies to any command-line agent and to several repositories at once.

The effect on how I work was immediate. Before, running two agents on the same project meant risking both editing the same file, or one reading code the other had half rewritten. So I didn't. I serialised. One task, wait, review, next.

Today I open a session to fix a bug, another for a dependency migration, a third to explore an idea I might throw away. Each moves forward on its own. When one is ready, I read the diff, push, open the PR, and delete the worktree. The others never noticed.

That's what I call multiplexing. Code doesn't come out of any single session faster, but nothing waits for the previous one to finish anymore. It works across projects too: three repositories, each with its sessions, in the same window.

The cost is real. Each worktree has its own node_modules (or equivalent), so disk fills up fast on a big project. A write-up by Margrop puts memory at about 2 GB per active agent, so around ten gigabytes for five agents in parallel. I haven't measured that precisely, but the order of magnitude feels right. Orca can push worktrees to a remote machine over SSH, which solves part of the problem.

The dashboard: who is waiting for what

Launching five sessions is easy. Knowing which one has been waiting for an answer for twenty minutes is another matter.

Orca shows the state of every agent: working, done, or blocked on a permission request. An overview gathers all sessions, with notifications when an agent needs you. It sounds minor. In practice, it's what makes parallelism sustainable. Without it, I kept making rounds of the terminals to check whether anyone had finished.

There's also a mobile app (iOS and Android) to follow agents and nudge them from your phone. Handy on the day a session needs approval while you're away from your desk.

Claude Code, Codex, or whatever you like

Orca doesn't impose an agent. It runs whatever works in a terminal: Claude Code, Codex, OpenCode, Cursor CLI, GitHub Copilot CLI, Gemini, and a long list of others. You can even send the same prompt to several different agents, each in its own worktree, and compare the results. Zed also lets you switch agents through ACP; Orca only needs a terminal, so an agent requires no specific integration to run in it.

That matters to me. I've spent enough time comparing tools (Claude Code, Cursor and Copilot, among others) to know none of them is final. I don't want my working environment to depend on a single vendor. With Orca, if another agent does better on some kind of task tomorrow, I add it in a tab. My habits, shortcuts and worktrees stay the same.

Scheduled tasks, or the agent that works on Monday morning

This is the feature I didn't expect and use the most.

Orca has an automation system: a prompt, an agent, a repository or worktree, and a schedule. The schedule accepts presets (hourly, daily, weekdays, weekly), a cron expression or an RRULE, with time zone support. You can also set a precheck, a small shell command that skips the run if it fails, so you don't burn tokens for nothing.

I have two running permanently.

Dependabot follow-up, once a week. Dependabot PRs pile up on my repositories. Individually they're trivial. Collectively nobody wants to deal with them. Now, every week, an agent goes through them, checks which pass CI and which break something, and prepares a summary of what can be merged as is and what deserves a closer look. I keep control of the merge. But the triage is done by the time I arrive.

Preparing the team daily. Every weekday morning, an agent gathers what moved since the day before: PRs opened and merged, pending reviews, tickets that changed state. I walk into the daily with a clear view instead of reconstructing yesterday from memory.

Here's what creating an automation looks like from the command line (repository name and prompt are examples):

orca automations create \
  --name "Weekly Dependabot" \
  --trigger "0 8 * * 1" \
  --timezone Europe/Paris \
  --prompt "List open Dependabot PRs, check their CI and summarise what can be merged" \
  --provider claude \
  --repo my-repo

Then orca automations list, run or edit to manage them. The UI does the same thing, with ready-made templates.

The CLI and skills: Claude Code handles the rest

This is where I understood Orca was designed by people who actually work with agents.

Everything the UI does is available through the orca CLI: create a worktree, read a terminal's output, send a command to another terminal, open a file, drive the built-in browser, manage automations. And Orca ships skills (in the sense of Claude Code skills) that teach the agent how to use that CLI. One command installs them:

npx skills add https://github.com/stablyai/orca --skill orca-cli --global

The upshot is that I hardly configure anything by hand anymore. I ask Claude Code to create the Dependabot automation, prepare three worktrees for a batch of tickets, or add a new project to Orca. It does it. What we used to set up through menus, we now describe in one sentence to an agent that has the tools to do it.

There are other skills for multi-agent orchestration (one agent handing work out to others), Linear, and driving iOS and Android emulators.

Plugins: I built one to track my usage

Last point, and the newest: Orca has a plugin system. It's still young (flagged experimental when it landed, and the repository issues show the API growing request by request), but it already lets you add panels, commands and shortcuts, and listen to application events.

I had a specific need. When you run many agents in parallel, usage goes up, and it goes up quietly. I'd already written about Claude Code billing, but I lacked a simple view of where the tokens were going.

So I built a plugin. It shows my usage per project and per model, with a monthly view, and surfaces the most expensive sessions. That last view is the one I check most. An exploration that was too vague, an agent looping on a test that won't pass: that kind of session jumps out at the top of the list, and it nudges you to frame your prompts better.

And like everything else, Claude Code wrote most of the plugin, from the documentation and the API Orca exposes.

What still gets in the way

I won't pretend it's all perfect.

The release pace. Releases almost every day are great for new features, less so for stability. You have to accept that the tool moves under your feet.

Resources. As mentioned above: disk, memory, and above all tokens. Five agents in parallel is potentially five times the usage. The tool makes parallelism easy. It doesn't make it free.

Review. More agents means more code produced, so more diffs to read. Orca helps (diff annotations, built-in PR review), but the bottleneck is me. If I don't review, I shouldn't merge.

The editor. Orca doesn't support VS Code extensions. For a big manual refactoring session, with the debugger and a language's full tooling, IntelliJ still has the edge. For me, that's become the exception.

Six weeks later

What changed, deep down, is the shape of my workstation. It's no longer organised around an open file. It's organised around tasks in progress, each in its own box, with someone (something) working on it while I do something else.

IntelliJ and VS Code remain excellent editors, designed around someone who writes code. Zed has made the move to agents, and made it well. Orca starts directly from someone who puts agents to work, schedules them, watches them and reviews what they produce. That's what I do most of the time now, and that's why I stayed.

If you want to try it: it's free, installs in a few minutes from onorca.dev, and your current agents work in it as they are. Start with two parallel sessions on a project you know well. You'll quickly see whether it clicks.

Frequently asked questions

What is Orca?

Orca is an open-source (MIT) desktop development environment built to run several coding agents in parallel. Each task gets its own git worktree, agent terminal and browser tab. It is made by Stably AI and runs on macOS, Windows and Linux.

Is Orca free?

Yes. Orca is free and open source under the MIT license. The agents you run inside it are billed separately under their own model: an Anthropic subscription or API key for Claude Code, OpenAI for Codex, and so on.

Does Orca work with Claude Code?

Yes. Orca runs any command-line agent in a terminal: Claude Code, Codex, OpenCode, Cursor CLI, GitHub Copilot CLI, Gemini and more. You can even run several different agents on the same task, each in its own worktree.

Why does Orca use git worktrees?

A git worktree is a second working directory attached to the same repository, on a different branch. By giving each session its own worktree, Orca stops two agents from editing the same files at the same time: each works in its own folder, and changes are merged later through a pull request.

What is the difference between Orca and Zed?

Zed is a fast code editor built for agents: it integrates Claude Code and others through the Agent Client Protocol (ACP) and, since its 1.0 release (April 2026), runs parallel agents in git worktrees. Orca is an environment built around orchestration: it runs any terminal agent and adds scheduled automations, a CLI agents can drive, and a plugin system.

Can Orca run recurring scheduled tasks?

Yes. Orca automations launch an agent with a given prompt on a schedule (hourly, daily, weekdays, weekly, a cron expression or an RRULE), against a specific repository or worktree. They can be created from the UI or with the orca automations create command.

Originally published on angelo-lima.fr.

AI and ecology in 2026: the prompt is light, the infrastructure is heavy

Angélo Lima — Thu, 15 Oct 2026 14:33:47 +0000

A prompt uses 0.24 Wh. Data centers could use as much electricity as Japan by 2030. The October 2026 numbers, without doom or greenwashing.

A prompt uses less energy than an LED bulb left on for two minutes. And yet AI is becoming a real burden on power grids and water resources. Both sentences are true. That is the whole problem.

In 2025 I wrote a post on the ecological cost of AI. The question that framed the debate back then: what weighs more, training a model or using it?

A year and a half later, that question is largely settled. The cost of a single prompt stopped being contentious once the big AI companies published measurements. The argument is now about total volume, about water, about hardware, and about what agents are going to do with all of it.

So is AI an environmental burden, true or false? I went through the numbers available in October 2026 to find out.

In brief

One prompt: 0.24 Wh, 0.03 g of CO₂e and 0.26 mL of water for a median Gemini text request (Google, 2025). About 0.34 Wh in ChatGPT according to OpenAI.

Data centers: 448 TWh in 2025, 945 TWh projected for 2030, roughly Japan (United Nations University, June 2026).

The paradox: energy per AI task drops nearly tenfold every year, yet data center demand grew 17% in 2025.

The blind spot: water (consumption doubling by 2030) and chip manufacturing, which dominates several impact categories of a GPU.

The verdict: false at the individual level, true at the collective level, especially true at the local level.

The prompt, a featherweight

A standard text prompt now uses between 0.24 and 0.34 Wh. That is the first big change since 2025: these figures are measured.

Google instrumented its infrastructure for a year. The median text request in Gemini uses 0.24 Wh, emits 0.03 g of CO₂e and consumes 0.26 mL of water (source). Over the same period Google reports a 33-fold drop in energy per prompt.
OpenAI reports about 0.34 Wh for an average ChatGPT request.
Mistral published a full life-cycle assessment of Mistral Large 2, server manufacturing included, following the French AFNOR frugal AI framework, with ADEME and Carbone 4 (source).

These figures demolish the shock comparisons that were going around two years ago, like "a bottle of water per request". A 2023 study estimated 10 to 50 mL of water per prompt for GPT-3, 40 to 200 times more than Google's measurement (source).

They still need to be read carefully. Google gives a median rather than a mean, says nothing about prompt length or complexity, and only covers the Gemini app. Google's and OpenAI's numbers are not directly comparable (source). They are orders of magnitude and should be read as such.

A prompt next to everyday objects

For everyday use, an electric car or an air fryer uses far more than a chatbot. Twenty minutes of air frying is worth about 2,000 text prompts, a 10 km drive in a compact EV about 7,000, and the same drive in a large electric SUV over 10,000.

Three caveats keep this from being the end of the story:

Not all prompts are equal. A long reasoning prompt already uses more than two smartphone charges. A heavy agentic task can be worth several kilometres in an EV.
Look at what each use replaces. The EV replaces a petrol car, the air fryer often replaces an oven: both can lower the overall footprint. A good share of AI use is added on top without replacing anything.
Only usage electricity is counted here. Manufacturing a car battery or data center GPUs changes the picture, as we will see.

The paradox: each task costs less, the total explodes

In 2025, data center electricity demand grew by 17%, against 3% for global electricity demand. Over the same period, energy per AI task dropped nearly tenfold each year (source).

This is an almost perfect Jevons paradox. When a resource gets cheaper to use, we use so much more of it that total consumption rises. There are more users, and each of them runs heavier tasks, like agents or reasoning models.

The projections all point the same way, towards a doubling by the end of the decade (UN, Gartner).

And that electricity is not clean: according to the IEA, about 40% of the additional data center consumption through 2030 will still be met by gas and coal (source).

The impact is also highly concentrated. Data centers already account for more than 20% of Ireland's electricity, against 2 to 3% on average in the EU (source). AI will not bring down the global grid. It can saturate a local one.

Beyond carbon: water, hardware, waste

Carbon is only part of the impact, and probably not the most worrying part. Kaveh Madani, lead author of the June 2026 UN report, says it plainly: the debate still treats AI as software, when it is a physical infrastructure made of power plants, chips, minerals, land and water (source).

Carbon: significant, not outsized. Data centers already emit as much CO₂ as Argentina (source). Against the roughly 37 billion tonnes emitted worldwide each year, that is around 0.5%, and AI is only part of it. Hyperscalers claim 92% of their energy comes from low-carbon sources, but partly through purchase agreements (source).

Water: the real hotspot. According to the UN, data center water consumption should more than double by 2030 (source). Over 21% of US data centers sit in basins with medium to high water stress (source). And the reported figures are underestimates: the water used by the power plants feeding them is reportedly about 12 times their direct consumption (source).

Manufacturing: the blind spot. A life-cycle assessment of the Nvidia A100 GPU shows that manufacturing dominates several impact categories over the whole life cycle, well beyond carbon alone (source). Cobalt, tungsten, lithium: each chip contains little, but demand is climbing fast.

E-waste. A high-end GPU can be outdated in under two years (source). Yet only 22% of e-waste is collected and recycled worldwide (source).

Agents push the cost per task back up

The training versus inference debate from my 2025 post is settled: more than 80% of AI's electricity use now comes from the usage phase (source). A model is trained once. It answers billions of times.

And usage is changing shape. A long advanced reasoning prompt can exceed 33 Wh, more than 130 times a standard text prompt (source). A coding agent that chains dozens of calls, rereads files, runs tests and starts over is another scale entirely.

This is where the "cost per token is falling" line becomes misleading. Cost per token is falling, yes. But the number of tokens per task is exploding. I see it every day working on an agentic platform: the number I track is the cost of a finished task. A single prompt tells you almost nothing. I reached the same conclusion with the Claude Code bill, where the whole session is what costs money.

So, environmental burden: true or false?

Both, depending on the scale you look at.

False at the individual level. Your prompt is not destroying the planet. Shaming someone for asking a chatbot a question while they drive to buy bread makes no sense.
True at the collective level. AI has become a significant and growing load on power grids, with a mix that is still largely fossil.
Especially true at the local level. Water, grid saturation and pushback from residents all play out where data centers are built.
Underestimated on the hardware side. Chip manufacturing and e-waste remain the big absentees from per-prompt figures.

The UN's wording seems the most accurate to me: AI will not exhaust water or electricity globally, but poorly planned expansion can collide with resources that are already under strain in specific places (source).

What developers and teams can do

The lever that matters most is sizing. Mistral's analysis shows that impact roughly tracks model size: a model ten times larger costs about ten times more for the same number of tokens (source).

Route to the right model. A small model to classify, summarise or extract, possibly running locally with Ollama. The big reasoning model only when the task calls for it.
Measure per task, not per prompt. Track tokens consumed per completed task, especially for agents.
Limit loops. Cap agent iterations, cache, avoid reloading the whole context on every call.
Choose where the compute runs. A cloud region with low-carbon electricity and little water stress genuinely changes the footprint.
Ask whether AI is needed at all. It is the first question in the AFNOR frugal AI framework (source). A regex is still cheaper than an LLM.

A prompt weighs nothing. A poorly sized agentic architecture, deployed to thousands of users, weighs a lot. And that architecture is designed by teams like mine.

Sources

Frequently asked questions

How much energy does an AI prompt use in 2026?

A standard text prompt uses between 0.24 and 0.34 Wh in 2026. Google measures 0.24 Wh, 0.03 g of CO₂e and 0.26 mL of water for the median text request in Gemini; OpenAI reports about 0.34 Wh for an average ChatGPT request. That is less than an LED bulb left on for two minutes.

Does a ChatGPT prompt use a bottle of water?

No. That comparison came from a 2023 study estimating 10 to 50 mL of water per prompt for GPT-3. The measurement Google published in 2025 gives 0.26 mL per median Gemini text request, 40 to 200 times less.

How much electricity do data centers use worldwide?

Data centers used about 448 TWh in 2025 according to United Nations University, and are projected to reach 945 TWh in 2030, roughly the consumption of Japan. Gartner estimates 565 TWh for 2026.

Is AI an environmental burden?

AI is not a burden at the individual level: a single prompt weighs very little. It becomes one at the collective level, with data center electricity demand set to double by 2030 on a grid mix that is still partly fossil, and above all at the local level, where data centers strain water and power grids.

How can developers reduce the environmental impact of AI?

The main lever is sizing: route each task to the smallest model that can handle it, measure tokens per completed task, cap agent loops and use caching. Choosing a cloud region with low-carbon electricity and low water stress also changes the footprint.

Originally published on angelo-lima.fr.

Kaizen: a complete SDLC for Claude Code, from requirement to production

Angélo Lima — Thu, 15 Oct 2026 14:33:41 +0000

A coding agent speeds everything up, mistakes included. Kaizen gives Claude Code a whole development lifecycle, with its critical rules enforced by code.

A coding agent writes fast. It also sometimes forgets the tests, or pushes a branch nobody reviewed. The DORA 2025 report measured it: AI raises team throughput, and instability along with it, except in teams that keep clear principles, small batches and real feedback.

Kaizen is the plugin I wrote to tool those disciplines in Claude Code, across the whole SDLC, from the requirement to production. It also answers the question I left open in April in my map of SDD, Compound Engineering and BMAD: can you combine the rigor of a spec with a learning loop?

In brief

What: Kaizen is an open source (MIT) Claude Code plugin covering the whole development lifecycle: requirements, plan, code, review, PR, deployment, monitoring, postmortem.

Key numbers: 23 skills, 21 read-only agents, 6 hooks, a Node.js CLI with no npm dependency. Version 3.2.1, October 7, 2026.

What sets it apart: the critical rules are hooks. Claude cannot finish on red tests, push without a real review, or deploy to production without a code you type.

Where it comes from: the loop of Every's Compound Engineering, the constitution from Spec Kit, practices from DORA and the NIST SSDF.

Who it's for: teams on Claude Code that want quality guarantees all the way to production.

The SDLC, phase by phase

Each classic phase of the cycle has its command. The last column says whether a check in code enforces it.

Phase	Command `/kaizen:…`	Enforced by code
Principles	`constitution`: 5 to 9 rules, each with a check	partly
Requirements	`brainstorm`: requirements R1…, acceptance examples AE1…	partly
Design	`plan` (STRIDE threats, rollback, PR-sized slices), then `doc-review`	partly: `plan check` verifies every requirement is covered
Code	`work` (test first), `debug`	yes: no end of turn on red tests
Verification	`review`, reviewers picked from the diff	yes: push refused without a real review
Delivery	`ship`, `watch-pr`, `release`	yes: PR size and SemVer checked
Deployment	`deploy` with your commands, rollback	yes: approval code for production
Operations	`monitor`: plan thresholds, dated incidents	partly
Improvement	`learn`, `postmortem`, `metrics` (DORA)	partly

Lost along the way? /kaizen:help looks at where the repository stands and gives the next command.

The critical rules are hooks

Writing "run the tests before finishing" in CLAUDE.md works nine times out of ten. The tenth time the session is long, the context compacted, and Claude reports that all is well over a red suite. So Kaizen puts those rules in hooks, which Claude Code runs on every tool call.

Before a commit, a scan refuses about thirty kinds of keys and tokens.
Before a push, the branch is refused until a review has been recorded, with proof that the reviewer agents really ran.
At the end of a turn, tests, lint and type checks must pass.
For production, only a code you type unlocks the deployment.

A loop that learns

This is what Compound Engineering brings. What a cycle learns (learnings, ADRs, postmortems) is written in the repository, and an agent reads it back before every plan, review or debugging session. Deployments, rollbacks and incidents become dated git tags, so the DORA metrics are computed from real events. /kaizen:metrics also separates learnings that were read from those applied in a commit. A learning nobody reuses signals a loop that isn't turning.

Ceremony is set by profile: lean for a prototype, standard for a product in production, full for a regulated domain. The checks in code stay on in all three.

Try it

/plugin marketplace add Lingelo/dojo
/plugin install kaizen@dojo

Kaizen is built for Claude Code and relies on its hooks. You need Node.js 18 or later, git, and gh for PRs. In your repository, run /kaizen:setup audit: it scores the project's SDLC maturity in five areas and offers to add what's missing. Code and docs are on GitHub. For how plugins work, see my article on Claude Code marketplaces.

Frequently asked questions

What is Kaizen for Claude Code?

Kaizen is an open source (MIT) plugin that gives Claude Code a complete SDLC: requirements, plan, test-first code, multi-agent review, pull request, watched deployment, incidents and learnings. It ships 23 skills, 21 read-only agents and a zero-dependency Node.js CLI. Version 3.2.1 was released on October 7, 2026.

What is an AI SDLC?

An SDLC (Software Development Life Cycle) is the set of phases that take software from a requirement to production: framing, design, code, verification, delivery, deployment, operations and improvement. An AI SDLC tools those phases for a coding agent, with checks suited to a fast executor that can forget an instruction.

How is Kaizen different from Compound Engineering?

Kaizen is derived from Every's Compound Engineering plugin (MIT) and keeps its learning loop. It adds checks enforced by hooks, Spec Kit's constitution, deployment, monitoring and DORA metrics. Kaizen is built for Claude Code and relies on its hooks.

How do I install Kaizen?

In Claude Code, add the marketplace with /plugin marketplace add Lingelo/dojo, then install the plugin with /plugin install kaizen@dojo. Kaizen needs Node.js 18 or later and git, plus gh for pull requests. In a repository, start with /kaizen:setup.

Can Kaizen deploy to production on its own?

No. Kaizen only deploys with the commands the team declared, and for a protected environment the user must type an approval code, valid for 30 minutes. Autopilot mode stops at a ready pull request and never merges or deploys.

Originally published on angelo-lima.fr.

Claude Code Cheat Sheet, October 2026: the complete state of play

Angélo Lima — Thu, 15 Oct 2026 14:33:34 +0000

All of Claude Code v2.1.296 on one page: 120 commands, 33 hooks, 243 settings, 391 environment variables

My fourth Claude Code cheat sheet in seven months, and the first one I didn't feel like calling an "update". Between June's v2.1.170 and October 9's v2.1.296, Anthropic shipped about 125 versions, including four new models and plugins that can redraw the interface. And the default permission mode changed its very nature. Adding badges to the June edition was no longer enough.

So this time I rebuilt the reference from scratch, from the official documentation downloaded page by page on October 13, and aimed for exhaustiveness in the strict sense: every command, every hook event, every flag, and in an appendix each of the 243 settings.json keys and 391 environment variables. The article that goes with it takes stock of what moved since June, and of what disappeared.

In brief

What: an exhaustive cheat sheet for Claude Code v2.1.296 (October 9, 2026), as interactive HTML, in English and French, checked against code.claude.com.

Key figures: ~120 built-in commands and skills, 33 hook events, 46 tools, 243 settings, 391 environment variables.

Models: Opus 5.5 is the default everywhere ($4 / $20 per MTok, medium effort), plus Sonnet 5.5, Haiku 5.5, and Fable 5.1 as an option for big jobs.

What changed in nature: auto mode became the default mode, subagents run in the background, and mods let you change Claude Code from the inside.

Why it matters: you now steer Claude Code by goals and delegate to background agents, instead of approving each command.

The cheat sheet

English: interactive HTML
Français : HTML interactif

Same palette as the previous ones (dark background, gold accent), with three badges: NEW for anything that wasn't in the June edition, CHANGED for anything whose behavior changed, REMOVED for anything that no longer exists. The page now renders properly on mobile, which the earlier editions didn't (they forced a fixed 1,400-pixel width).

What's covered

Section	Contents
What changed since June	Month-by-month timeline, June to October
Keyboard shortcuts	Essentials, navigation, readline editing, prefixes, transcript, agent view
Vim mode	Modes, navigation, editing, text objects
Models, effort and costs	The four 5.x models, aliases, effort levels, fast mode, advisor, fallbacks
Slash commands	Complete list in 9 categories, removed ones included
CLI	Subcommands (background sessions, plugins, purge, gateway…) and every flag
Permissions	6 modes, rule syntax, auto mode, sandbox
Hooks	All 33 events, the 5 handler types, common fields
Memory, skills, subagents	CLAUDE.md and AGENTS.md, full frontmatter, output styles
Plugins, mods and MCP	Plugin components, marketplaces, mods, MCP
Parallelism	Subagents, fork, agent view, agent teams, workflows, projects
Platforms	CLI, Desktop, web, self-hosted, mobile, IDEs, Chrome, Slack, CI/CD
Built-in tools	All 46 tools, deprecated ones included
Files and configuration	`.claude/` tree, precedence, key settings, status line, artifacts
Admin and enterprise	Model control, policies, versions, observability
Appendix	All 243 settings keys, 391 environment variables and 137 keybinding actions

State of play: where Claude Code stands in October 2026

Models: the 5.5 generation settles in

It was a busy summer. Sonnet 5 landed on July 2, Opus 5 on July 24, then the next generation: Fable 5.1 on September 1, Opus 5.5 on the 22nd, Sonnet 5.5 on the 28th, and Haiku 5.5 on October 7. In June I had to annotate the cheat sheet in a hurry after Fable 5 was suspended. The Fable family is back, and the fable alias now points to 5.1.

Model	ID	Price (input / output, per MTok)	Status
Fable 5.1	`claude-fable-5-1`	$10 / $50	Most capable, never the default
Opus 5.5	`claude-opus-5-5`	$4 / $20	Default on every plan and the API
Sonnet 5.5	`claude-sonnet-5-5`	$2 / $10	`sonnet` alias
Haiku 5.5	`claude-haiku-5-5`	$0.10 / $0.50	`haiku` alias

All of them have a native one-million-token context. Since v2.1.280, Opus is the default model on every plan, Pro and Team Standard included (they used to be on Sonnet). Default effort on the 5.5 models drops to medium, which the documentation recommends for well-scoped everyday work, and it is now saved per model. Finally, ultracode has become an independent toggle (/effort ultracode on) that plans a workflow for each substantive task, at any level.

On the safety side, recent models run with classifiers (cybersecurity, biology). A flagged request automatically switches to a fallback model depending on the category: Opus 4.8 for cyber, Opus 5 for bio. If you work on a security repository and see unexplained switches, switchModelsOnFlag makes Claude Code ask you first.

Auto mode is no longer optional

To me this is the most structural change of the period. In June, auto mode was a feature you turned on. On August 14 it became the default mode for new Pro, Max and Team sessions, and since v2.1.284 (September 28) it is the default for every interactive session on every plan and provider, unless permissions.defaultMode says otherwise.

The idea: a classifier evaluates each action instead of asking you to click. It now runs server-side by default, and its calls no longer count against your usage limits. It was hardened all summer: it blocks git reset --hard or git clean -fd when you didn't ask to throw work away, refuses terraform destroy without an explicit request, forbids access to cloud metadata endpoints, asks before the first read outside the working directory, and now names the rule behind a denial (for example [Data Exfiltration]). The /auto-mode-setup command drafts the autoMode.environment section that describes your trusted repositories and domains.

As a consequence, the old "default" mode is now called Manual, and bypassPermissions can no longer be turned on from a repository's settings. I covered the old model in the Permissions and security article. The rule syntax there still holds; what moved is the starting point.

Parallelism became the norm

In June, agent view had just arrived. Four months later, parallelism is everywhere, and the documentation now lists five distinct ways to get several agents working:

Subagents run in the background by default since July. They can nest three levels deep, twenty can run at once, and their permission requests surface in the main session. The frontmatter gains omitClaudeMd, autoCompactWindow and effort (see the subagents article for the basics).
Fork is on by default: a forked subagent inherits the whole conversation and the cache. /subtask starts one, and /fork now copies the entire session into a background session with its own worktree.
Agent view (claude agents, or ← on an empty prompt) gains search by name, the n: filter, classifier-written titles, and a link to the associated PR or GitLab MR.
Dynamic workflows orchestrate tens to hundreds of agents from a JavaScript script Claude writes. Saved in .claude/workflows/, they become commands.
Projects (Pro and Max beta) launch parallel cloud threads from a single conversation.

On top of that comes cross-session messaging (August): two Claude Code sessions on the same machine can write to each other through SendMessage, and @name in the prompt mentions another session.

Extending Claude Code: enter mods

Skills, subagents, hooks, MCP and plugins were already there. On October 1 (v2.1.287) a new layer arrived: mods. A mod is a plugin written in JavaScript or TypeScript that runs inside Claude Code. Where a hook launches an external script, a mod can draw a pane next to the transcript, add a band above the prompt, create a command that runs without a Claude turn, hold a tool call while it asks a question, or send a request to another model. Anthropic uses the mechanism for its own features too: the /diff panel is a mod.

The trade-off is spelled out in the docs: a mod runs with your permissions, reads your secrets, sees every prompt and can approve a tool call on your behalf. I would only install them from a marketplace I control.

Hooks keep growing as well: we're up to 33 events (from 27 in June), including DirectoryAdded, PreModelSwitch and PostModelSwitch. The new onFailure: "block" field (v2.1.295) closes a real gap for anyone relying on hooks as a safeguard: a security hook that crashes or times out now blocks the action instead of letting it through.

Other notable ecosystem additions: claude plugin eval to test a plugin against a run without it, /skill-doctor to spot skills that cost context without being used, syncing of the skills and plugins enabled on claude.ai, and AGENTS.md support when a project has no CLAUDE.md. /import codex, /import gemini and /import cursor bring over another agent's configuration.

Beyond the terminal

Claude Code lives less and less in the terminal alone:

Desktop comes to Linux in beta (Ubuntu 22.04+, Debian 12+), with a built-in browser, an iOS Simulator, background computer use on macOS, pop-out panes and automatic continuation after a usage limit. /resume there picks up sessions started from the CLI.
Artifacts publish interactive pages to claude.ai from the session, and can call your MCP connectors on every view.
Self-hosted environments run cloud sessions on the company's own infrastructure (Team and Enterprise beta).
Remote Control is out of preview, and the mobile app shows your machines as cards you can start a session on.
Claude in Chrome has been generally available since July.

Review and security

Four tools now complement each other. /code-review hunts bugs in a background agent, at five effort levels, and can comment on the PR or apply fixes. /simplify handles cleanup. /ultrareview sends a fleet of agents into the cloud. On the security side, the security-guidance plugin reviews each edit, and the Claude Security plugin (July) runs a full multi-agent scan with a threat model, then turns the findings you pick into patches to review. Finally, /verify and /run launch the application to see that a change actually works, beyond the tests.

On the enterprise side

Administrators got a lot of levers: deniedModels and availableModelsMatch: "exact" to block a model until it's approved, maxEffortLevel, allowedProviders, modelPricing to show costs at negotiated rates, managedMcpServers to hand out MCP servers, and the self-hosted Claude apps gateway (SSO, policies, spend limits) in front of Bedrock, Vertex or Foundry. A repository's settings can no longer turn on telemetry, Remote Control or Claude in Chrome: those now belong to the user or the admin.

What disappeared

Ultraplan (the /ultraplan command and keyword): removed in August.
/vim and /pr-comments: removed. Vim mode is set in /config.
The TodoWrite and Task* tools are no longer provided to recent models (CLAUDE_CODE_ENABLE_TODO_TOOLS=1 brings them back), and TaskOutput is gone.
Glob and Grep are absent by default on macOS, Linux and WSL: Claude uses find and grep, which actually run embedded versions of bfs and ugrep.
/agents no longer opens a wizard: ask Claude to create the agent, or edit .claude/agents/.

My takeaway

Back in December, in my 20-article series, Claude Code was a terminal assistant you watched command by command. In October, the tool is designed for you to hand it a goal (/goal), let it break the goal down, delegate to background agents, and let a classifier act as the guardrail. The user's job shifts toward defining the frame: rules, hooks, CLAUDE.md, spend limits. That is exactly the idea behind Kaizen, the Claude Code SDLC I presented last week: when the agent speeds everything up, critical rules have to be enforced by code.

The flip side is surface area. 243 settings and 391 environment variables is a lot, and part of this cheat sheet exists so you can find the right lever without rereading 220 documentation pages. /doctor and /skill-doctor go in the right direction by helping you remove what no longer serves.

Official sources: Changelog, What's new, Commands, CLI reference, Hooks reference, Model configuration, Mods overview, All settings, Environment variables.

Previous editions are still available: June EN · FR, April EN · FR, March EN · FR.

If you spot a mistake or something missing, let me know and I'll fix the cheat sheet.

Frequently asked questions

What is the latest version of Claude Code in October 2026?

As of October 13, 2026, the latest Claude Code version is v2.1.296, released on October 9, 2026. About 125 versions shipped between June 9 (v2.1.170) and October 9. Run claude --version to see the installed version and claude update to upgrade.

Which model does Claude Code use by default in October 2026?

Since v2.1.280 (September 22, 2026), Claude Code uses Claude Opus 5.5 by default on the Pro, Max, Team and Enterprise plans and on the Anthropic API, at medium effort. Fable 5.1, the most capable model, is never the default: select it with /model fable.

What is Claude Code's auto mode?

Auto mode is a Claude Code permission mode in which a classifier judges each action instead of asking the user to confirm it. By default it blocks destructive actions such as git reset --hard or terraform destroy. Since v2.1.284 it is the starting mode for every interactive session that isn't configured otherwise.

What is a mod in Claude Code?

A mod is a Claude Code plugin written in JavaScript or TypeScript that runs inside the tool, introduced on October 1, 2026 (v2.1.287). It can draw panes, add commands that run without a Claude turn, intercept tool calls or call a model. It runs with the user's permissions, so it should only be installed from a trusted source.

How many commands and settings does Claude Code have?

In October 2026, Claude Code documents about 120 built-in slash commands and skills, 33 hook events, 46 built-in tools, 243 settings.json keys and 391 environment variables. Angelo Lima's cheat sheet lists all of them, with an expandable appendix for settings and variables.

Originally published on angelo-lima.fr.