DEV Community: Yves Jutard

🤖 What is a ReAct-style agent?

Yves Jutard — Tue, 09 Jun 2026 06:04:00 +0000

TL;DR: "ReAct" is the way all models do their internal "reasoning+acting" loop since 2023. prompt => {loop = evaluate <-> tool call(s)} => final answer It used to be dumber, before a paper from Google.

Disclaimer: this article is a reviewed, lightly edited and enriched conversation with Claude Opus 4.8.
I was learning the subject and found the answer worth sharing.
I'm not taking any credit: It helped me, hopefully it'll help you.

A ReAct-style agent is an LLM agent that interleaves reasoning and acting in a loop. The name comes from "Reasoning + Acting." It was introduced in a October 2022 paper by Google Research's Brain Team, and it became one of the foundational patterns for building tool-using agents.

The paper

ReAct: Synergizing Reasoning and Acting in Language Models by Yao et al. (2022).

arXiv abstract page: https://arxiv.org/abs/2210.03629
- PDF: https://arxiv.org/pdf/2210.03629
mini-site https://react-lm.github.io/
Readable write-up from the authors on the Google Research blog (lighter version): https://research.google/blog/react-synergizing-reasoning-and-acting-in-language-models/

In details

The core idea is that instead of having the model either just think (chain-of-thought) or just call tools blindly, you let it alternate between the two in a structured cycle:

Thought → the model reasons about the current state and what to do next
Action → the model issues a tool call (search, API request, code execution, etc.)
Observation → the result of that action gets fed back in
…and then it loops back to Thought, using the new observation to inform its next step, until it decides it has enough to produce a final answer.

A toy trace looks like this:

Question: What's the population of the capital of France?

Thought: I need to find the capital of France first.
Action: search("capital of France")
Observation: Paris is the capital of France.

Thought: Now I need Paris's population.
Action: search("population of Paris")
Observation: Approximately 2.1 million.

Thought: I have what I need.
Answer: The population of Paris is about 2.1 million.

Why it works well: The reasoning steps keep the model grounded—it plans before acting and adapts when an observation contradicts its expectation. The action steps keep it factual, since it pulls real data from tools rather than hallucinating. The interleaving is the key: reasoning informs which action to take, and observations correct the reasoning. Pure chain-of-thought can reason its way confidently into a wrong answer; pure action-taking can't plan or recover from surprises.

In practice today, the "Thought/Action/Observation" text format from the original paper has largely been absorbed into native tool-calling APIs (function calling), where the model emits structured tool calls and the runtime feeds back results. But the underlying loop is still ReAct — it's the conceptual backbone behind frameworks like LangChain agents, LlamaIndex agents, and most custom agent loops you'd build yourself.

The trade-offs: ReAct loops can be token-hungry and occasionally get stuck in repetitive cycles (re-issuing similar actions), which is why people layer on things like step limits, reflection (e.g., Reflexion), or more structured planning (Plan-and-Execute) on top.

ReAct's core contribution is best understood as a fix for the failure mode of pure chain-of-thought (CoT): When a model reasons via CoT, it isn't grounded in the external world and works only from its own internal representations, which limits its ability to reactively explore, reason, and update what it knows.

The consequence is the familiar pathology: a model reasons fluently and confidently down a chain that's built on a wrong or stale premise, and because nothing external ever contradicts it, the error compounds at every subsequent step. That's the "hallucination and error propagation" problem.

ReAct breaks that closed loop by letting actions interrupt the reasoning. On HotpotQA and Fever, ReAct overcomes the hallucination and error-propagation issues prevalent in chain-of-thought by interacting with a simple Wikipedia API, and it produces human-like task-solving trajectories that are more interpretable than baselines lacking reasoning traces.

The key word is synergy—it's bidirectional. Reasoning traces help the model induce, track, and update action plans and handle exceptions, while actions let it interface with external sources to gather additional information. So reasoning decides what to look up, the lookup injects a real fact, and that fact constrains the next round of reasoning—the model can't drift far from reality because it keeps getting pulled back to ground truth.

Two things from the paper are worth underlining for how you think about agent design:

✅ The gains weren't marginal on the interactive tasks. On ALFWorld and WebShop (two interactive decision-making benchmarks) ReAct outperformed imitation and reinforcement-learning methods by absolute success-rate margins of 34% and 10% respectively, while being prompted with only one or two in-context examples. That few-shot efficiency was a big part of why the pattern caught on: you got RL-beating behavior from a couple of prompt examples, no training loop required.
⚠️ ReAct alone wasn't strictly dominant on the QA tasks the real winner was the hybrid. On HotpotQA and Fever, the best overall approach was a combination of ReAct and CoT that lets the model use both its internal knowledge and externally obtained information during reasoning.

