DEV Community: Mayank rajput

We read every message our first six users sent. The worst bug was our own progress report.

Mayank rajput — Thu, 27 Aug 2026 15:02:06 +0000

We build a cloud AI coding agent. Over 21 days, six real people signed up and used it.

Six. Not a launch, not traction, not a growth story — six people, small enough that we could sit down and read every message they ever sent it. So we did.

Here is everything that broke, including the one that was our fault in a way we didn't expect.

1. "No file changes were made in this turn."

That string appears three times across six users. One of them typed Continue, waited, and got it back. It was the last message of their session. They didn't return.

Our first assumption was that the agent had stalled — a hung tool call, a dead model, something obvious. It hadn't.

The message comes from a fallback. When the model returns no prose, we describe what it did instead:

const summary = fullResponse || this.describeTurnActions(turnActions);

And describeTurnActions counted this:

if (type === "write_file" || type === "edit_file") {
  files.push(action.path);
} else if (type === "run_command") {
  commands++;
}

Writes and commands. That is the whole census.

Now the turn that ended that user's session: 117 seconds. 254,000 tokens. 8 file reads. 10 searches. The agent opened the codebase, searched it, read through it, and then stopped without editing anything.

Every one of those actions was invisible to the counter. So the product took two minutes of real work and reported it to a paying-attention human as nothing happened.

There were two separate bugs sitting inside one sentence:

the agent terminating a turn without acting, and
us being unable to tell that apart from a crash — including in our own logs.

We spent our first hour debugging (2) while believing it was (1).

2. 73 commands, 2 files

Another user's first turn produced 48 files and 41 commands — a real application skeleton. Then they typed continue. and got 2 files and 73 commands. Then again: 2 files, 59 commands.

Dozens of shell commands producing almost nothing. From the outside that reads as thrash, and it may well be.

But look at what I just told you about that turn. File counts and command counts. It is the same instrument as #1, and I do not yet know whether those 73 commands were flailing or were one long legitimate diagnosis. We are not currently equipped to tell the difference. That is the actual finding.

3. The token budget ended a build early

One user wrote a 518-character casual prompt — the kind of thing you type without thinking hard about it. The agent worked, hit its token budget partway through, and wrote an honest handoff explaining where it had got to.

That is the correct behaviour, and I will take it over a confident lie every time. It is still a build that stopped short of a working app, and the user experienced it as the product giving up.

4. "I can't see a thing in the preview"

Same user, very next message. Their words, not our paraphrase.

The cause: scaffolded Vite apps were going out without a base set, so behind our preview proxy every asset resolved to a path that did not exist. A blank white page, underneath a promise of a live preview.

That one is fixed and deployed. It had also been sitting fixed in a branch for a while before anyone noticed it was not in production, which is its own small lesson.

5. The one that redeems the list

One user wrote a genuinely principal-architect-grade PRD, ran it, and got 36 files — prisma schema, auth, API routes, middleware. Then they closed the tab.

They came back 12.8 hours later and kept building.

No onboarding sequence. No email. No nudge. They came back the next day because the thing they had started was worth continuing. At six users that is not a statistic, but it is the single most encouraging thing in the data.

And in that same session the agent hit a Next.js 16 async-params breakage across three route handlers, diagnosed it, and fixed all three unprompted. Nobody asked it to.

The pattern underneath

Twice in one week we looked at a bad number, concluded the model was underperforming, and were wrong — because the thing doing the counting was broken.

The first is the one above: reads and searches were not in the census, so work looked like idleness.

The second was our evaluation harness. Fixtures were scoring high on trajectory quality while failing nearly all of their acceptance checks. Two measurements of the same run, disagreeing wildly. We spent real money iterating on the agent before anyone asked the obvious question — and the acceptance check was the thing that was wrong. The agent had been fine.

Both times, the fault was in the ruler and we went looking in the thing being measured.

Check what your instrument counts before you conclude the model is bad at its job. It costs about twenty minutes. We skipped it twice.

What we changed

The empty-turn message now knows the difference between "investigated and stopped" and "genuinely nothing":

if (files.length === 0 && commands === 0) {
  if (reads > 0 || searches > 0) {
    return `**I looked, but I did not change anything this turn.** I ${looked} ` +
      `and stopped without editing — usually that means I could not work out ` +
      `the next step on my own.\n\n` +
      `Tell me what to do next and I will act on it.`;
  }
  return `**That turn produced nothing — that is a fault on our side, not ` +
    `something you did wrong.**\n\nSend your last message again.`;
}

That is live in production as of this week — I checked the running build rather than the branch, and the old string is gone from the bundle.

Two things worth saying about that snippet.

