It was a great experience talking at "I Love Tech" in Timisoara a few days ago. To me it was a confirmation that the most interesting part happens after the talk, during the breaks. I got to talk face to face with around 20 engineers from the region and what I heard from them didn't really surprise me, but still made me sad on one important count. The disconnect between what engineering organizations are posting on socials or their corporate blogs and what happens in their teams was never bigger than it is now. Talking to engineers I understand their frustrations as: ❌They've been handed an AI license and everyone should figure it out from there ❌There's no governance on AI usage and no real measurement to understand the outcomes of the AI assisted engineering efforts ❌There's no (or very poor) setup of deterministic guardrails to ensure code quality, security and data privacy ❌There's no real effort to understand and manage skills, memories, agents on a team and org level The main problem with this is that we can teach engineers how to work, but if their management doesn't take some minimal steps towards a proper organizational setup, every individual effort is in vein. So, I'm genuinely curious, why does technical management always think they have everything under control and they are doing great when their team's morale is lower than it ever was?

I usuallly prefer not to go into this topic, but the most worrying thing for me right now is that European countries are not able to defend themselves not even from internal riots. Seen that the US is now on Russia's side I'm genuinely worried about our future.

One of the aspects I'm very pleased on my agentic engineering setup is the investigation setup. I can investigate literally everything with just an initial prompt of a few words! The setup does the rest. Looks up the database, telemetry, code, documentation and it always just loads into context the information it needs for a certain task. I have exported the entire setup and made it available in the "Modern Engineering" community. However, it's not just a bunch of skills, hooks and rules. No, it contains literally everything that I use to make sure that: ✅No mutation operations happen on the database ✅No sensitive or private data ever touches the LLM ✅Proper PIM and Just-in-time access for investigation agent accounts. All of that is part of the downloadable resources as PowerShell and bash commands that can help you set something similar up in a matter of minutes. Plus a lot of Python scripts I use for different hooks in the entire process. Everything is also described with a lot of diagrams and visual aids in a 35 page PDF file. This is the kind of setup that's literally taken from our production Atherio system and vetted by the security certifications we already went through. If you want to become a community member and get it here's the link: modern-engineering.circle.so…

Getting ready to talk at I Love Tech about how to make AI engineering work in practice

“Always use a different model for code review” is cargo-cult engineering. On 116 LiveCodeBench tasks, Claude drafts passed 91.4% of tests. After Codex reviewed/revised them: 82.8%. Fresh Claude review: 91.4%. Different model ≠ better reviewer.

