The day the business started deploying to prod
Anna Peter
SubscribeSign in
The day the business started deploying to prod<br>Reflecting on the past year as an FDE - AI is changing who's shipping software, but our systems for managing the risk haven't caught up.
Anna Peter<br>Aug 20, 2026
Share
For a long time, if someone in a large company wanted a piece of software, there was a fairly predictable process: write a ticket, get it prioritized, wait for engineering, go through security, deploy it.<br>That process was slow. Sometimes painfully slow.<br>But it also meant someone knew the software existed.<br>With AI, much of this process can now be skipped. Nowadays a business user can build and deploy something themselves without jumping through all the hoops.<br>This is the reality where I found myself as an FDE in London. If you aren’t familiar with the role (and trust me it’s not a fake job) - it’s somewhere between a software engineer writing production code and business’ genie, granting their every wish immediately. In my daily work with business stakeholders, I helped them integrate hardcoded values that would never generalize, simply because waiting for the official engineering solution would have taken months, or worse, because they were afraid of the IT department.<br>Now that I’m back home in Switzerland, I keep thinking about how much effort large companies put into controlling what reaches production. Security reviews, approvals, change management, access controls - all boring stuff, but there for a reason. AI makes it increasingly easy to go around all of it. When business sees need for a new functionality, they no longer have to wait for a six-month IT sprint - they can vibecode it and deploy it in the shadows. This is super cool in terms of enablement and helps put some pressure off already overloaded IT teams, but misses out on the longer-term view.<br>What happens when business “goes rogue” and deploys their own software? A traditional software engineer gets migraines just hearing tales of this shadow IT. But for the business, their eyes lit up. What can be easy to miss is that their “quick AI go-live” is accumulating a massive, unquantified technical liability…<br>To understand just how dangerous this is, I went back to the holy grail - Google’s SRE book. I wanted to see how its core principles apply to vibe-coded applications released cowboy-style on a Friday evening. Below some notes.<br>Chapter 6 - Monitoring.<br>Traditionally, you would collect system metrics and build alerting on top of that, triggering on-call for urgent issues. Handing a vibe-coded application over to IT has several challenges: a) we go back to the endless IT backlogs and limited capacity b) what are the relevant metrics for this application and who defines it? c) in case of an incident, quick resolution would ideally be based on a playbook. In reality, quite often there are on-call heroes who “fix it all” - but can they reliably work with AI generated software they never previously touched?
Chapter 8 - Release Engineering.<br>Google’s release-engineering practices emphasize hermetic, repeatable builds. In reality, business is under immense pressure to release fast. Quite often this results in so-called “unique snowflakes” - manually fitted releases that are neither automated nor repeatable. Also, who even thinks of release management until Friday before end of Q3 when the product should be launched?
Chapter 9 - Simplicity.<br>Simplicity before reliability. When we introduce new code, we should think about its maintainability - time spent reducing code complexity and volume is time well spent. AI famously introduces heaps of “slop” - from harmlessly redundant boilerplate to phantom packages that can be exploited by hackers (see slopsquatting)
This isn’t just theory - as legendary engineer Dan Luu puts it (see also his insightful notes for a more comprehensive general summary of the book), we are suffering from the “normalization of deviance”. We get so used to bypassing safety checks, manually tweaking servers, and ignoring warnings that this becomes the operating standard.<br>As a last cautionary tale, consider the infamous Knight Capital incident, where dormant “dead code” caused a $400 million loss in 45 minutes. AI could never. Right?<br>What to make of this? For me as an engineer, looking at the wild west of modern code gives me headaches.<br>But also, I think it’s showing an interesting shift in responsibility (and liability) for technical solutions. Not only are we changing who gets to create software, but also shifting the responsibility to maintain and uphold said software. The old mechanisms for assessing risk (compliance reviews, questionnaires, approval processes) assume static software whose existence is known. That assumption is becoming less reliable. Until we can automatically understand and contain the risk of the code we deploy, faster software development may simply mean faster growth of technical liability. Those shiny new business kpis...