Posts | Ben Sadik

Software Factories and the Future of Consulting

Sun, 01 Nov 2026 00:00:00 GMT

The Astro team reported in a blog post that a pipeline of AI agents had cut the repo’s open GitHub issues from more than 200 to about 30. For each bug, the pipeline reproduces it in a sandbox, diagnoses the root cause, and ships a preview release that the original reporter can verify. Astro calls this pipeline a software factory, a concept that many software companies are now trying to build, and has open-sourced the pipeline.

The idea is that a production bug already moves through a loop with clear inputs and outputs. People copy context from alert to Slack to ticket to branch to PR. A software factory for bug fixes runs that loop as a system of agents.

This innovation matters most for consulting firms whose offering rests largely on their clients’ legacy systems. These firms do the complex work of reading and maintaining that code, triaging issues to separate bugs from features, and modernizing the systems without breaking anything.

But what happens when clients can do this work in-house, more easily and cheaply, without hiring expensive transcultural contractors? I expect most clients to bring the work in-house, and these firms to lose more clients every year as those clients learn to leverage AI.

These firms can shift their offering from “we have many cheap engineers who can read your legacy code and grind through tickets” to designing and setting up software factories. Each software factory fits a client’s own budget, criticality, and compliance constraints.

You may ask why clients would not build software factories in-house too. I believe these firms really sell two things. The first is experience: they have maintained legacy systems for many clients, so they know where a factory is likely to break on a legacy codebase. The second is confidence that the software factories work as intended, that the right human verification gates are in place, and that nothing triggers a regulatory issue. Because LLMs are non-deterministic, that confidence matters even more. After all, consulting firms have long sold expertise and risk transfer as well as hours.

Firms that bill hours for ticket triage, or whose edge is labor-cost arbitrage, are the most exposed. Firms that productize a factory, price it on outcomes and put their name behind it are the best placed. This holds most in regulated industries, where a client’s own compliance team will likely want an outside party to share the risk.

Astro is close to a best case, with strong tests, reporters who send reproductions and maintainers who know the code. Its team says that when the pipeline fails, the cause is usually opaque abstractions, missing comments or thin test coverage. This is one open-source project reporting its own results, so whether the approach works for a regulated bank is still unproven.

Clients that build their own factories will still face one question when something goes wrong: who vouches for this? Consulting firms that can answer it, with experience, gates, audit trails and a contract behind them, will have a business. Those that cannot will be competing with a free GitHub Action.

I rethought my Neovim config

Sun, 25 Oct 2026 00:00:00 GMT

Agents write most of my code now. So I stripped my Neovim config down to almost nothing.

Gone: LazyVim, LSP, completion, pickers, file explorer.

Left: my keymaps, treesitter highlighting, format on save.

Neovim is just for reading and small edits now. Reading a diff or fixing one line doesn’t need a language server.

Everything else moved up a level. I use tuios, and I set up keybinds at its level to pop up a cli tool whenever I want to do something manually:

Television for fuzzy searching
Yazi for browsing the file system
LazyGit for… you know what lazygit is. If you don’t, what are you waiting for?
Serpl for search and replace (made by a Moroccan btw)

None of them know or care what my editor is.

Now that my Neovim is stripped away and I use a dedicated tool for each job, I feel more compliant with the unix philosophy than ever. Each tool does one thing, Neovim included.

Just one more prompt

Tue, 14 Apr 2026 00:00:00 GMT

I have an idea, I write a prompt, and half a minute later there’s something on my screen that actually runs. Sometimes it’s exactly what I wanted, sometimes it’s completely broken, and I never know which one I’ll get until I look. So I look, and then I write another prompt, and then another one.

Programming used to slow me down on its own. There were errors to fix, docs to read, builds and tests to wait for. At some point I’d hit a wall, get up, make a coffee, and come back later with a clearer head. It was frustrating at the time, but looking back, those walls were what made me stop. Coding agents took them away, and nothing replaced them.

A tool that removes all the friction from starting also removes all the friction from not stopping.

I never sit down in the evening and decide to code until 3 AM. What actually happens is that I decide, over and over, to keep going for a few more minutes. One more prompt before dinner, one more before bed. Each of those decisions feels reasonable on its own, and it’s only when I add them up that I realize where the night went.

