Like it or not, vibe coding is here to stay. It’s too easy to just go away. Maybe if the per token cost rises too much at some point that it becomes cheaper to hire a junior… But until then, you’d better get used to it.
For now, tools like Cursor, Copilot, and Claude let developers (and plenty of non-devs) ship full-stack apps faster than a junior is able to completely grasp the concept of the app they’re working on. And that’s pretty neat. But the problem is that speed doesn’t necessarily mean quality. AI-generated code works until it doesn’t, and once it breaks, you are left staring at a production incident in a codebase you don’t fully understand.
Monitoring has always been important, but with AI code, it has become essential.
TL;DR AI-generated code can reach production fast, but it carries a unique set of risks that the person in charge of prompting cannot really anticipate, such as aggressive caching, memory bloat, silent failures, security overhead, and more. Monitoring, therefore, becomes the safety net for the parts of the stack you didn’t write and don’t fully own.
New Full-Stack Developer Problem AI (or LLMs, to be precise) has turned frontend developers into full-stackers overnight and vice versa. Someone who’s great at frontend can now ship a Rails API, and a designer can deploy a Django backend. But shipping code and understanding code are two entirely different things.
While writing backend code for years, you’ve been building a mental model of where things could go wrong. But when AI does that work for you, you do not have this knowledge to fall back on. All you’ve got is a working app and a gap where that model should be. This gap is exactly where monitoring lies. Of course, monitoring can’t replace the understanding you get from years of experience, but it does give you an extra set of eyes and a better comprehension of the parts of the stack you cannot fully reason about yet.
What AI Code Gets Wrong
What I'm about to mention is not theoretical and it’s not meant as some sort of an “anti-AI take”. These are simply the patterns that show up in production repeatedly:
Aggressive caching: AI loves cache very much, and that’s a fact. Caching is a safe and intentional optimization technique that works great, but it can also return stale or completely wrong data the moment anything changes. You won’t know until a user tells you, if they even realize the data is wrong in the first place. Oops.Unnecessary deps: AI installs libraries it’s comfortable with (for instance, the most prevalent in the training dataset), not the ones you really need. Every gem/package is another potential point of failure in the chain. Packages can break, conflict, or introduce a CVE. Code usually works, but the dependency tree can quickly turn into a Kinder Surprise. :)Memory bloat: Your daily LLM of choice really likes to produce objects that never get cleaned up. Those patterns look fine in dev, but they quietly eat up memory over hours in production. Man, RAM isn’t cheap. Make sure to keep an eye on it.No awareness of production reality: AI lives in a parallel universe from your production. The underlying model has zero concept of your production environment: no time zones, no real traffic patterns, no idea that an endpoint gets slaughtered on Mondays.Non-existent security: One of the most expensive mistakes an AI can make is fiddling with sensitive data. Those can end up in logs, PII can get serialized in a part where it shouldn’t be, and GDPR-sensitive data can start flowing in ways that are difficult to audit. AI doesn’t inherently understand your security policies, so you have to be explicit and actually plan out how to work in such circumstances.
None of the above means AI is bad at coding. It just means that it’s unaware of the specific context it hasn’t been given.
Handwritten Code Is (Slightly) Safer When you write code yourself, you are building a mental model around it as you go. Since you’re actively thinking while writing code, you already roughly know where it’s likely to fail. In short, when something breaks, you have a starting point.
The person who has prompted the AI is just looking at a black box of code. They can deploy it, but do they really understand what they’ve deployed?
Again, this is not an argument against AI usage. This is an argument for being honest about what you are taking on when you ship code you haven’t completely written.
Monitoring AI-Generated Code
Given you are deploying AI-generated code, you may be wondering, “What do I monitor?”
| What to Monitor | Why to Monitor |
|---|---|
| AI-generated code fails silently more often than you'd expect. You need to know what happened before your users do. | |
| Bloated code, unnecessary queries, and N+1 problems do not really show up locally. | |
| Memory bloat from AI-generated code compounds over time. That code likes to eat RAM, and RAM is not cheap, pals. | |
| AI writes queries that are sometimes inefficient at scale. | |
| Catch what error tracking misses + audit for sensitive data leakage. | |
| An app will go down sometimes, AI or not. |
Host metrics are particularly important when you are self-hosting on Coolify, Hetzner, or a bare VPS, or if you’ve picked a server size without a clear sense of your app's resource footprint.
Monitoring Is Easy
You may think that setting up monitoring is time-consuming and difficult. Nope, one-liner installs are available, and you’ll be looking at charts in <5 mins. You can even point Cursor at the AppSignal docs and tell it to install and configure the integration. It works surprisingly well. You can use the same AI that writes your code to set up observability for you.
At this point, there’s no plausible excuse for shipping to production without monitoring. The effort required for activation is too low.
If you prefer to do it yourself, AppSignal's setup takes under five minutes for Ruby, Python, Node.js, Elixir, and PHP. Auto-instrumentation handles most of what you need out of the box: errors, performance, host metrics, all without manual configuration. The Cost of Not Monitoring
Token bills are already noticeable in accounting, and this becomes especially clear in heavy agentic workflows. Those agents do be eating thousands of dollars for a few hours of orchestrated, multi-agent work.
Now, add a production incident on top of that. The cost of monitoring is predictable, like insurance. The cost of not monitoring isn’t, and is as reckless as driving uninsured.
Beyond the financial side of things, regulations do not care if a human or AI wrote the code. EU's GDPR will slap you with a fine regardless of who leaked PII.
At this point, some developers are tempted to reach for the "I will build my own monitoring" option. Please don’t. The data pipeline alone (collection, storage, retention, alerting) is a serious engineering project. You don’t want to maintain that alongside the app it’s supposed to be watching.
We have a whole build-vs-buy argument here, and the short version is: use the time you’ve saved vibe coding on something that actually moves your product forward.
Next Steps
✨ Artificial intelligence ✨ makes building and shipping easier. It also makes it easier to mess up your security, compliance, and reputation. Simple to build is not the same as simple to keep running in production.
Monitoring is the missing layer between shipping fast and shipping responsibly. Set up AppSignal in under five minutes. Your AI assistant can help you do it while you are already in the editor.
Frequently Asked Questions (FAQ) Does AppSignal work with apps built entirely by AI agents?
Yes. AppSignal integrates at the framework level (Rails, Django, Express, Laravel). We will not judge you based on who wrote the code, and instrumentation does not see the difference.
What is the single most important thing to monitor in an AI-generated app?
Error tracking with alerting. AI-generated code fails silently more often than hand-written code because it handles error cases generically rather than with domain-specific logic.
My AI-generated app is small and low-traffic. Do I still need monitoring?
Yes, arguably more so. High-traffic apps get organic feedback from user reports and visible performance degradation. Small, low-traffic apps can have bugs running silently for weeks.
Can I use MCP with AppSignal?
Yes, 100%. Once AppSignal is collecting data from your app, the MCP server lets your AI agent query that data directly from your editor.
Published
Wondering what you can do next? #
Try out AppSignal with a 30-day free trial.Reach out to our support team with any feedback or questions.
- Share this article on social media
Dejan Lukić #
Our guest author Dejan is an electronics and backend engineer, who is pursuing entrepreneurship with SaaS and service-based agencies and is passionate about content creation.
All articles by Dejan Lukić Become our next author!
AppSignal monitors your apps #
AppSignal provides insights for Ruby, Rails, Elixir, Phoenix, Node.js, Express and many other frameworks and libraries. We are located in beautiful Amsterdam. We love stroopwafels. If you do too, let us know. We might send you some!