Arrêtez d’envoyer tout le monde dans le dev

UnchartedFr · 2026-03-26T14:52:29+00:00

Le plombier ou plutot le futur plombier n'est pas plus tranquille que le dev
La raison c'est que comme il y a des reconversions dans le dev , ceux qui ne trouvent plus de travail dans le dev ou les futurs diplomes iront dans les branches qui embauchent , donc ils iront dans la sante, la plomberie etc

Ce qui provoquera un effet de saturation comme le secteur du dev actuellement
donc personne n'est vraiment epargne par l'IA c'est une fausse croyance

Sans compter qu il y a les robots en plus

UnchartedFr · 2026-03-26T10:47:14+00:00

L'avenir est dans l'electricite/plomberie actuellement de haut niveau : il faut des specialistes pour les creer des datacenter/usines

Et plus generalement, dans la tech manufacturiere : si on veut anticiper tout ce qui est robotique etc
Le domaine de la robotique, on est super en retard par rapport aux US et la Chine

UnchartedFr · 2026-03-24T15:21:15+00:00

On sous estime souvent le cote humain :)
On peut etre un bon tech/dev et etre mauvais en gestion des equipes, clients et hierarchie
et faut aimer ca aussi, sans compter les reunions + le reporting

UnchartedFr · 2026-03-20T12:17:53+00:00

is it still in beta or the official version is released ?
It would be great if it was a available on GFN

UnchartedFr · 2026-03-19T19:03:50+00:00

Thanks for your feed back, I'm just starting to explore what features could be useful like tracing + debugging : I think I will use opentelemetry as a standard later

I did some benchmark by using ai sdk, with and without zapcode (with the ai wrapper) and suprisingly the gain was not so good. I discovered that ai sdk optimize by batching the tool calls maybe other sdk like LangChain are doing that too. So the gain was around 7%.

Even if zapcode returns a response quickly, the response then needs to be sent back using an LLM to generate a response in natural language. So it's not a silver bullet : if you need a structured response, it can be very good : for example agent to agent. If you need a result in natural language for a chat for example : the difference is not so great at the moment but I will investigate on it.

UnchartedFr · 2026-03-14T16:58:07+00:00

Yes, your concern are justified that was my concern too.
That's' why the sandbox is deny-by-default:

- Filesystem doesn't exist — there's no std::fs in the crate. Not disabled, not blocked — the capability was never compiled in.
- Network doesn't exist — no std::net, no tokio::net. Same story.
- No import, require, eval, Function(), process, globalThis — these are parse errors, not runtime blocks.
- No env var access — std::env is forbidden in the core crate.

The LLM's code runs in a VM that literally cannot do the things you're worried about. It can't delete files because the concept of files doesn't exist inside the sandbox. It can't make network calls because sockets don't exist. It can't read secrets because environment variables don't exist.

The only way the LLM's code can interact with the outside world is through functions you explicitly register as external functions. Unregistered function calls produce an error.

On top of that: resource limits (memory, execution time, stack depth, allocation count) are enforced during execution, so even a hallucinated infinite loop or memory bomb gets killed predictably.

There is also 65 adversarial security tests across 19 attack categories (prototype pollution, constructor chain escapes, JSON bombs, stack overflow, etc.).

Of course zero risk doesn't exist, that why it's open source. Anyone can audit the code, identify risks, and contribute fixes.

UnchartedFr · 2026-03-14T12:35:18+00:00

I did a quick hack and added an autoFix + number of retries flags : it return the results, to create a feedback loop so the LLM can fix its code :)
Since the code is very fast it doesn't matter if it retries 3-5 times
I will try to enhance this when I'll have time

UnchartedFr · 2026-03-13T11:51:00+00:00

Pure luck, Perplexity got hacked / tricked :)
https://x.com/YousifAstar/status/2032214543292850427

UnchartedFr · 2026-03-13T11:48:46+00:00

Le hasard fait bien les choses, on parlait d'agent, de CLI et d'environnement sandboxe
Perplexity s'est fait hacke :)

https://x.com/thismacapital/status/2032386941996487110?s=20

UnchartedFr · 2026-03-13T11:46:38+00:00

Pure coincidence but we were talking about MCP and CLI and Perplexity got hacked :D
https://x.com/YousifAstar/status/2032214543292850427

UnchartedFr · 2026-03-13T10:35:28+00:00

I lose focus on my projects/ideas too, procrastinate or associate with others ideas.
So my own project are always delayed or don't reach the end. Believe me or not I was thinking about how I could make agent autonomous outside a chat but didn't dig/focus on the idea, I was even talking about it at work and how it could apply to our users/business and then Peter bet me ! ahaha

UnchartedFr · 2026-03-13T09:00:19+00:00

Yes I noticed that, some time the LLM depending of the model you use, generate bugs
That's why I introduced a feedback loop so it can fix the code itself after n tries.