It doesn’t help that the finish line keeps moving. A feature looks almost done, so it feels like one more prompt will close it. It rarely does. The last part usually takes more back-and-forth than everything before it, but because I feel so close, I keep going. And when I finally go to bed, my brain doesn’t stop. It keeps writing prompts in the dark: a bug I could fix in five minutes, a small tool I could build before breakfast.

It feels like a slot machine because it works like one.

Research on behavioral addictions points to two things that make an activity addictive even without any substance involved: rewards you can’t predict, and a loop you can repeat very quickly. Slot machines have both, and so does social media. Coding agents have both too, but the reward is better than a like or a number going up. It’s something I built, and that’s much harder to walk away from.

That’s also what makes it so easy to excuse. I’m not doomscrolling, I’m making things, and some of them are projects I had been putting off for years. But being productive doesn’t make it healthy. A night of lost sleep is the same whether I spent it on TikTok or on a side project nobody asked for.

The real curse is how little effort it takes.

When building something only costs a prompt, I stop asking whether it’s worth building at all. Effort used to work as a filter: if an idea wasn’t worth a weekend of my time, it stayed in my notes and quietly died there. Now it costs thirty seconds, so it gets built. The first hour of a new project is pure reward, because everything works and nothing is broken yet. Then the edge cases show up, along with the docs, the cleanup, and all the boring work that makes something actually useful, and the rewards dry up. That’s usually when I open a new tab and start something else.

So I end up busy without really getting anywhere, with a lot of output and very little of it that matters. And because it came so easily, it doesn’t stick. I understand and remember the things I struggled to build. The things I prompted into existence, I barely remember making.

The friction developers spent years trying to remove was doing a job nobody noticed. Waiting for a build or getting stuck on a bug forced a pause. The agent never needs one. It never tells me to pick this up tomorrow. It just waits for the next prompt.

So the pauses have to come from me. That means closing the agent an hour before bed, writing late-night ideas in a notebook instead of opening a terminal, and keeping a list of new ideas rather than building each one the moment it shows up. It also means counting hours instead of features, because shipping six features between midnight and 4 AM is not a good day, no matter how productive it feels.

One comment in this Reddit thread put it better than I can: “AI saves you time. It doesn’t mean you have to fill that time with more work. Fill it with thinking about what you should do and why.”

Nix makes more sense in the age of AI

Sun, 12 Apr 2026 00:00:00 GMT

Two years ago, I went pretty deep into Nix and nix-darwin.

I spent a lot of time setting up my MacBook config so it would be declarative, reproducible, tracked in git, and more reliable than a bunch of manual changes and forgotten steps. I wanted a setup I could trust, rebuild easily, and roll back without stress.

I talked about it with colleagues, and a lot of them liked the idea immediately. The benefits were easy to explain. Reproducibility makes sense. Versioning makes sense. Treating your machine config like code makes sense.

A few of them even tried it seriously.

Still, most people bounced off it. The learning curve was steep, and the amount of effort it took up front was hard to justify. I can hardly blame them. Nix asks for a lot before it starts giving much back. You have to model your system, learn a new way of thinking, and fight through a lot of confusing edges. Sometimes you spend an absurd amount of time on a change that would have taken five minutes in a settings panel.

So even though I believed in the idea, I always felt a bit hesitant when recommending it. The upside was real. The cost was real too.

Two years later, I think the tradeoff looks better.

Nix itself is still Nix. It has not suddenly become friendly. The initial setup still takes real time and real patience. What changed is everything around it.

AI coding agents are now good enough to be genuinely useful on codebases like this. Tools like Codex, Claude Code, OpenCode, and Cursor can read through a Nix repo, follow the structure, understand patterns, and make the kinds of edits that used to require me to reload a lot of context into my head. I still want to review the result, obviously. But the routine burden is lower than it used to be.

That changes things more than I expected.

A big part of the cost of Nix was never just learning it once. The real cost was having to keep paying that tax every time you wanted to tweak something. Every small change meant re-entering the mental model, re-learning some corner of the language, re-discovering how a particular option worked.

That loop is much less painful now.

If the structure is already there, and the repo is reasonably clean, an agent can do a lot of the translation work between “I want this change” and “this is how the change should be expressed in Nix.” That makes the initial investment easier to defend. You are still paying for a system with a steep slope. You are just no longer climbing every part of it alone.

And honestly, this goes beyond Nix.

Lately I keep coming back to the idea that more of the things I care about should live as plain files in a repository.

My blog as Markdown files.
My machine config as Nix packages.
My finances as hledger journals.
Scripts, notes, little tools, all of it.

