Recently our team concluded in our peer-reviewed research that that code health determines AI-performance. The study "Code for Machines, Not Just Humans: Quantifying AI-Friendliness with Code Health Metrics" concluded that when agents operate on unhealthy code, the defect risk increases by 60% (at least).

It s was a large-scale study of 5,000 real programs using six different LLMs to refactor code while keeping all tests

passing.

Every bug I've shipped in a normal product got reported within a day. The AI ones don't. If a model returns something plausible and slightly wrong, people shrug, fix it themselves and move on, so you never hear about it. Your error rate looks healthy because it's only counting the failures loud enough to complain about.

Ours in Zeplik was the model picker swapping mid conversation without saying so. Nobody filed a ticket for it. People assumed the AI was just having an off day, which is a story users will happily tell themselves forever.

The fix felt wrong to ship. We made the picker say out loud that it swapped and why, which is basically admitting we changed something behind your back. Shipped it three weeks ago and I'd do it again.

If you're vibecoding an AI product right now, the thing worth instrumenting isn't crashes. It's what people quietly edit after you've told them the output is done.

Hey there,

What are the biggest issues/problems you currently have with building and Testing APIs with existing tools like Postman, Insomnia etc?

I ve been using VS Code with ChatGPT Codex for development, but I keep running into a frustrating workflow bottleneck: when I ask the agent to edit or fix a tiny section of a file, it often insists on rewriting the entire codebase or file from scratch.

This burns context windows, introduces random side-effect bugs, and wastes a ton of time reviewing diffs.

For those using AI coding assistants in VS Code, how are you isolating issues so the agent strictly operates on the target lines? Are there specific extensions, prompt patterns, or scoping tools you rely on to keep the edits surgical?

Everything I've built fast worked perfectly for me and fell over for the third person who touched it. Not because the code was worse than I thought. Because I'd quietly learned the path through it. I know which field to fill first, which button not to press until the save finishes, which page to reload when it looks stuck. None of that is written down and none of it is in the product.

The test I run now is to hand it over and say nothing. No walkthrough, no "just click here first". Watch where they stop.

built an on-call tracker for my team last week. maybe 3 hours. then spent the rest of the day trying to figure out how to let 6 specific people see it and nobody else

ended up with a shared password in our team chat. it works. I hate it

writing a real login system for six users feels stupid. but the shared password thing also feels stupid. what do you guys actually do

Developing with AI agents and orchestrating multiple sub-agents is widely celebrated as the next evolutionary leap in software engineering. But is it really a leap forward?

I see true evolution in qualitative shifts approaches that deliver fundamentally better outcomes. An AI agent is essentially the same underlying LLM with the exact same core constraints. What actually changes if multiple models write code in parallel?

At best, we get raw speed by splitting a project into subsystems where each agent operates in its own narrow vector space. But in real-world production, subsystems are never truly isolated. Agents, just like base models, cannot hold a holistic mental model of the entire architecture, no matter how detailed your system prompts are. This inevitably leads to silent bugs, broken dependencies, and architectural drift.

When an agent works across multiple files, it suffers from rapid context degradation. Each successive edit accumulates dirty context from past steps. In a complex system, the probability of a critical failure compounds exponentially. Unsupervised autonomous coding quickly devolves into endless audit loops, explosive generation spikes, and massive token burn. Development costs can easily 10x without strict human supervision. What feels fast initially creates a mountain of hidden debt.

A commenter said the core of what I'm building, working out what a change will break before it happens, is impossible. He never explained, and never came back.

It bugged me enough that I went looking for what he might have meant. The strongest version is Rice's theorem: you can't write a program that reliably works out the behaviour of arbitrary programs. Applied to me, you can't look at software and compute what a change breaks. Not hard. Impossible. Settled since 1953.

Everyone talks about which tool they're using right now. Fewer people talk about the tool they left and why.

I switched from Bolt to Cursor halfway through a project a few months ago, not because of a big feature gap, but because of something small: Bolt kept losing context after a few file edits and I'd have to re-explain the whole architecture every session. It wasn't a benchmark loss, it was a patience loss.

That's the kind of thing that never shows up in comparison posts. Nobody writes "Tool A has 12% worse long-context memory," they just quietly open a new tab and start using Tool B.

So, curious about real switches, not hypotheticals: