And here, my friends, is the difference between vibe coding and AI assisted engineering

Over the past few days, I've been reading some genuinely disturbing accounts from people who have been laid off in tech. I've included three of them in the carousel, but there are countless others. Some of these people have 20+ years of experience, having worked as senior engineers, engineering managers, and even CTOs. People who have spent decades building their careers and are now struggling to find employment, exhausting their savings, and worrying about how they'll support their families. Meanwhile, close to 200,000 tech workers have reportedly been affected by layoffs this year alone. Some other hundred thousands will probably happen next year as well. Yet, every other day I come across another millionaire tech influencer, smiling condescendingly from a shiny YouTube thumbnail, proclaiming that "Engineering matters more than ever." Of course engineering matters! I don't think anyone seriously questions that. But the importance of engineering as a discipline and the employment prospects of individual engineers are two very different things. I find these ivory-tower takes increasingly disrespectful towards people who are genuinely struggling. They offer a false sense of security, as if being a good engineer, continuously learning, and keeping up with the latest technologies somehow guarantees that everything will be fine. I've spent over 15 years in software engineering. I'm currently a CTO, still very much hands-on, and I have absolutely no reason to believe I'm immune to any of this. Neither does anyone else, regardless of their experience or seniority. I don't know what the job market will look like in two or three years, and I don't think anyone does. But I do think there's a very real possibility that many more of us will find ourselves in situations similar to those described in these accounts. As an engineering community, I think we need to acknowledge this possibility and start having much more serious conversations about what it means for our careers and how we can prepare for it. Continuously reassuring people that engineering matters more than ever, without addressing the actual risks they're facing, isn't particularly helpful.

From my POV the PHP stuff is not that problematic. In the end it's just discovered CVEs, published patches that can be applied. Though I obviously understand the stress and additional workload this might create.. More concerning to me is the eMudhra certificates problem. I still can't fully grasp how an organization entrusted with internet certificate issuance generated eight effectively guessable private keys, failed to detect them through two audit cycles, and apparently missed an earlier opportunity to investigate the very same keys. This might go beyond just a technical failure as this area is quite regulated and this issue should have been caught way earlier.

I honestly can't remember another week quite like October 14–21 in software security. Just between October 14 and October 21: - Next.js patched two critical RCE vulnerabilities (9.5/10). - NGINX patched five security vulnerabilities. - PHP disclosed critical RCE vulnerabilities. AWS observed exploitation attempts four days before disclosure. - Node.js patched multiple vulnerabilities, including potential RCE and TLS validation bypasses. - GitLab disclosed another 10/10 vulnerability allowing potential unauthenticated RCE. - LiteLLM's compromised releases distributed credential-stealing malware. - Railway disclosed a potential exposure of customer secrets and API keys. - OpenCode reported a breach affecting 1.4% of its Console users. - eMudhra had eight trivially recoverable certificate authority private keys. One of them was literally the number 4! Also, Microsoft reported AI-orchestrated attacks targeting over 2,250 Microsoft 365 tenants, with attackers obtaining privileged access in under three hours in multiple cases. CrowdStrike documented AI agents conducting real-world intrusions, including one that obtained domain-controller credentials in approximately 20 minutes without further human guidance. Meanwhile, Cloudflare observed PHP exploitation attempts growing to millions within hours of disclosure. Some of the attacks even started before any public disclosure, which shows that malicious actors have ways to get to the important information way before any organization does. All of this obviously made me think about what this means for engineering organizations. For years, we've treated vulnerability management as something that happens periodically. We review advisories, create tickets, plan upgrades, and eventually deploy patches. Sometimes days later, sometimes weeks, and quite often months or even years. That's not going to work anymore and technical decision-makers will need to fundamentally rethink how their organizations approach security. Continuous monitoring, immediate exposure assessment, automated mitigation, credential rotation, and rapid patching need to become standard engineering capabilities. We need to start measuring our security response times in minutes, not days, weeks, months, or years.

This week we started work on a huge new area of our Atherio system. In the "Modern Engineering" Community I have posted an extensive breakdown on how we started from 1 Notion page to arrive at 1 High Level Plan, 12 Areas of Change, 24 implementation tasks (only for the first area) and parallel implementation of 19 of them in one day. If you are deeply interesed, check it out and join the community: danpatrascu.com/community/

SSO? Anthropic doesn't even offer basic MFA for non Team/Enterprise subs (except obviously if you login via Google, but then it's Google's MFA)

Can we re-write PHP in Rust?

I was less than 1 month into the new role of Divisional Software Architect when my manager brought me into an M&A process. The company was about to do an acquisition. To be clear: my role was not to perform due dilligence. This is usually done by 3rd parties to ensure there's no bias in the process. My roles was to understand and estimate ($$$ at the end) the effort it would take us to integrate the new system into our division, bring the new product to the same security, data-privacy and operational baseline we used throughout the division and providing a roadmap for it all. It's really not important what that estimation was. It was considerable. However, over the past few weeks I kept thinking back to that estimation and realized that if I'd had to make the exact same estimation again, it would be probably around 8x less. That's because in a proper AI-Assisted Engineering setup, the effort to integrate a new system would be substantially less. I don't really see many people talking about this, but I think AI is fundamentally also changing the economics of M&As. Or am I wrong?

Reading through "conflict" between Marc Lou and Tyler Denk, there are so manu things I'd want to say... But I'll keep it to this: both are wrong and shallow. And if I'd be the VC behind Beehiiv (or how it's called) I'd make Tyler understand that his behavior is unacceptable

Idk what's wrong today but Opus 5.5 starts feeling like Opus 5.

The fact that Opus 5.5 gets so basic software archtiecture principles totally wrong just shows us the amount of human code slop the LLM was trained on.

As an engineer myself, looking at these numbers made me sad! According to the 2026 Stack Overflow Developer Survey, the biggest difficulties engineers face at work include unclear priorities, inefficient processes, lack of time, and organizational changes. And then there's Atlassian's 2025 State of Developer Experience report: - 63% of developers say their leaders don't understand their pain points. - 50% report losing at least 10 hours every week to inefficiencies. The main problem with tech organizations is that they try to address these challenges by throwing more tech at them. However, these leadership challenges, not tech challenges. This is actually one of the problems we're trying to address at Atherio. Helping organizations develop a much clearer understanding of their people, how they create value, and where things aren't working as they should. And how to fix them, obviously!

I'd just want to add that such moments should always lead to an update in memory/agent/skills/rules/hook setup so that the LLM can't make the wrong decision next time.

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.