AI tools are unusually good at working with that kind of material. Give them plain text files and code, and they can actually do useful work: explain them, clean them up, refactor them, spot duplication, suggest better defaults, flag suspicious patterns, and automate the boring parts.

And the nice thing is that this does not require giving up ownership.

Quite the opposite. The more my stuff lives in simple files, the more control I keep. I can store it wherever I want. I can sync it however I want. I can inspect it with normal tools. I can diff it. I can revert it. I can roll back to an earlier state with a couple of git commands and move on with my life.

There is a real comfort in that.

It is not flashy comfort. It is the comfort of knowing that the important parts are legible and portable. They are not trapped in some product that feels convenient right up until the moment you want to leave, audit something, or recover from a mistake.

Git gets more valuable in that setup too. It stops being just version control and starts becoming memory, audit trail, and safety net. If an agent makes a weird change, I can inspect the diff. If I take things in the wrong direction, I can go back. If I want to understand how a system evolved, the history is sitting there in plain sight.

That is one of the more interesting consequences of the current AI moment, at least for me.

A lot of people seem to take AI as a reason to move further into opaque tools and magical interfaces. I keep landing in the opposite place. The better these agents get, the more I want my own work represented as files instead of hidden application state.

Once your workflows are in a repo, the agent becomes much more useful.

I still would not trust a model blindly with config, finance data, or anything else where small mistakes can have annoying consequences.

But the maintenance story really has changed.

A few years ago, adopting something like Nix often meant accepting that you personally would carry the full cognitive load forever. Now it feels more like front-loading the modeling work, then letting an agent handle a good chunk of the maintenance.

That is why Nix makes more sense to me today than it did two years ago.

The complexity is still there. What changed is the amount of leverage you get in return.

And that same logic is pushing me toward a broader way of working: code-first when it makes sense, file-first almost everywhere else. In a world full of capable coding agents, owning your workflows as text files in a repo feels less like a niche preference and more like solid personal infrastructure.

The old pitch for Nix was reproducibility.

Now I think the pitch is reproducibility, plus the ability to delegate a lot of the annoying work without giving up control.

My personal config is open source, check it here.

RFC: A convention for CLI tools to output LLM-optimized results

Thu, 09 Apr 2026 00:00:00 GMT

AI coding agents like Claude Code, Codex, and OpenCode run CLI tools all the time: tests, linters, builds. But these tools talk to humans. They print colors, progress bars, banners, long stack traces, and a line for every test that passed.

The agent pays for every one of those tokens, and the noise makes it worse at its job. It only needs to know what failed and why.

So I wrote a small proposal: a --llm flag that tells a tool “an LLM is reading this, keep it short.”

Why not `--json` or `--quiet`?

--json is made for scripts. It includes everything, and it’s often 10 to 50 times bigger than a short text summary. LLMs read text from top to bottom; they don’t walk through keys.

--quiet hides too much. The agent learns that something failed, but not what or why.

What’s missing is something in between: short, plain text, and still enough to fix the problem.

The idea

Two things:

A --llm flag: jest --llm, eslint --llm, cargo build --llm.
An LLM_OUTPUT=1 environment variable, so an agent can turn it on once for every command it runs. A flag passed explicitly, like --json, still wins.

When it’s on, a tool should:

Drop decoration: colors, spinners, box drawings, banners.
Report failures, not successes, plus one summary line like FAIL 2/50.
Keep stack traces short: the error and the top frames from your own code. No node_modules, no code previews with arrows.
Use a flat format that reads top to bottom.
Still give enough detail to fix the problem. --llm is not --quiet.

The test is simple: could a good developer fix the bug with only this output and the codebase?

An example

A failing Jest run normally prints dozens of lines: PASS lines, code previews, arrows, full stack traces, and a summary table. With --llm, it becomes:

FAIL 2/50

--- src/auth.test.ts:42 "should reject expired tokens"
expected: 401
received: 200

--- src/auth.test.ts:67 "should refresh token on 403"
TypeError: refreshToken is not a function
  at handleResponse (src/api.ts:15)

Everything the agent needs, for a fraction of the tokens. If it wants the code around line 42, it can read the file itself.

How it could spread

No standards body, no committee. Like --verbose and --quiet, it only works if people use it:

Build it into the tools agents run the most: Jest, ESLint, pytest.
Send PRs upstream, or ship it as plugins.
Have agent harnesses set LLM_OUTPUT=1 by default.