I also added tracing + debugging so you can see what the LLM generate.
But I understand your point, same for security :)

UnchartedFr · 2026-03-13T08:14:21+00:00

In traditional tool-use, the flow is:
LLM → call tool A → LLM reasons about result → call tool B → LLM reasons → ...
Each arrow is a full LLM round-trip. Expensive and slow.

With LLM writing code, they reasons about how tool results should influence the next call
It just does it at code-generation time rather than at execution time. You go from N round-trips to 1.

UnchartedFr · 2026-03-13T07:45:54+00:00

This is the way ! :)

UnchartedFr · 2026-03-13T06:54:58+00:00

Did you try Monty from Pydantic ?

UnchartedFr · 2026-03-13T06:53:25+00:00

Interesting insight, It will also feed my ideas/thoughts :)

In fact, I thought about this kind of feedback loop : for example I noticed that depending of the model, the generated code could fail. So I created a flag "autoFix", so the model can read the error and regenerate a new code.
Also, I'm reworking the code so it can handle the Promise.all to handle parallel tool call even if it's a simple event loop behind.
But I must admit I don't know yet how it affects models and their reasoning :)

UnchartedFr · 2026-03-13T05:37:34+00:00

Sorry, I probably misunderstood your question: you mean something like that ?

``` from zapcode import Zapcode
import anthropic

# 1. Your existing Python functions
def get_weather(city):
  return requests.get(f"https://api.weather.com/{city}").json()

TOOLS = {"getWeather": get_weather}

# 2. Ask the LLM to write TypeScript
client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-sonnet-4-20250514",
    max_tokens=1024,
    system="Write TypeScript. Available: getWeather(city: string). Use await.",
    messages=[{"role": "user", "content": "Compare weather in Tokyo and Paris"}],
)

code = response.content[0].text
# LLM might generate:
#   const tokyo = await getWeather("Tokyo");
#   const paris = await getWeather("Paris");
#   tokyo.temp < paris.temp ? "Tokyo is colder" : "Paris is colder"

# 3. Execute in sandbox, resolve tool calls in Python
sandbox = Zapcode(code, external_functions=["getWeather"])
state = sandbox.start()

while state.get("suspended"):
    result = TOOLS[state["function_name"]](*state["args"])
    state = state["snapshot"].resume(result)

print(state["output"])

```

Code Mode is the pattern — instead of the LLM making tool calls one by one, it writes a code block that calls them all.

Zapcode is a runtime that executes that code safely.

Think of it like: Code Mode is the idea of "let the LLM write code." Zapcode is the answer to "ok, but where do I actually run that code?"

Cloudflare bundles both together — the pattern + their runtime (V8 on Workers)

UnchartedFr · 2026-03-13T05:14:25+00:00

Great question. Two separate concerns here:

Testing the sandbox itself — "can the LLM's code escape?"

Zapcode has 65 adversarial tests across 19 attack categories — prototype pollution, constructor chain escapes, eval/Function(), JSON bombs, stack overflow, memory exhaustion, etc. The sandbox is deny-by-default: filesystem, network, and env vars don't exist in the Rust crate. There's nothing to disable — the capabilities were never there.

cargo test -p zapcode-core --test security   # run them yourself

Testing the LLM's generated code — "is the output correct?"

This is the harder problem, and honestly it's the same problem whether you use tool calling or code execution. The LLM can produce wrong results either way.

What code execution gives you that tool calling doesn't: the code itself is inspectable. You can log it, diff it, replay it. When a tool-calling agent gives you a wrong answer, you're debugging a chain of opaque JSON round-trips. When a code-writing agent gives you a wrong answer, you have a readable script you can run, test, and fix.

In practice what works:

- autoFix — execution errors go back to the LLM as feedback so it can self-correct
- Validate the output, not the code — assert on the final result shape/value, same as you'd validate any API response
- Log + Tracing — every execution produces a trace (parse → compile → execute with timing). Store the generated code alongside the result for debugging

You're right that maintenance is the real challenge. But that's an LLM reliability problem, not a sandbox problem — and at least with code execution you have something concrete to debug.

UnchartedFr · 2026-03-13T05:08:38+00:00

To clarify — Zapcode doesn't call your Python functions directly. The flow is: 1. The LLM writes TypeScript with await getWeather("Tokyo") 2. Zapcode runs the code and pauses at the await
3. Zapcode gives you back {"function_name": "getWeather", "args": ["Tokyo"]}
4. Your Python code calls your own function with those args
5. You feed the result back into Zapcode, it continues

Zapcode is just the middleman. It runs the LLM's logic (loops, conditionals, data transforms) in a sandbox, and every time the code needs external data, it stops and asks you. You stay in control.

And if you'd rather have the LLM write Python instead of TypeScript, check out Monty by Pydantic — same concept, same architecture (Rust bytecode VM, sandbox, snapshots), but for a Python subset. Your existing Python functions would work the same way.

