Madalin Popa

Ok, so: when you create a new agent in Claude and write "you are an expert software developer...", the agent doesn't get access to some special expertise. All agents use the same underlying model, with the same training. Where agents really help is the context window: each one keeps its own topic and doesn't fill its context with everything else.

It's Sunday evening. Instead of watching a movie, I'm watching my AI agent work. "Why are you deleting that?" Better suspense than Netflix.

Blogs are scraped by AI without credit, and Google AI Mode no longer sends people to the actual site. Do you think email newsletters will come back strong as an alternative?

Understanding something is not equal to being able to do that something. Learning needs that "friction" that we try to avoid now with AI. So if you build something and you have the impression you understand it, try to build the same thing without AI. That's how you learn.

I believe two mindsets from the pre-AI and post-AI eras are not working well together. Move fast, break things + no need to read the code bro. What could go wrong?

Was open source ever only about the code? Now you can maintain a project for a long time, get a lot of contributions and never really talk to a person.

As a backend engineer who doesn’t like frontend development at all, I find AI a blessing. Anyone else feel the same?

Finally got access to the Rex beta from @superlogical yesterday. I have to say I’m impressed. After a few hours of using it, I don’t think I want to go back to anything else. Once again, @mitchellh and the team have shown they do great work. While exploring and enjoying this tool, I had a thought. In the future, the people behind a piece of software will matter more than ever when we choose a product. At least for me, this already matters a lot. Having followed Mitchell and his work for so long, I was almost sure I’d get a quality product. And I think this will become even more important as AI makes building software easier and faster. We’ll probably have more software than ever, but more choices don’t necessarily mean better products. Knowing who’s behind a product, their track record, how they approach engineering, security, and long-term maintenance will increasingly influence my decisions. Of course, reputation doesn’t guarantee quality. Every product still has to prove itself. But when almost anyone can build software, knowing who you can trust to build and maintain it becomes increasingly valuable. Writing code is getting easier. Building something worth trusting is still hard.

I decided to invest a little in this platform, hoping to find real human connections: people with real opinions based on their own experience. But to be honest, I'm tired of these "nonsense, just make noise" posts. I'm old enough to remember the times when people only posted when they had something to say.

Someone asked me if I allow AI co-author attribution in my commit messages. I said no, for two reasons: First, if something is broken or wrong, I can't blame Claude. I'm the only one responsible for the code. When Claude can share the responsibility, I'll allow it. Second, if I do this for Claude, I would need to do it for all my tools. Co-Authored-By: vscode and the boys. Do you allow AI co-author attribution in your commit messages?

Trying something new in my framework: the prototype is the spec for features and behaviour. My app specs stay light, just ADRs and the stack. The prototype can be a web app, a CLI, a service, or just part of the code. solomonar.dev/?v=1

Have you noticed? In almost every movie where AI takes over, there's still one guy who knows how to code. What does that tell us?

"I put a lot of effort into this software" is out. Now it's "I put a lot of tokens into this software." Bonus: you finally know the exact development cost.

Why I built my own framework for spec-driven development with AI I tried other spec-driven frameworks, but I couldn't adapt them to the way I work. So I built my own: Solomonar. Here are the three main reasons. 1. I wanted something light. I didn't want a system I'd have to learn and then bend my workflow around. It should be the other way around: you take a framework and adapt it to how you work. Solomonar is small at its core: a process, a minimal set of rules, and a CLI that checks every step against Git. The core is 4 skills plus the agent roles that implement and review. No language or stack assumptions. It's not a library of skills and agents. 2. Parallel work. Git worktrees isolate files, but they don't coordinate agents. Two sessions can still grab the same task, overwrite each other's progress, or merge on top of a main they never saw. To run several agent sessions in parallel, you need shared state. In Solomonar it's a task registry on its own Git ref, written only through the CLI with compare-and-swap. No progress files on feature branches that conflict at merge. What you get: • Every task gets an ID (W-001, W-002…) and its own branch and worktree • Tasks start one at a time, then run in parallel • Dependencies are recorded, and dependent work waits until the prerequisite is merged • Before merging, each branch takes in the latest main, and reviews rerun if main touched the same files • Merges land in main one at a time, and a task can't be marked done until its merge commit is on main 3. Extensibility. I wanted it to be easy to add rules, skills and agents and plug them into the process, grouped logically: language, frontend, persistence, testing, workflow, review. Each extension declares when it applies (e.g. "a change touches *.go files"), and its "must" rules bind both the implementer and the reviewers. Adopting a stack extension is recorded as an architecture decision, so agents follow the stack you approved, not a default. The Go extension ships today. Adding extensions later and writing your own are next. Bonus: every change gets independent reviews. Security, correctness and spec reviewers check the same commit in parallel, and risky changes also face an adversarial reviewer. Open source, MIT → solomonar.dev/?v=1