One: it does not fix the agent stopping early. It fixes us lying about it. Those are different jobs, and conflating them is how you end up shipping a nicer error message and calling the bug closed.

Two: read the second branch again. When it really is our fault, the product says so, in those words. A user who is told "no file changes were made" concludes they prompted it wrong. That is the worst available outcome — they blame themselves, and they leave.

What we deliberately did not publish

Two of those six prompts are 15,000-character specifications for named products. Those are somebody's business, written into a text box they reasonably assumed was private. They would have made a far more interesting post than this one.

There are no names, no product concepts and no prompt text anywhere above, and there will not be unless the person says yes.

If you would rather watch the agent working than read about it failing, there is an uncut run here: https://youtu.be/2sR4H1q9QCQ — the interesting part is at 1:12, where its own build check fails and it goes and fixes the config itself.

My AI agent wasn't dumb — my guardrail was lying to it

Mayank rajput — Sun, 23 Aug 2026 16:37:08 +0000

I record demos of my own AI app builder. Last week one of them made the agent look incompetent, and chasing why turned into a lesson about diagnosing agents in general.

What it looked like

The agent wrote a file. Then it wrote the same file again. Then it said this:

"the writes report success but the files aren't there"

"Many files aren't persisting despite success reports — likely a parallel-write race condition. Let me write them one at a time"

And then it did exactly that, slowly, for most of the run — defending against a problem that did not exist.

My first theory, which was wrong

NoCoder has an approval gate: in review mode the agent stops before each file write and waits for you to approve the diff. My immediate theory was that gated writes were being queued — so the agent's next read hit the real filesystem, found nothing, and panicked.

It explains the symptom perfectly. It is also completely wrong.

The gate is blocking, not queueing. At the call site:

if (this.approvalGate.shouldGate(sessionId, name, args)) {
  const decision = await this.requestChangeApproval(sessionId, name, args, podName);
  if (!decision.allow) { /* returns a normal failed ToolResult */ }
}
// only now does the write reach the pod

The comment above it says the quiet part out loud: the gate sits before anything touches the pod, so the diff shown is exactly what gets written and a rejected change never reaches disk. The agent is parked on that await the entire time a request is pending. There is no window in which it can write, move on, and read a file that isn't there yet.

I found this by reading the call site. I would not have found it by reading the transcript, because the transcript supported my wrong theory beautifully.

The actual cause

A loop guard I wrote.

If the agent issues a second write to a path it already wrote, the guard assumes the model is spinning, skips the write, and feeds back: "You already wrote X. Do NOT rewrite it."

That is the right behaviour when the file is sitting on disk. It is the wrong behaviour when the file is gone — and it is often gone, because the agent's own cleanup of node_modules, a config regeneration, or a scaffold step removed it between the two attempts.

So the agent was told it had already written a file that did not exist. It checked. It found nothing. It concluded the workspace was broken — which, from where it was standing, was a reasonable inference. Everything downstream was careful reasoning from a false premise handed to it by my own guardrail.

No data was ever lost, incidentally. Every claimed write was on disk once approvals landed.

The fix

Make the guard check instead of assume. It now probes the workspace for the file and only skips the rewrite when the file is genuinely still present.

What I actually took from this

Two things.

Guardrails are part of the model's world. We spend a lot of effort on prompts and tools and comparatively little on what our safety rails say when they fire. This one lied — confidently, in the imperative — and the agent believed it, because why wouldn't it. An agent can only be as sane as the feedback it is given.

A transcript is evidence of symptoms, not of causes. The agent's own explanation ("parallel-write race condition") was wrong, my first explanation was wrong, and both were wrong in the same direction: blaming the layer we could see instead of the one we had to go read. If you are debugging an agent and your theory came from its output, go read the call site before you ship a fix.

If you want to watch the run this came from, it is here: https://youtu.be/2sR4H1q9QCQ — the model catching a different mistake of its own, a missing Tailwind plugin, is the more flattering part.

NoCoder is what I am building: an AI app builder that proposes every change as a diff you approve before it touches your code. https://nocoder.codes/?utm_source=devto&utm_campaign=guardrail

I made our AI agent ask permission before writing a single file

Mayank rajput — Sat, 22 Aug 2026 11:54:13 +0000

Most AI app builders write files and tell you afterwards. You send a prompt, the agent works, and some time later you have a diff to audit — or worse, you don't, and you find out what changed when something breaks.

We built ours the other way round: the agent proposes a file, and then it stops.

Here is a full run, one sentence in to a working landing page out:

What the approval gate actually does

Every write_file and edit_file is intercepted before it touches disk. You get the path, the diff, and three choices: accept it, reject it, or approve the rest of the run so it stops asking.