Over the past few weeks I did an experiment and bought some "agentic engineering" courses. Some of them from very reputable platforms. Others from some clickbait ads. Some of them at reasonable prices. Others really over 200 USD. Do you want to know what those all had in common? They were all just videos starting from official Anthropic documentation with a sample app that can barely get the title of "weekend project." What you don't realize is that you take such courses and think you got it: that's how AI engineering is done. Then you confidently go to an interview and hit the hard reality: - you have no idea how to secure the agentic coding setup in practice (because, yes, that goes well beyon the official documentation into real engineering that doesn't have anything to do with AI) - you have no idea how to make sure coding agents don't have access to data they shouldn't - you have no idea how to manage project memories across teams and organizations - you have no idea how to idea how to make sure that all devs on a team get consistently the desired outcomes. There are a lot of influencers out there that sell courses. They haven't been in charge of a real production system for years. What they do is work on hackathon projects or small sample apps and then sell you some basic stuff as "that's how you do it in prod." It's not! In the end it's your choice who you trust for your future. But then don't get irritated when you hit reality and don't try to find scape goats for your own bad decisions in terms of education.

Ive put together a practical guide to implementing a Context Layer for coding agents! The idea is to organize project knowledge so that agents can discover the relevant information, assemble the context they need for a specific task, and keep documentation up to date as the code evolves. A complete, ready-to-adapt implementation can be found in my "Modern Engineering" community. The entire setup available as a single download: documentation templates, agent instructions, three agent skills (Discover Context, Assemble Context, Maintain Documentation), and validation tooling. It works with Codex, Claude Code, and OpenCode. You can find the full kit here: modern-engineering.circle.so…

Compact Disk 🤣

When I see "Dr. " in the Linkedin name and the post starts with "When everyone can build software, software becomes a commodity" my first instinct is to immediatly block that person.

I guess I'll stay with Claude Code as my main coding agent at least till the end of the year. Opus 5.5 seems to be the best model for my workload so far.

Memory systems are definitely a great addition to coding agents. However, they can turn a blessing into a curse quite easily if not managed properly! In my Modern Engineering community I have shared my concrete steps and technical implementation that ensures the Claude Code memory doesn't turn a blessing into a curse. You can join the community here: modern-engineering.circle.so… P.S: Tomorrow there will be a new practical resoure drop that can bring your AI-Assisted coding to the next level.

People underestimate how much I appreciate vibe coders! I really do! I work with one. Let me tell you more about it. At Atherio we have our main system which contains all our proprietary algorithms, data, business logic. It's my responsibility to take care of it and make sure it's secure, up to date and that it runs smoothly for our customers. There's no vibe coding here, just pure engineering work. Yes, AI assisted but still 100% proper engineering. On the other hand, Ben is a powerhouse when it comes to marketing/sales/networking. Very often he comes with different ideas that require some basic tools. He's totally non-technical. So he vibe codes what he needs for his purposes. And I'm totally fine with that. Till now he has built and deployed an ROI calculator, a page that syndicates the content from his podcast and my newsletter, the Employee Lifetime Value Index survey and a bunch of other stuff. You can't really imagine how thrilled I am with that. Pre-AI I would have to create all of those myself, taking time away from the core system. Which matters a lot. That would also introduce a bottleneck. From his idea to the implementation it would take way longer. Now it's about a couple of hours from idea to something that works for a certain purpose. We just agreed on some basic stuff and we review some of the things as needed, but my involvement is minimal. So, yes, even in an engineering business I think there's a time and place for vibe coding, as long as the way of workings and the boundaries are clear, planned and accounted for.

The most dangerous thing about AI is people not having even the minimum ethical standards of a chatbot.

I so hate it when "big accounts" say something dumb. You politely point out what's wrong. Then they delete the post. What I'd expect people to have at least the decency of coding agents to say "you're absolutely right and I was wrong" and then move on. The most dangerous thing about AI is people not having even the minimum ethical standards of a chatbot.

In 1984, Eliyahu Goldratt and Jeff Cox published The Goal, introducing the Theory of Constraints (TOC). One of its central ideas is that the throughput of an entire system is determined by its constraints. Improving individual components doesnt necessarily improve the entire system. And once a constraint is sufficiently improved, it moves somewhere else. Seeing the shifts in software engineering over the past two years made me reflect quite often on the TOC. Yes, coding was a constraint! Ive been in software for over 15 years and Ive rarely seen new features developed in less than a few sprints. Nowadays, single engineers port entire frameworks to new languages in weeks. Coding agents have dramatically increased our capacity to produce code. Yet that doesn't necessarily translate into a matching delivery throughput. Requirements, architecture, code reviews, testing, releases, product validation. None of these appeared because of AI. What changed is their relative capacity compared to coding. Much of our engineering process was designed around the economics of code production. Those economics are changing, but our processes havent necessarily caught up. I get the impression that many engineering organizations are still concentrating on optimizing the constraint we used to have. I think one of the biggest challenges for engineering leaders today is changing how we approach technical decisions. Before deciding what to optimize, we need to ask ourselves whether were addressing the current constraint or simply continuing to optimize the one weve spent the past decades dealing with.

Although I agree with the general idea, I think this argument is objectively wrong in this case. Google basically acquired the entire founding team, leaving the entire company in a zombie state. AI or not, I don't think any startup could survive its entire founding team being gone

Leading based on real-time insights instead of gut feel seems to be a recipe to success! Here's just one case study of a manager that took Atherio seriously. Daily conversations with Athi, daily check on the fresh data and then decisions and interventions based on that data. What we immediatly see is employee engagement going up. Leadership effectiveness as well. What we don't see in the data and it's based on feedback: - one employee was considering leaving. Our data showed the signal, the manager had the conversation and the employee didn't quit - another employee was struggling to balance work and personal time. Another intervention, some work re-distribution across the team and things got visibly better. A 30K replacement cost was avoided.

No AI at all in writing this, so there might be typos and odd formulations. But I think it might be useful