Madalin Popa @coderustle

@lucas_builds For someone who's still learning, yes. Writing code by hand is part of the learning process.

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.

AI didn't kill software engineering. it just moved the bugs to places we don't understand 💀

Good question. I left out heartbeats and time-based takeovers on purpose. If a session crashes, the task stays owned and nothing happens automatically. You decide how to recover: - Resume as the same owner. task status shows any differences between the record and Git, and the session reuses the existing worktree and PR. - Or hand the task over: "solomonar task handoff W-001 --owner orchestrator-2" Every write uses --as and goes through a compare-and-swap check. After the handoff, any write from the old owner is rejected with owner_mismatch One limitation is that, the CLI protects the registry, not the files. If the “dead” session is still running, it can still change files in its worktree. That’s why you need to confirm the old session has stopped before a handoff.

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

@kidtsang 100% agree. Extensibility should be easy.

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.

@ThePrimeagen No. In the near future we'll see a lot of security breaches. Software will be regulated and audited more and more strictly. The cost of building software will move to audits, security, and infrastructure. The need for expertise will grow.

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 was thinking of making a lesson plan with ChatGPT to generate vocabulary, exercises, writing practice, and audio conversations, plus listening to podcasts. I also noticed plenty of plugins for this, but I think I'll go with a teacher once I get back home.

After my trip to Spain, I plan to improve my Spanish, and I can't decide between using ChatGPT and taking lessons with a real teacher. How do you guys learn a new language these days? I tried Duolingo and similar apps, but they didn't work for me. I'm a self-learner, so learning with AI looks like a good fit for me. But at the same time, these days I really value human interaction more, and learning with a real person is also a way to support them.

A very short story

@RaulOnRails Congratulations, man! Happy to see fellow Romanians succeeding in this domain. And as someone mentioned, I'm happy too that you chose the local market.

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.

@iuliatech Hei! 👋

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=2… x.com/CodeRustle/sta…

Madalin Popa @coderustle

a month ago

I'm 37. DevOps engineer based in Bucharest🇷🇴 I write Go every day and love keeping things simple and easy to maintain. Looking to connect with more builders, DevOps folks and Go devs!

4 0 2 198 0