The takeaway: grounding via tools and reasoning from internal knowledge aren't competitors; the strongest setup lets the model lean on its own priors when they're reliable and reach for external sources when they aren't. That tension—when to trust the model's internal knowledge versus when to force a retrieval—is exactly the design knob you're tuning in RAG and agentic pipelines.

The interpretability point is also more than a footnote. Because every step is an explicit thought or a named action with an observation, the trajectory is human-readable, which makes the system far easier to diagnose and steer when it goes wrong—a meaningful operational advantage over an opaque policy that just emits actions.

⚽️ Claude Code Isn’t the Only Game in Town

Yves Jutard — Wed, 13 May 2026 23:35:26 +0000

Claude Code is great, but alternatives exist with unique strengths. I tried a few.

TL;DR: the "coding agents" space is extremely dynamic with fierce competition. We can expect a lot of changes in the coming months, from form factor to mental models. Competition is good! Trying other coding agents may help you:

stay open-minded about the UX / form factor
increase your performance by using their unique strengths
save credits: they have free tiers 💰

Here is a short list, in order of personal preference/relevance:

⭐️⭐️⭐️ Codex by OpenAI

"The same agent everywhere you build"

✅ generous free tier
✅ frontier models
✅ built-in worktrees and cloud environments
💡 not a CLI! Codex is primarily an app (though they do have a TUI version)
💡 integrated browser that the agent can access, with annotation tool

Overall the strongest contender. Integrated browser is extremely useful (all coding agents can access the browser, but some setup is required). Integrated agent orchestration + all-in-one app makes a great UX.

openai.com

⭐️⭐️ openCode

"The open source AI coding agent"

✅ free tier (not frontier models) + low-cost plans
✅ Can connect to any model = you can use frontier ones
✅ Open Source (extensible / tweakable)
✅ Enterprise plan with confidentiality promises
✅ has an app like Codex
💡 killer feature seems to be the plans and open-source nature

opencode.ai

⭐️ Gemini CLI by Google

"Build debug & deploy with AI"

✅ generous free tier
✅ frontier models
✅ must be decent and reliable since it's Google
✅ procurement may be easier since it's Google
normal TUI coding agent, I didn't notice any original feature (typical Google?)

Note to Google: make your landing page scrollable and immediately list your USPs

Build, debug & deploy with AI | Gemini CLI

geminicli.com

Vibe by Mistral AI

"Agentic coding that meets you where you work. Write, test, and deploy autonomously with full codebase context."

✅ free tier
✅ European company
✅ decent
💡 killer feature seems to be sovereignty since it's a rare non-USA one.
still has room to grow: I encountered a backend error during first use

Mistral Vibe (formerly Le Chat) - AI chat and coding agent

Vibe (formerly Le Chat) is Mistral's AI chat and agent for work and code. Chat, think, search, write, code, and automate your most meaningful work.

mistral.ai

Amp

"the frontier coding agent built for leading models, and what comes next"

recommended by an opinion leader (maybe Steve Yegge?), I wish I'd tried it, unfortunately Amp discontinued their free tier: https://ampcode.com/news/amp-free-is-ad-free

ampcode.com

Did I miss a notable one? Any notable Chinese coding agents worth trying? Feel free to share in the comments.

🌅 Brighten your day in 3 CLAUDE.md lines

Yves Jutard — Wed, 29 Apr 2026 04:15:37 +0000

This won't save your job, but it might get a few laughs during your workday:

Ask Claude to act like a pirate and call you 'Captain' 🏴‍☠️

Here are 3 lines to drop in your CLAUDE.md: (or AGENTS.md)

# Coding Agent Guidance

In all conversations, address me as "Captain Yvem".

You're a very experienced staff product engineer.
If you meet my expectations,
you'll get gold doubloons and rum.

On start, greet me. Also crack me a joke.

Here is the result:

Sometimes Claude asks for rewards on its own:

Hope this helps!

I’ll be sharing more coding agent tips soon: Feel free to follow along ⛵️🛟

HOWTO: run a local MCP server in TypeScript without a build step

Yves Jutard — Fri, 30 May 2025 02:42:10 +0000

I experimented with writing and running a local MCP server in TypeScript and I ran into difficulties having it properly called from Claude.

In this article, I'll share the working config and the issues I encountered.

Prerequisite: MCP server code

I copy/pasted the TypeScript example from Claude documentation.