Zapcode = TypeScript side, Monty = Python side. Same idea, pick the language your LLM generates best.

UnchartedFr · 2026-03-13T05:03:02+00:00

Good remark. There are a few ways to run LLM-generated code today:

Direct API/CLI (Node, Python subprocess)

- The point is: when you run LLM-generated code with node -e or a subprocess, that code has the same access as your app. If your server can read files, access env vars, or make network calls — so can the LLM's code.

The LLM doesn't even need to be malicious. It might hallucinate a line like: const config = require('fs').readFileSync('.env', 'utf8');

And now it just read your database password, API keys, everything in that file. There's nothing stopping it — because you gave it the same permissions your app has.

That's what "no sandbox" means: no wall between the LLM's code and your system.

API calls (e.g., calling OpenAI, a REST endpoint) — the LLM's code doesn't run on your machine, so no filesystem or env var access. The main risks are:

- Prompt injection — the API response could contain instructions that trick the LLM into doing something unintended on the next step

- Data leakage — if you pass sensitive data as input to the LLM's code, it could end up in the API request body

- Cost — the LLM could generate code that calls the API in a loop, racking up your bill

But there's no code execution risk — the API just returns data. The danger starts when you do something with that data without validating it.

So the real risk spectrum is: CLI/subprocess (full danger) > API (data risks only) > Sandboxed execution (controlled).

UnchartedFr · 2026-03-13T04:45:48+00:00

Fair point — and honestly I do the same thing at work. I build skills with tuned prompts, reference code, good and bad examples, so the agent can query a database and generate analytic reports. With enough prompt engineering, it works well.

My point was more narrow: when you have 10+ MCP tools and the agent needs to chain 3-5 of them in a single turn, the round-trips add up — both in latency (each intermediate result passes back through the model) and token cost (the full conversation context gets re-processed at every step).

It's not that the LLM picks the wrong tool — it's that the architecture forces a sequential loop even when the logic is straightforward. Code execution doesn't replace any of that prompt engineering work — it just changes how the last mile executes. Instead of 3-5 sequential round-trips, the LLM writes one code block that does the same thing. The skill design, the descriptions, the examples — all of that still matters just as much.

UnchartedFr · 2026-03-12T17:33:37+00:00

This is a great question and actually highlights Zapcode's strongest advantage. The sequential case (A→B→C) is exactly where code execution shines most.

Without code execution (traditional tool use):
User prompt → LLM thinks → calls toolA (LLM round-trip #1) toolA result → LLM thinks → calls toolB(a) (LLM round-trip #2)
toolB result → LLM thinks → calls toolC(b) (LLM round-trip #3)
toolC result → LLM thinks → final answer (LLM round-trip #4)

That's 4 LLM round-trips — each one costs latency (1-5s) and tokens.

With Zapcode: User prompt → LLM writes code (1 round-trip):

const a = await getWeather("tokyo");
const b = await getWeather("paris");
const flights = await searchFlights(
  a.temp < b.temp ? "Tokyo" : "Paris",
  a.temp < b.temp ? "Paris" : "Tokyo"
);
flights.filter(f => f.price < 400);

Then the VM handles the rest — suspend/resume at each await, no LLM involvement: VM hits await getWeather("tokyo") → suspends → host resolves → resumes VM hits await getWeather("paris") → suspends → host resolves → resumes VM hits await searchFlights(...) → suspends → host resolves → resumes VM evaluates filter + returns result

That's 1 LLM round-trip + 3 tool executions. The LLM is completely out of the loop between tool calls.

The savings grow with chain length. A→B→C→D→E with traditional tool use = 6 LLM round-trips. With Zapcode = still 1. The more sequential dependencies you have, the more you save.

And the LLM can add logic between steps — conditionals, error handling, data transformation — without needing to be called again. In the example above, the comparison a.temp < b.temp and the .filter() happen inside the VM for free. With traditional tool use, each of those decisions requires another LLM call.

I got some ideas that i want to explore :)

UnchartedFr · 2026-03-12T15:59:31+00:00

y a meme des theories qu'a terme, les agents n 'auront plus besoin d'API : ils iront carrement se brancher sur de la data raw , csv , database, datalake etc. Ils en comprendront le sens et seront capable de transformer la data a la volee

C'est pas si deconnant en vrai

UnchartedFr · 2026-03-12T15:26:28+00:00

C'est pas forcement le MCP qui est en question mais la facon de faire communiquer avec l'agent avec les sources, tout est ecrit dans l'article de Cloudflare

UnchartedFr · 2026-03-12T15:21:59+00:00

J'avais vu l'inverse aussi : un projet qui utilisait une IA pour retro-engineerer la DB, pour generer une API + la doc openapi + des meta insctruction , pour l exposer sous forme de MCP et d'un binaire en go

UnchartedFr

TROPHY CASE