Later, the flag could take values like --llm=verbose. For now, it’s a simple on/off.

The full proposal, with the details and an FAQ, is on Codeberg. Ideas and contributions are welcome.

May I Smoke Here?

Sat, 21 Mar 2026 00:00:00 GMT

Someone has probably asked you this before. Or maybe you’re a smoker and you’ve asked it yourself, standing in the middle of a group of friends, lighter already halfway out of your pocket. It sounds polite. It sounds considerate. But I’d argue it’s neither.

This is written to you, the smoker. Not to lecture, not to guilt-trip, but because I think this small question deserves more honesty than it usually gets.

Asking “May I smoke here?” is not courtesy. It’s a trap dressed up as manners.

Think about what happens when you ask. The answer is almost always “Yeah, sure” or “I don’t mind.” And why wouldn’t it be? Nobody wants to be the person who says no. Nobody wants to come off as difficult, or controlling, or dramatic about it. So people say yes, not because they mean it, but because they feel they have to. That “yes” comes from politeness, not permission. It comes from someone who doesn’t feel entitled to say what they actually think, which is probably something closer to: I’d really rather you didn’t. You should never take that answer at face value.

And let’s say they do mean it. Let’s say the person across from you genuinely doesn’t care. That still doesn’t make it okay. You know what cigarette smoke does. You’ve read the warnings, you’ve seen the campaigns. Secondhand smoke is not some abstract concern. It’s a real, documented health hazard, and lighting up next to someone means actively choosing to expose them to it. The same goes for vaping, by the way. It’s newer, the long-term effects are still unclear, and that uncertainty is not a free pass. If anything, not knowing what it does to the people around you is a stronger reason to keep it away from them.

If someone walks up to you while you’re already smoking, the courteous move isn’t to keep going. It’s to put it out, talk to them, and light up again later when you’re alone or around fellow smokers. That small gesture says more about your character than any polite question ever could.

You probably already know smoking is destroying your body. You’ve probably tried to quit, maybe more than once. Addiction is real, and I’m not here to pretend it’s just a matter of willpower. It’s a trap, and escaping it is genuinely difficult. But if you haven’t found a way to stop hurting yourself yet, at the very least, stop making it someone else’s problem.

And honestly, the people who ask are already a step ahead of the ones who don’t. You know the type. Lighting up in a closed room. Smoking right next to someone without a second thought. But even in places where it’s technically allowed, where ashtrays sit on every table and the air is already heavy, you don’t have to add to it. Self-awareness doesn’t take a day off just because the venue permits it.

So here’s the alternative, and it’s simple. Step away. Go to a terrace, a balcony, an empty corner somewhere. Smoke where you’re not making it anyone else’s business. You’ll be more comfortable, nobody has to perform their “I don’t mind” routine, and the whole awkward permission ritual disappears.

Never ask “May I smoke here?” Not because you don’t care, but because you care enough not to put anyone in that position.

Zod validation that reads like docs

Mon, 06 May 2024 00:00:00 GMT

TypeScript types disappear at runtime. If you work with classes in Angular, NestJS, or any other TypeScript codebase that leans on OOP, that can leave an important gap at method boundaries.

This pattern uses decorators and Zod to validate method inputs and return values at runtime while keeping the TypeScript types aligned.

ZodDoc

ZodDoc is a small set of TypeScript decorators that use Zod schemas to validate method parameters and return values. It looks like this:

export class Statistics {

    // Returns the average of two numbers.
    @param(0, number) // `x` - The first input number
    @param(1, number) // `y` - The second input number
    @returns(number) // The arithmetic mean of `x` and `y`
    public static getAverage(x: number, y: number): number {
        return (x + y) / 2.0;
    }

}

The number argument passed to @param and @returns is the Zod schema itself. The omitted import looks like this:

import { number } from "zod";

Requirements

Zod

Install Zod with npm i zod. If you are not already using it, the official documentation covers the schema API in detail.

TypeScript Decorators

Angular and NestJS already rely on decorators, so this usually works out of the box there. In other setups, you may need to enable decorators in tsconfig.json:

{
  "compilerOptions": {
    "target": "ES5",
    "experimentalDecorators": true
  }
}

Implementing `returns`

Start with a simple returns decorator:

import { z } from "zod";
export function returns<T>(schema: z.Schema<T>) {
	return function(
        _target: Object,
        _propertyKey: string | symbol,
		descriptor: TypedPropertyDescriptor<(...args: any[]) => T>) {
            // TODO: Implement logic
        }
}