Goal: Direct Local execution

Claude rightfully recommends using TypeScript and suggests a build step to convert .ts to .js. However node >23.6 now supports direct execution of TypeScript with type stripping, so the build step felt unnecessary ❌.

TL:DR; Here is the working config:

Final, working, Claude's local config.json:

{
  "mcpServers": {
    "hello-world": {
      "command": "/Users/sam/.nvm/nvm-exec",
      "env": {
        "NODE_VERSION": "23"
      },
      "args": [
        "node",
        "--disable-warning=ExperimentalWarning --experimental-strip-types",
        "/Users/sam/work/src/mcp/module/src/index.ts"
      ]
    }
  }
}

Issues encountered and solutions

Everything path must be absolute

Claude's config doesn't perform any path interpolation or env inheritance, so everything has to be explicitly declared and all paths have to be absolute. No ~ or $HOME or PATH preset:

"command": "/Users/sam/.nvm/nvm-exec"
"/Users/sam/work/src/mcp/module/src/index.ts"

Calling the right node

I'm using nvm to manage my node runtimes. Even after installing the latest node 23 with nvm install 23, calling node from Claude yielded another version. The solution is to use nvm-exec with an env variable NODE_VERSION=23, see the config above. Note that nvm-exec must be referenced with an absolute path.

Stdout pollution

Since node 23's --experimental-strip-types is considered experimental, there is a warning message displayed on invocation. Since the local MCP protocol relies on stdin/stdout, this warning message disrupted the protocol.

The solution is to silence this warning with --disable-warning=ExperimentalWarning

Conclusion

It works!

I hope you'll overcome those issues faster thanks to this post. Good luck experimenting with MCP! Comments and reactions are appreciated 😊

🖼️ Install those 6 browsers now… (Yes you need them all!)

Yves Jutard — Thu, 20 Mar 2025 05:25:37 +0000

I'm Frontend Software Engineer. I routinely use 2x browsers at once. Since last year, I further improved my productivity thanks to 2x extra browsers.

Disclaimer: 2 of them are macOs only.

1st: Main browser: Firefox

Firefox is not the greatest and fastest browser, but it has 2x killer features:

Vertical tabs: (webextension) THE killer feature. A collapsible tree of tabs is a huge productivity gain! Chrome absolutely rejects vertical tabs for no clear reasons.
Ad blocking: while Chrome is trying to kill ad blockers, Firefox promised they would keep them working. I use an advanced one called uMatrix but I heard good things about uBlock Origin.

2nd: Secondary browser: Chrome

The most supported browser, also the most "enterprise ready", the only one supporting all my company's internal tools.

Killer feature:

The standard: like it or not, all websites work on Chrome, especially business webapps.
Multi-profiles: allowing to seamlessly keep a separate personal profile on the side of a work one.

Be sure to tweak the security settings to block 3rd party cookies!

3rd: Dev browser: Chrome Dev

Using a dedicated Dev browser is a big gain! To properly debug websites (esp. perf issues), one needs:

no webextensions: daily-life webextensions such as password managers inject code into pages, add extra iframes etc. This is confusing when trying to debug a page, seeing extra logs & errors, extra classes on elements, confusing flamegraphs...
a cleanable browser: a dedicated dev browser allows you to safely "reset" your browser, clearing all cookies and site data without impacting all your work sessions on the main browser(s).
a defaulted browser: unlike your main browser which is likely "strenghtened" (strict Safe Browsing, 3p blocking…), you can keep the dev browser "defaulted" to experience it like most of your users do.

Chrome Dev is an excellent choice. It's evergreen and the most used browser anyway.

4th: "picker" browser: Velja

Velja by Sindre Sorhus is not a real browser but a browser picker. By setting it as the default system browser, it shows a picker upon click on a link from outside of a browser (ex. in your Terminal, Slack, Zoom…):

(Bonus) 5th: Mobile debugging browser Safari Technology Preview

Killer feature: mobile debugging. Safari Technology Preview can open dev tools on a connected iPhone, either a physical one or an emulated one. This is invaluable when fixing mobile issues.

I'm not doing much mobile debugging at the moment, but when needed, it's a must-have.

(Bonus) 6th: Responsive Development browser Polypane or Responsively

Killer feature: responsive development. Both browsers allow to simultaneously open several synchronised tabs with different viewport sizes.

Polypane is paid but feature-packed by very motivated devs

brew install --cask polypane

Responsively is free but has less features

brew install --cask responsively

I'm not doing much responsive dev at the moment, but when needed, it's a must-have.

That's it!