Deploying from your IDE is a bug, not a feature
Turning an anti-pattern into an easily accessible feature makes it worse, not better.
Some of you might be old enough to remember when editing PHP files on the production machines was considered standard practice, almost a proof that people knew what they were doing.
A slightly improved version of that involved using ftp to manually copy edited files from one's laptop or workstation into the production server.
Decades of experience and smart people putting their brains on the topic, the industry at large moved away from such reckless and unsafe practices, towards more reliable and repeatable deployment mechanisms. One could argue that the whole premise of DevOps was to build safe, reliable, and cheap ways for software engineers to ship their code to final users.
I'm afraid we're now witnessing a potentially massive regression phase, one in which decades of experience and practice are being sacrificed on the altar of convenience and doped product growth metrics.
The worrying trend with AI-assisted coding environments
One relatively recent event sparked a disproportionate amount of reactions:
In essence, in an unfortunate sequence of events, Replit apparently completely nuked the production database of a SaaS tool, effectively destroying months of work.
Lots of people reacted crying victory, as this seemed the final demonstration of the insanity of the practice that has become famous under the silly vibe coding term.1
Some reacted by directly attacking the victim, accusing them of incompetence, that they deserved the lesson, much like the old days of what posting a naive question on StackOverflow would earn you.
Others accused Replit of building a tool that didn't follow the user's instructions. The user had apparently written specific instructions to prevent the software from making any further changes in production, some "code freeze" of sorts.
While I do believe that vibe coding is essentially garbage and that incompetence should not be an excuse for blaming others, I definitely believe Replit and most other AI-assisted tooling vendors bear a significant responsibility in what is going on.
If I find it shameful that the agent/LLM in question didn't respect the given instructions, I'm not surprised it happened, and I don't believe that's the worst part of Replit's misbehaviour in the affair.
Partly because, despite all the biased propaganda that would like you to believe the opposite, large language models aren't deterministic systems. Hallucinations are an inherent pitfall of the technology that no one knows how to solve, because they can't. Replit, like all other vendors, uses the same foundational models provided by either OpenAI, Anthropic, or Google, and has absolutely no control over how they behave. There is plenty of literature on this aspect; it's not worth spending more time on it here.
The main reason I blame Replit and similar vendors for that specific problem is that I believe they are the culprits of a vastly more insidious type of wrongdoing, of which the above incident is nothing but a symptom.
In their attempt to put convenience above all else, likely moved by the desire to ease the barriers to entry into the programming world for people without professional experience, they've gone as far as to discard decades of advancement in software engineering and deployment engineering, more specifically.
Most of these tools, be it web-based solutions such as Lovable or Replit, or IDE-based solutions such as Cursor or Windsurf2, have built their own flavour of one-click deployment to production, an almost blatant affront to the last two decades of good engineering practices.
Jez Humble3 is luckily too young and too alive to be turning in his own grave, but I guess he might be at least violently spinning in his office chair.
I don't know whether this trend is driven by a deliberate agenda to trick people into shooting themselves in the foot in an extreme attempt at oversimplification of the fairly complex discipline of software engineering, or whether this is a result of pure incompetence.
It's a typical case of Hanlon's razor4, which I'll leave up to each individual reader to resolve.
Software Engineering vs Programming
Naming things is hard. It's one of the 2 hardest things in software engineering5.
One of the most common issues with naming in our industry has been the conflation, or should I say simplification, of the act of programming and the broader discipline of Software Engineering. Though there isn't a single definition that is universally accepted of what Software Engineering is, and its relationship with the mere act of programming, I do like the one put forward by the authors of the book Software Engineering at Google (emphasis is mine):
We propose that “software engineering” encompasses not just the act of writing code, but all of the tools and processes an organization uses to build and maintain that code over time. What practices can a software organization introduce that will best keep its code valuable over the long term? How can engineers make a codebase more sustainable and the software engineering discipline itself more rigorous? We don’t have fundamental answers to these questions, but we hope that Google’s collective experience over the past two decades illuminates possible paths toward finding those answers.
One key insight we share in this book is that software engineering can be thought of as “programming integrated over time.” What practices can we introduce to our code to make it sustainable—able to react to necessary change—over its life cycle, from conception to introduction to maintenance to deprecation?
In essence, programming, or the mere act of writing code to solve a specific problem or implement a use case, though an essential part of the discipline of software engineering, is just a subset of it6.
A significant contributor to Software Engineering that goes beyond pure programming is its emphasis on release and deployment management: CI/CD, repeatability, reliability, and other practices aimed at ensuring that what works on my laptop will not wreak havoc when shipped in the production environment.
And most AI-coding vendors, including Replit, are getting it all wrong.
Fixing that is, without any doubt, their full responsibility.
Encouraging users to give LLMs and AI agents direct access to production environments to drive adoption is, at best, shortsighted. At worst, something that should outright ban them from distributing software engineering tools.
You have a duty to educate your users
If you offer a product, especially one that offers the ability for people to access skills and capabilities previously considered out of reach to them (as if studying an practicing had suddenly become something to avoid at all cost for the sake of moving quickly, but I digress…), you have the moral duty of teaching and educating those same users on the principles that constitute the foundation of the discipline you're enthusiastically pretending you're making accessible to them.
The fact that Amjad Masad, Replit's CEO, declared in January that the company doesn't care about professional coders anymore7 only makes things worse, not better. If that's their target audience, Replit has an even more significant responsibility to educate its users on table-stakes practices.
A delivery process should be reliable, repeatable, and most definitely, it should not take initiative on its own. Convenience should be a byproduct of implementing it in such a way that reduces human interventions to the minimum while ensuring a broad set of safeguards limiting the risk of shit happening.
Bypassing such controls and misleading users, be it implicitly or explicitly, who lack the required domain knowledge to understand the risks they're exposing themselves to by trusting your tools, is pure Snake Oil practices.
AI vendors must either find a way to implement proper release management in their tools, while clearly teaching their users about the risks of taking the easy path, or stay out of that game for good.
They should stop promoting incompetence and recklessness as the new paradigm of productivity and target their products narrowly at the programming part, where they can provide value. And leaving it to other, more competent and arguably more honest vendors to take care of handling other critical aspects of the entire supply chain, such as production access and deployment.
Help the newsletter remain free!
Engaging with my professional services is a great way to ensure I can continue dedicating many hours each week to producing what I hope to be high-quality content.
Those services revolve around three legs:
Fractional CTO or Advisory roles for startups, scaleups, and established tech companies. Find out more on this page.
Individual Mentoring and Coaching for Engineering Leaders. Find out more on this page.
A paid Community for engineering leaders. Find out more on this page.
If your needs fall into a different category, such as newsletter collaborations or sponsoring, please reply to this email or schedule a free call via this link.
In case you're wondering, I think the entire discourse around vibe coding is just a sign of planetary-scale early dementia. If you want a more nuanced take, have a look at this informative video.
Interestingly enough, less popular tools in the vibe-code sphere, such as Gemini-cli, Claude Code, or even the Google web-based Jules, do not seem to promote such an approach. Is that because there are people with more than intern-level software engineering practices making product decisions in those cases? I don't know, but I'd love to find out.
I'd like to believe every one of my readers knows who Jez Humble is, but if you don't, this is your opportunity to discover someone who's been highly influential in the Software Engineering/DevOps space for the past 1,5 decades. Surprisingly, he doesn't have a Wikipedia page, despite being mentioned in many. I guess the best way to get started to learn about Jez's work is via this page on the Berkeley University website.
My favorite variation of the razor goes as follows: “Never attribute to malice that which is adequately explained by incompetence.” Read more about it on this Wikipedia page.
The two hardest problems in software engineering are naming, cache invalidation, and off-by-one errors. See this page for a list of variations on this old piece of wisdom.
The fact that the accepted standard for evaluating LLMs on coding tasks is called SWE Bench, where SWE is the common acronym for Software Engineering, only includes coding tasks, is another piece of evidence of the general confusion around these topics.
“We don’t care about professional coders anymore,” Masad said. Source: this article on Semafor.
Interesting read! The bigger topic in here of defining software engineering is valuable. Simplest analogy is thinking a structural engineer just needs to know how to saw a piece of timber!
There's an argument to say that the whole prod database deletion event is karma. Rush in to building a product to make a quick buck without putting in the effort of figuring out how to do it properly, and you deserve to lose it just as easily.
It would be nice if there were more safeguards in place in these tools, but equally, there are likely times where those would annoy the people who do know what they're doing when they just want to ship a toy internal project to test something out... it's tough to find the balance.