cd /news/artificial-intelligence/why-you-shouldn-t-vibe-code-your-mon… · home topics artificial-intelligence article
[ARTICLE · art-101037] src=blog.appsignal.com ↗ pub= topic=artificial-intelligence verified=true sentiment=· neutral

Why You Shouldn't Vibe Code Your Monitoring Tool

AppSignal, a vendor of application performance monitoring tools, warns that vibe coding a monitoring pipeline is risky because the hard parts—scale, reliability, error grouping, and compliance—surface months later, often during the incident the tool was built to catch. The company argues that managed tools are cheaper, faster, and safer, citing issues like the need to monitor the monitor, handling terabytes of telemetry data, and GDPR compliance for storing PII.

read7 min views1 publishedAug 18, 2026
Why You Shouldn't Vibe Code Your Monitoring Tool
Image: Blog (auto-discovered)

TL;DRVibe coding makes a monitoring pipelinelookfinished in a single afternoon. The hard parts (scale, reliability, error grouping, compliance) show up months later, usually during the incident you’ve built the tool to catch. For most teams, a managed tool is the cheaper, faster, and safer choice, not because monitoring is hard to start with, but because it is hard to maintain.

Vibe coding made building software feel almost too accessible. You describe what you want, an AI assistant scaffolds it, and a few hours later, something is running. So, it was only a matter of time before developers started asking the obvious question: why should I pay for a monitoring tool when I can just build my own? In all fairness, the DIY instinct is a healthy one. But monitoring is one of the last corners you’d want to cut.

Now, full disclosure, AppSignal does sell an application performance monitoring (APM) tool, so of course we’d rather you didn’t roll your own (read the rest with that bias in mind 😅). However, the reasons below are the same arguments a senior engineer with nothing to sell would give you.

An Afternoon Project That Looks Done

In your head, it’s pretty simple:

  • Spin up
[Kafka](https://kafka.apache.org/)for event streaming. - Pipe metrics into
[ClickHouse](https://clickhouse.com/)for time-series storage. - Wire up a
[Grafana](https://grafana.com/)dashboard. - Add a webhook for alerts.
  • Total cost: a VPS and an afternoon with

Claude. And, by god, it works. On day one, with your ten test events, it works beautifully. ✨

That’s the common trap, and it even has a name: the Dunning-Kruger effect. Described by psychologists Justin Kruger and David Dunning in 1999, it refers to our tendency to overestimate our competence in something we’ve only just started.

Vibe coding just adds fuel to that fire. The AI hands you a convincing result before you’re capable of understanding what it has left out. You’ll likely be able to whip up some sort of monitoring tool, but the dangerous part is how quickly it will convince you there’s nothing left to tweak.

What Breaks Later

This kind of approach comes with its own set of issues. For starters, your monitoring tool now needs monitoring. In fact, it’s a production dependency. When the tool goes down, you lose visibility into everything else, often at the exact moment you need it most. So now you need a second system to watch the first one, which raises the obvious question: who monitors the monitor?

Then there’s the sheer volume of data. Telemetry is one of the highest-throughput data types you will ever handle. Millions of events per hour quickly become terabytes per month. ClickHouse needs tuning. Kafka needs partition management. Retention, rotation, and compression are all your problem now. Before you start, ask yourself whether you really want to process all of that on your own.

And finally, every feature is its own product. Error grouping and deduplication. Stack-trace parsing across languages. Anomaly detection, which needs historical baselines and statistical models just to answer "Is this response time normal?". Deploy correlation. Alerting with escalation and on-call rotation. Host agents for CPU, memory, and disk. None of these is a small feat.

The Part Everyone Forgets: Security & Compliance

This is where the real liability starts to show, and it’s also what AI-generated code is the worst at.

Your monitoring pipeline ingests sensitive data, from request payloads to user IDs, IP addresses, and often personally identifiable information (PII). The General Data Protection Regulation (GDPR) requires you to know what you store, where, and for how long, and to delete it on request. AI-generated code, on the other hand, tends to log everything by default, with very little thought regarding what it is that it’s logging.

The track record isn’t really reassuring. A 2025 Veracode study found that roughly 45% of AI-generated code introduced a vulnerability from the Open Worldwide Application Security Project (OWASP) Top 10.

And it doesn’t stop there. When researchers scanned thousands of publicly reachable vibe-coded apps, they found more than 2,000 high-impact vulnerabilities, hundreds of exposed secrets, and 175 cases of leaked personal data, including medical and bank details. Woohoo!

In July 2025, an AI coding agent deleted a live production database during a code freeze, wiped records for more than 1,200 companies, and then generated thousands of fake users to paper over the cracks.

And if you want to read something like this over a coffee, there are a lot more similar incidents.

The Cost of “Free”

The “free” monitoring tool is rarely free. Here’s what the actual bill looks like:

Cost Why
Infra Instances for Kafka, ClickHouse, Grafana, and alerting, scaling with your data volume
Maintenance Upgrades, patches, capacity planning, and debugging when it breaks, forever
Opportunity Every hour on your monitoring pipeline is an hour not spent on your product
Incident risk When it fails during an outage, you need to debug two systems at once
Compliance GDPR audits, retention policies, and PII scrubbing, all on you
Tokens If AI has built it, you’ve paid for tokens to create a liability

A managed tool turns that whole column into one predictable line item. And when something breaks on their side, an entire team is on it, not one developer splitting their attention between multiple fires in the middle of an incident.

“But Doesn’t Monitoring Slow You Down?”

This is the assumption underneath the whole build-your-own urge: that monitoring is a tax on shipping. It’s quite the opposite, actually. Monitoring is what lets you ship fast AND safely, because it tells you within minutes when a deploy has made things worse.

The setup cost people imagine is also outdated. A managed APM installs in about five minutes, not days. With AppSignal's Model Context Protocol (MCP) server, your AI assistant can do the install for you and then query production errors, traces, and deploys using plain English. The free tier covers a real baseline at no cost.

As you can see, the math behind build-your-own approach ("It’s free, and I control it!") quickly falls apart.

Where Building Your Own Does Make Sense

I gotta be fair, though, there are situations when in-house monitoring could be the right call and the own-your-infrastructure movement may seem reasonable. Think 37signals leaving the cloud; at that scale and with that team, it works.

Basically, self-built monitoring makes sense when:

  • You have a dedicated platform or site reliability engineering (SRE) team with monitoring expertise.
  • You have compliance requirements that no SaaS tool can meet.
  • You are at a scale where SaaS pricing genuinely becomes prohibitive.
  • Monitoring is your product.

Most teams don’t fall into any of these categories, though. They generally consist of two to ten developers shipping a product.

Spend Your Tokens on Your Product

Vibe coding makes a monitoring tool look deceptively easy to build. However, it does nothing to make the tool easier to run, secure, or keep compliant. The costs are real, and a tool that can crash during the incident when you need it most just puts you at an unnecessary risk.

Your job is to build your product. Let a monitoring tool deal with the monitoring. AppSignal installs in about five minutes (your AI assistant can even do it for you), the free tier lets you get started at no cost, and all your data stays in the EU. 😁

Try it for free, no strings attached, and put your tokens toward something only you can build.

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!

Find out more

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!

Discover AppSignal

── more in #artificial-intelligence 4 stories · sorted by recency
── more on @appsignal 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/why-you-shouldn-t-vi…] indexed:0 read:7min 2026-08-18 ·