The escape hatch matters as much as the gate. A review step you cannot turn off is a review step people click through without reading — so "Approve the rest" is a first-class button, not something you find by giving up.

The part I did not script

Around 1:12 in the video, the agent's own build check fails. It reads vite.config.ts, notices the plugins array is [react()] with no Tailwind plugin, runs a dry-run edit to confirm the string it wants to change exists, applies the fix, and then notes that Vite config changes are not picked up by HMR — so it restarts the dev server and verifies the CSS is actually being served.

That is the real trajectory, not a demo edit. It is also the strongest argument for the gate: you can watch the reasoning that produced each change.

Why we charge for the sandbox and not the tokens

The agent runs in a real Kubernetes workspace you can open in VS Code. Bring your own API key — or point it at a local Ollama — and the tokens cost you nothing, because they never go through our provider account.

What you pay for is the machine it runs on. No credits, no overage, and a failed build does not spend one of your runs.

What comes out is an ordinary Vite or Next project with a normal package.json. No proprietary format, nothing that needs us to keep running.

Try it

Free tier, no credit card: https://nocoder.codes/?utm_source=devto&utm_campaign=demo

If you try it and the agent does something dumb, I would genuinely like to see the trajectory — that is the fastest way we fix things.

We shipped the feature we are named for. It was off by default.

Mayank rajput — Tue, 18 Aug 2026 12:30:41 +0000

96% of developers don't fully trust AI-generated code. Only 48% of them verify it before it ships (Sonar, 2026).

That gap is the reason our product exists: you review every AI change as a diff before it touches your project.

Last week I found our review gate was off by default.

The feature worked. Nobody met it.

The mechanism was never the problem. The agent is intercepted at the tool boundary, before anything reaches disk. You get a real unified diff, and the run waits. There's no timeout, because a user who walked away hasn't approved anything.

There is also an "Approve the rest" button, deliberately. A cold build writes dozens of files, and asking dozens of times produces rubber-stamping — which defeats the entire point of a gate.

All of that shipped and worked. And reviewChanges defaulted to false.

So a new user got the same write-without-asking behaviour as every prompt-to-app tool we describe as the problem. We had quietly joined the 52% who do not verify.

I found it the only way this class of bug can be found: by running a real build and watching the agent create a file in the workspace without asking me a single question.

Two things underneath were worse

The diff you approved was not always the diff that got written

The gate ran on the original tool arguments. Pre-write hooks — which can rewrite file content — were applied after the user answered.

So if a hook rewrote content, you approved one change and a different one reached disk. On a review feature, that is not a bug, it is a lie.

The order is now: safety hooks → hook modifications → user review of the final arguments → write.

One retry ended the whole run

When a user rejects a change, models sometimes re-propose it. We cap that:

const MAX_REPEATS = 2; // repeats allowed before the turn is ended outright

The check read seen + 1 >= MAX_REPEATS, and seen is already the count of previous rejections. So the first repeat satisfied it, and the orchestrator turns that into a full run abort.

One innocuous retry killed everything the user was doing.

The existing test asserted that the third request stopped the run. It never asserted the second one did not.

What I take from it

A feature flag defaulting to off is indistinguishable from never having built the feature. Your tests pass either way. Your changelog says you shipped it either way. Nothing in your pipeline knows the difference between "built" and "reachable".

61% of developers say AI produces code that looks correct but is not — silent failures. A review gate that quietly defaults to off is exactly that failure mode, turned on your own product.

The fix was one boolean. Finding it took running the thing like a user and watching what it actually did.

Originally published at nocoder.codes.

Bolt.new and Replit Agent alternatives that let you review the code before it ships

Mayank rajput — Sun, 09 Aug 2026 17:29:33 +0000

Cross-posted from nocoder.codes/blog/bolt-new-alternatives — see the canonical URL for the latest version.

People leave Bolt.new and Replit Agent for the same reason they leave Lovable: the demo is fast, but the code is a black box you can't easily trust, extend, or own.

Judge alternatives on control, not just speed: reviewable diffs, rollback, a real workspace, code ownership, full-stack, and predictable pricing.

NoCoder is a diff-first alternative — every change is a per-file diff you approve, in a real code workspace, with code you own and can run anywhere.

Why people look beyond Bolt.new and Replit Agent

Both tools optimize for one thing: getting from idea to running app in as few steps as possible. For a throwaway demo it's hard to beat. The friction shows up afterward, when the app has to survive contact with reality:

Black-box edits. The agent applies changes automatically. The preview works, but you can't see what changed, why, or whether it rewrote something that worked before.
Code that's hard to own or extend. When the app is generated behind the scenes, handing it to a developer — or picking it up yourself in three months — gets painful. You're reverse-engineering your own app.
Replit's path to production is the cloud IDE. Ties your app and your deploy to one platform. If you want to own the stack, the agent isn't built for that.
Unpredictable cost as you iterate. Each "just fix this one thing" round-trip can burn more credits than you expect.

