Daniel Saadia

Introducing : the Radius Principle. 3 skills to expect your changes and review your PRs with confidence . It was a thought in my articles, now it is a practice you can adopt. Review the change before it exists. Just 3 skills to install. radiusprinciple.com

Real question, how do you concretely manage and develop your software factories on your projects ? (If you have any)

I think composability + isolation of critical parts is a path to auto-mergeability. My next project is all about this concept I am experimenting with: the critical bricks (secrets, payments, key rules) only merge after a human review. Everything that merely composes those validated bricks can auto-merge. A new rule means a new validated brick, so the PR waits for me. The rest can go through on its own.

The let's connect of the week. I passed 500 last time, let's go higher I am Daniel, Lead TypeScript Engineer from Paris. Future dad in 2-3 weeks, building side projects every day next to my freelance work If you are building anything tech-related, let's connect !

Hi all, apparently, doing multiple let's connect can work. So if you are a developer tinkering with agentic workflows, an entrepreneur, designer, or builder in any kind, let's connect ! (If you are a builder-parent let's connect too, future builder dad here)

And what if... you take an open model, work with it on your tasks, and when doing your feedback skill that update the memory of your repo (like a @mattpocockuk /retro or my /update-memory), you also ask the model to update its own weights to better match your needs. We maybe have something interesting here no ?

Naming things well is one of the most important things in software engineering. And with coding agents, I think we are missing a good name to distinguish two very different kinds of instructions we give them. What I propose : rules vs practices. - Rules are constraints you can describe deterministically. Types, lint, import boundaries between modules, the scope an agent is allowed to touch, a fresh context per ticket. They belong to the harness and to your code verifications, because no prompt can guarantee them, by essence. - Practices are what you cannot describe deterministically. How to name things, when to split a function, what clean looks like in this codebase. They live in the prompt, the skills, the agent memory. The game is to move everything you can from practices to rules. What stays in the prompt is what you accept to be followed most of the time, not every time

A study of almost 18,000 real coding-agent sessions found the agent asks a clarifying question in about 3% of its turns. @ShlomoFaig wrote it up, and that number stuck with me. So here is my workflow using grilling @mattpocockuk's way and radiusprinciple.com Before any code, I grill the agent until the task is clear. Then I lock the result into an expect.yml: the files and symbols it plans to touch, one line on why, and a rough size. Reviewing that file is a kind of pre-review. You see what the agent really understood of your task before it writes a single line. A file you didn't expect, or a size way too big for the change you had in mind, usually means something in your description wasn't clear, or something in its plan was off. You adjust it there, when it costs nothing. I only validate the expect once everything is ok with me, then let the agent implement. It stays in the agent's context while it implements, so it keeps steering. Then the PR review is mostly checking the drift against what was produced. By doing this, you displace a big chunk of the cost of reviewing from a multi-files PR to a single file expect.yml.

Don't ask your agent to stay in scope. Make it hard for it to leave. Restrict it deterministically, like limiting the files it's allowed to modify. You shrink the space of possible outputs to one you know contains what you want, and in return you increase the probability to get something that fits. Limit what your agent can reach, and you'll reach what you wanted.

Bend is awesome, thanks @mattpocockuk for sharing it to your audience !

A small reintroduction could be nice. I’m Daniel, from Paris. Technical Lead on Typescript projects during the day and still doing Typescript on my personal projects during the evening and early in the morning. I write some articles and posts about my way of making open source software and my agentic coding workflow. I learn a lot from my followers too, so let’s connect !

Is anybody doing static verification of AI generated code (a constrained js subset) to be sure it is safe at runtime ? Like you allow only some symbols, mandatory purity, and all dependencies are from function arguments, no globals. I think there is an interesting topic here.

Lumpcode dashboard is so nice, you see what is running, what context, and if you need to be sure the agent runs well, transcripts are there.