This is a standard method decorator factory. The generic T ties the Zod schema type z.Schema<T> to the decorated method type (...args: any[]) => T, so TypeScript can catch mismatches at compile time:

...
@returns(z.number()) // 🔴 Argument of type
                     // 'TypedPropertyDescriptor<() => string>'
                     // is not assignable to parameter of type
                     // 'TypedPropertyDescriptor<(...args: any[]) => number>'.
public doSomething(): string {
    return "";
}

Now implement the runtime check:

import { z } from "zod";
export function returns<T>(schema: z.Schema<T>) {
	return function(
        _target: Object,
        _propertyKey: string | symbol,
		descriptor: TypedPropertyDescriptor<(...args: any[]) => T>) {

            if (!descriptor || !descriptor.value) {
			    return;
		    }

		    const originalMethod = descriptor.value;
            
            // replace the original method with our own implementation
		    descriptor.value = function(...args: unknown[]): T {
                
                // Grab the original result
			    const originalResult = originalMethod?.apply(this, args);

                // Call the `parse` method of the supplied schema
                // with the original result as parameter.
                // If the original result is conforming to the schema, it
                // will be returned. Otherwise, a `ZodError` will be thrown.
			    return schema.parse(originalResult);

		    };

		    return descriptor;

        }
}

The decorator replaces the original method, calls it, and validates the returned value with schema.parse. If the value does not match, Zod throws a ZodError.

You can then use it like this:

import { z } from "zod";
import { returns } from "...";
export class Statistics {
    @returns(z.number())
    public static getAverage(x: number, y: number): number {
        return (x + y) / 2.0;
    }
}

You can also accept a function that returns a schema. That makes primitives slightly nicer to write, for example @returns(number) instead of @returns(z.number()).

- export function returns<T>(schema: z.Schema<T>) {
+ export function returns<T>(schema: (z.Schema<T> | () => z.Schema<T>)) {
     // ...
+       if (schema instanceof Function) {
+           return schema().parse(originalResult);
+       }
        return schema.parse(originalResult);
     // ...
 }

This also works with custom schemas:

src/.../UserResponse.ts

import { z } from "zod";

// Define the schema once.
export const UserResponse = z.object({
	id: z.string().uuid(),
	name: z.string().min(2),
	sex: z.enum(["male", "female"]),
	birthdate: z.date(),
});

// Infer the TypeScript type from the schema.
export type UserResponse = z.infer<typeof UserResponse>;

src/.../UserService.ts

import { UserResponse } from "./UserResponse";
import { promise } from "zod";
import { returns } from "...";
import { httpClient } from "...";

export class UserService {

    @returns(promise(UserResponse))
    public async getAuthUser(): Promise<UserResponse> {
        return await httpClient.get<UserResponse>("auth/me");
    }

}

The same approach can be used to implement @param as well: capture the original method, validate the targeted argument before calling it, and then delegate to the original implementation.

My participation in the ENSET Mohammedia's GEIW Hackathon

Mon, 20 Mar 2023 00:00:00 GMT

From March 15 to 17, ENSET Mohammedia held its Global Entrepreneurship and Innovation Week (GEIW). Part of it was a hackathon with one theme: use blockchain and AI to improve healthcare.

I joined with four friends from second-year GLSID and II-BDCC. We called the team TL3B, after the initials of our last names: Achraf Taffah, Abderrazzaq Laanaoui, Ahmed El Bouchouki, Mohamed Benchelbikh, and me, Ben Sadik.

Our idea was a platform that connects patients and doctors. Medical records would be stored on a blockchain, so patients stay in control of who can see their data. On top of that, an AI service would suggest a diagnosis based on a patient’s symptoms and medical history.

We built it as microservices talking to each other over REST. That choice had more to do with us than with the problem. I’m fastest with .NET, Ahmed and Abderrazzaq are more at home with NestJS, and the AI part made more sense in Python. Splitting the backend let each of us work in the stack we knew best.

We ran out of time before we could build a front-end, so during the defence we showed what we had: the backend. The code is unfinished and rough, but it’s still up on the GitHub organization we made for the hackathon.

We took second prize, and I was proud of what we pulled off together.

I got to try blockchain and AI on a real project, but what stayed with me most was working as a team against a deadline: splitting the work so everyone could move fast, and accepting that some things, like our front-end, just won’t make it in time.