What to look for in a Bolt.new / Replit Agent alternative

Judge alternatives on what happens after the demo, not just generation speed:

Does it show every change as a reviewable diff before applying it — or does it edit for you automatically?
Can you roll back a bad change to a clean checkpoint?
Is there a real code workspace (full editor + live preview) where you can run, edit, and verify?
Do you own and can you export the code, or is it locked to the platform?
Can it do full-stack (backend, auth, database) — not just a frontend demo?
Is pricing predictable, with a usable free path?

The case for a diff-review builder

The most important difference between alternatives is not which one writes prettier React. It's whether you stay in control of what ships. A diff-first builder proposes each change as a per-file diff and applies nothing until you accept it. You keep the speed of AI generation without inheriting code you've never actually looked at.

The honest trade-off

Pure prompt-to-app tools will usually feel faster for a throwaway demo — that's what they're built for. A diff-review workflow adds a short review beat, and that beat is exactly what makes the output something you can trust, extend, and maintain. If your app is disposable, the fastest demo wins. If your app has to live, control wins.

Where NoCoder fits

NoCoder is built around reviewable diffs and a real code workspace. Every change is shown as a per-file diff you approve; the app runs in a full code-server (VS Code in the browser) environment with a live preview; and you can roll back to any checkpoint. The code is yours to read, extend, and run anywhere.

For a head-to-head on speed, ownership, and control:

Or start free on NoCoder and review your first diff.

FAQ

What is the best Bolt.new alternative for developers?

If you care about reading and owning the code, choose an alternative that gives you a real workspace and shows changes as reviewable diffs instead of applying them automatically.

Is there a Replit Agent alternative where I own the code?

Yes. NoCoder is built around a diff-first workflow: the agent proposes every change as a per-file diff, nothing is written until you approve it, and the code is yours to export and run anywhere — not locked to a hosted IDE.

How is a diff-review builder different from Bolt.new or Replit Agent?

Bolt.new and Replit Agent optimize for getting a running app as fast as possible and apply edits automatically. A diff-review builder adds a short review beat — you see each change before it lands and can revert to a checkpoint.

Canonical URL: https://nocoder.codes/blog/bolt-new-alternatives

What Our AI Agent Still Can't Do

Mayank rajput — Sat, 08 Aug 2026 14:11:06 +0000

Most AI tools only tell you what they're good at. That's how you end up discovering the gaps in production. So here's the other half: where our AI agent still misses, specifically, and what we're doing about each one.

What it's genuinely good at

Targeted bug-fixing (~85–90%) — given real broken code, it produces a fix that compiles clean and makes the specific change.
Simple full-stack builds — it scaffolds working SPAs reliably.
Prompt → full-stack app → live deploy with a real database — validated end to end.

Where it still misses

From our own correctness-gated evals, the honest gaps:

Complex full-stack scaffolding. On a notes app with auth, it built the database schema but missed declaring the bcrypt / jsonwebtoken dependencies — the kind of gap that compiles in isolation but breaks the build.
Run-to-run consistency. A landing-page fixture's dev-server check passed on one run and failed on another. Non-determinism is real, and we measure it instead of hiding it.
Small correctness slips. Using React.Fragment without importing it; a to-do app that skipped localStorage persistence. Individually minor — exactly the sort of thing you'd want to catch in a diff review, not in production.
Read-only tasks. On a task that only asked it to find and report something, it wrote files instead of answering. Knowing when not to act is its own skill.

What we do about it

Every genuine failure feeds a closed self-improvement loop: the run is analyzed, a prompt change is proposed, and the candidate is validated against the same correctness gate — with a holdout set guarding against regressions — before anything reaches production. Some of the misses above already have fixes in flight; some don't yet. We publish both states.

Why publish this at all

Because you're going to hit these limits either way — the only question is whether you find out from us now or from a broken build later. It's also why NoCoder puts diff review at the center: the agent isn't perfect, so you stay in the loop. Every change is a per-file diff you approve before it applies.

The short version: Our agent is strong at bug-fixing (~85–90%) and simple full-stack builds, and weaker on complex scaffolding, consistency, and a few specific tasks (missed auth deps, a skipped localStorage step, a Fragment import, a read-only find task). We fix what we can via a validated self-improvement loop and publish the rest. See how we benchmark or try NoCoder free.

This post originally appeared on the NoCoder blog. NoCoder is an AI full-stack app builder that shows every change as a diff you approve before it ships — build at AI speed, ship only what you've reviewed. Free to start on free models.