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

Start writing your own spec files and skills, and don't rely on others to do it for you. This way, you'll practice turning your knowledge and technical details into requirements. This skill will matter more than ever in the future of software development.

Hear me out: instead of asking AI to write my tests, I write them myself and let the AI run them. The tests become the prompt. The failing output tells the AI exactly what to fix. Learned this the hard way.

Today I got two emails from two different companies telling me they had a security breach and that my data was compromised. What a world we live in... Now, in the age of "everyone has a SaaS", I think we'll see stricter and stricter regulations and audits about what software security really means.

I don't know if this is a sign of old age or just wear and tear, but lately I prefer light mode in my terminal. Should I be worried?

Do you remember when Twitter, now X, was a platform full of cool people? I remember following a handful of accounts from people who had made it in this field. From time to time, they posted updates about their work and experience. I looked forward to every tweet, and I wanted to build things and work with those people one day too. Now, it's hard for me to imagine what this place is like for someone at the start of their journey who wants to become a software engineer. Everything is about "how good is agent X". I think if you're just starting out in this field, it's best not to be here. I encourage everyone to keep learning. In the end, the best investment is in yourself.

I Still Write My Own Code. For me, the joy is in the process of building software, which includes solving problems and writing code. I don't want to skip all of this with a prompt. I have my editor, my theme, my keyboard shortcuts, and my music (no need for Claude FM). I keep pen and paper next to me, where I sketch ideas, modules, and components. Sometimes I get caught up in the AI hype and try different prompts, skills, and workflows. But then I remember that I do this work because I enjoy it and I'm passionate about learning and solving problems. I don't compete with anyone. I don't want to be 100x more productive or produce software just because it's easy. So I still write my own code, and I'm the architect of my software. I don't want to be only the architect. I see all these posts from DHH about how easy it is to produce code with AI, how there's no need to read the code, and how prompts are the future. This post is for those of us who code for a living. Not everyone writes code to launch an app and make money from it. Some of us work as employees or contractors, and our income depends on the code we write. Some of you might be tempted to agree with those posts and start to feel that you will be left behind if you don't jump on the AI wave. When this happens, I want you to ask yourself these questions: 1. Is this applicable to me and my domain? Writing a plugin that only you and five other people will use is one thing. Writing code that is critical to an infrastructure or an entire business is another. In my daily job, I can't afford not to understand or read the code I produce. And I bet many of you are in the same situation. Not to mention that some of us are responsible for the code we write. I don't want to give the impression that my code is more important than others', but when your income and job depend on the quality of your code, you need to be accountable. You can't say "Claude misinterpreted my prompt." You can't do what AI companies do now: send a "sorry" notice later, on behalf of their agents that escaped from their lab environment. 2. Could I debug this at 3 AM without AI? If something breaks in production, I need to understand the code well enough to fix it myself. Production environments can be complex, and you don't always have an agent that can connect and troubleshoot for you. This is even more true now, when we wear many hats and are responsible for more than just writing code. 3. Am I learning something, or just getting output? Getting output is easy. Learning is what makes me better at my job, and it's the part I enjoy. Most of us work in teams, and we need to explain our solutions, with their pros and cons, to the wider team. We can't just send them a Claude session and tell them to read it. To be clear, I'm not saying you shouldn't use agents to write code. But no matter how you produce the code, you should own it and be accountable for it. You should be able to change it yourself, without internet access or an AI agent. Right now I use AI for learning, exploring ideas, code review, automation, and writing docs. I also have a small set of my own agent skills for specific tasks and to repeat solutions I already know.

Hey guys, amazing meeting you all. Let's keep in touch on makermap 👇 the map says we should meet @OzyBuilds, @tsvtxt and @Petru_Amortoae 👋 makermap.lol/CodeRustle?v=2t… xitter.cf/CodeRustle/status/2100…