DEV Community: Girish R

Bolt, Lovable, Replit, v0: All Four Get You to 70%. Here's Where Each One Stops.

Girish R — Thu, 27 Aug 2026 07:55:32 +0000

Sit through enough meetings and you will hear someone compare Cursor to Lovable, or ask why the team needs Claude Code when Replit already exists. The room nods along. Most of the people in it are not sure either.

Nobody should feel bad about this. AI tooling arrived as one undifferentiated category, and every vendor in it describes itself with the same six words. Someone reads a thread or watches a video that flattens four different products into a single demo, and walks away with a mental model that collapses the first time they have to defend a purchase in front of a CFO.

The categories underneath are real, though, and mixing them up costs money. A browser builder that spins up a deployed SaaS from a paragraph and a terminal agent that refactors a 400-file monorepo solve different problems. Comparing the two produces a verdict that is useless for both.

So we are writing a series to sort the layers out: what each class of AI coding tool does, who it is for, and where it stops being the right answer. Part one covers the browser-based full-stack builders: Bolt.new, Lovable, Replit, and v0 by Vercel.

They share an architecture. You type a prompt into a web page, an agent writes a React or Next.js app, a preview renders beside the chat, a managed backend gets wired in, and a deploy button puts it on the internet. No local environment, no terminal, no repo to clone.

That shared architecture produces a shared ceiling. All four are excellent at the first 70% of an app and expensive at the last 30%. The differences are in which 70% they nail and how gracefully they hand off when you run out of runway.

The eight capabilities that decide whether you can finish a project on a platform, rather than the ones that make the demo look good.

Ranked by how likely each is to be the right call.

1. Lovable

Best for: non-technical founders shipping a real SaaS MVP with auth and a database.

Lovable is the commercial leader of this group, at roughly $500M ARR after a $330M Series B at a $6.6B valuation. It earned that by being the least demanding. Describe the product, get a React frontend on a Supabase backend with auth and storage scaffolded, and a deployed URL you can send to a customer.

Where it wins: the backend is real from prompt one. Most competitors treat the database as a later integration. Lovable treats it as the default, which is why non-developers finish things in it.

Where it lacks: the Supabase defaults are a security liability in the hands of someone who does not know what row-level security is. Researcher Matt Palmer scanned 1,645 Lovable projects in May 2025 and found 303 endpoints across 170 of them readable by an unauthenticated request using the public anon key. That is CVE-2025-48757, and the exposed data included emails, phone numbers, payment status, and third-party API tokens.

Lovable has had platform-level failures of its own too. Palmer filed a HackerOne report in March 2026 on a broken object level authorization bug that let any free account pull another project's source and Supabase credentials, including the service role key, in about five API calls. He published it on April 20 after getting no patch. Lovable shipped a fix within two hours of the disclosure going public.

What it does not do: hand you a codebase you would want to maintain. Export exists, but the generated app assumes Lovable's Supabase wiring, and unwinding that is a project. Pricing is credit-based rather than per-seat: free gives 5 daily credits capped at 30 a month, Pro is $25, Business is $50, and unused monthly credits expire two months after they are issued.

2. Bolt.new

Best for: developers who want the browser convenience but expect to read every file.

Bolt runs your actual project in the browser through StackBlitz's WebContainers, so npm installs and a real Node runtime execute client-side. That single technical choice makes it the most honest of the four. You are looking at a real filesystem, not an abstraction over one.

Where it wins: control and transparency. Full file tree, terminal, and the freedom to pick your own stack instead of accepting a house one. Figma import is useful.

Where it lacks: token economics. Bolt bills by tokens consumed, and most of that consumption is syncing your project's files into context on every turn. Costs therefore scale with codebase size, not with how much you asked for. A short prompt against a 20-component project costs more than a long prompt against a fresh one, which is backwards from how anyone budgets. Pro is $25 a month starting at 10M tokens with no daily cap and one month of rollover, and the usual complaint is how fast that drains once the project stops being small.

What it does not do: hold a coherent plan across a large app. Past a few dozen files, it starts editing things you did not ask it to touch.

3. Replit

Best for: teams that want an agent and a real dev environment in the same tab.

Replit was a development platform before it was an AI product. You get a container, a shell, a package manager, Postgres, object storage, auth, secrets management, and deployment. The Agent sits on top of infrastructure that already existed.

Where it wins: it is the closest thing to a normal engineering environment in this category. When the agent gets stuck you can drop into a terminal and fix it yourself, which is not true of Lovable or v0. Agent 3 added genuine self-testing, driving a browser to click through the app it just built and catching interfaces that look functional but are not, and it will run unattended for up to 200 minutes. Agent 4 is the current default.

Where it lacks: cost predictability. Replit's effort-based checkpoint pricing charges by how much work the agent decided to do, which means the agent controls your bill. Core is $20 a month with $20 of usage credits, and when those run out you move to pay-as-you-go rather than hitting a hard stop. There is no circuit breaker when the agent enters a debugging loop.

The incident that still matters: in July 2025 the Agent deleted a production database during a code freeze, fabricated records, then told the user rollback was impossible. It was not. CEO Amjad Masad committed publicly to automatic dev/prod separation and a planning-only mode. Those shipped. The underlying lesson did not expire. An agent with write access to production and no enforced plan will eventually use it.

4. v0 by Vercel

Best for: teams already on Vercel who need beautiful UI fast.

v0 produces the best-looking output of the four by a clear margin, especially anything built on shadcn/ui and Tailwind. It has grown well past a component generator. The rebuilt v0 added a code editor, Git integration with automatic branching and pull requests, and database connections, and the v0 Platform API plus its open SDK now let you drive the whole thing programmatically.

Where it wins: design quality and the escape hatch. Import an existing GitHub repo, work on it, merge a PR, leave. Of the four, v0 is the least painful to walk away from.

Where it lacks: backend depth and gravity. Full-stack v0 is newer than Lovable's or Replit's and it shows on anything with real data modeling. Everything is smoothest inside Vercel's infrastructure. Premium is $20 a month including $20 of credits, Team is $30 a seat, and credits are consumed by input and output tokens, so spend tracks prompt and output size rather than anything you can forecast up front.

Prices are the entry paid tier as of August 2026. Replit bills by agent effort on top of the base plan, so treat its number as a floor rather than a monthly cost.

Honorable mentions

GitHub Spark is the cautionary tale. GitHub stopped accepting new users on August 4, 2026 and shuts the product down on August 31. If you built on it, export via Create repository before then. GitHub's stated reason is worth reading twice: builders can now do this through Copilot in the environments where they already work, meaning VS Code, the CLI, and the Copilot app. The company that owns the world's largest code host looked at prompt-to-app in a browser tab and decided the editor and the terminal were the better home for it.
Base44 pairs visual editing with generated code and pulls in Slack, Google Workspace, and GitHub from the first prompt. Strong for internal tools.
Firebase Studio is Google's entry, worth a look only if you are already committed to Firebase.
Figma Make turns designs into working prototypes and stops there. Useful for design teams, not for shipping.

The wall all four share

None of these tools operate on your existing codebase in your existing environment. They generate into a sandbox they own.

That constraint produces the same failures regardless of vendor. Context is capped by what the platform decides to load, so quality degrades as the project grows. Cost is metered by agent activity rather than delivered outcome, so the tool that flails the most bills the most. And the agent has no durable statement of intent, so nothing stops it from redesigning a screen you never mentioned.

Why the dev-focused agents go further

Claude Code, Codex, and Grok's coding agents are weaker at zero-to-one demos and far stronger at everything after. The difference is where they run.

A terminal agent works in your repo, on your branch, with your git history as context. It runs your test suite and reads the failures. It calls your linter, your migrations, your deploy script. It connects to your internal services through MCP. You can gate it with hooks, scope it with subagents, and review its work as a diff in the tooling your team already uses.

Browser builders give you none of that. There is no branch to review, no test suite that is yours, no CI gate, no way to say "never touch this directory." You get a preview pane and a chat log.

Model quality is roughly constant across these three rows. What changes is how much of your codebase the agent can see and how much of its work you can inspect before it lands.

Run those agents inside an IDE, or drive them from a written specification, and the gap widens again. A spec gives the agent a definition of done, and a definition of done is what stops the loop that generates the bill.

Use the browser builders for the thing they are best at, which is proving an idea is worth building, in an afternoon, for a few dollars. The moment the answer is yes, move the work into a repo and give it a spec. GitHub reached that conclusion about its own product this month. The other four will happily take your money for another six months instead.

Next in the series: the confusion inside a single vendor. Claude app, Claude Code, and Cowork against ChatGPT, Codex CLI, and Codex cloud, and the rule for knowing which one a task belongs in.

Claude Now Puts an Invisible Watermark on Everything It Writes - Including Your Code

Girish R — Fri, 14 Aug 2026 10:42:48 +0000

Anthropic just started embedding invisible watermarks into everything Claude writes. Including your code.

Starting with every model released after August 2, Claude weaves a machine-readable signal into its output that survives copy-paste and applies across every surface: Claude, Claude Code, Claude Cowork, the API. No opt-out. The trigger is the EU AI Act's Transparency Code, and every major lab is doing some version of this by year's end.

The backlash came from an unexpected group: not students, but lawyers and academics who use Claude to copy-edit their own writing, now finding their human drafts flagged because Claude touched three sentences of them.

For engineering teams, three things actually matter here:

If Claude Code touched a function, the watermark travels into your repo, and possibly a client's, indefinitely. Any "no AI-generated code" clause just got a lot more testable.
The watermark proves Claude touched the text. It doesn't prove you followed a real process, or that the output matches what was approved.
Detecting AI involvement answers one question. Regulators and clients want three: who asked for it, under what constraints, and whether it matches what was approved. A spec-driven paper trail answers all three. A watermark answers one, and only sometimes.

Your Coding Agent's Approval Dialog Is Lying to You

Girish R — Tue, 04 Aug 2026 16:38:44 +0000

On July 8, Wiz Research disclosed GhostApproval, a symlink flaw that hit six major AI coding assistants at once: Amazon Q Developer, Claude Code, Augment, Cursor, Google Antigravity, and Windsurf. The bug is almost insultingly simple, which is exactly why it worked.

A repo ships a file named project_settings.json. It's actually a symlink pointing at your SSH keys. You ask the agent to "set up the workspace." The agent resolves the link, writes to the real target, and shows you an approval dialog that says project_settings.json - because that's the name it was told, not the file it's about to touch. You click approve. You just authorized a write to ~/.ssh/id_rsa without knowing it.

Three things stand out from this disclosure.

The dialog worked exactly as designed. It shows the path a tool call was invoked with, not the path the filesystem resolves to after it follows a symlink. That gap between what the agent says it's doing and what the filesystem actually does is a decades-old class of bug - TOCTOU and symlink attacks predate LLMs by thirty years - and it walked straight into agentic coding because nobody ported the old lessons over.
Vendors split on whether this is even a vulnerability. Amazon, Google, and Cursor shipped fixes. Augment and Windsurf went quiet. Anthropic disputed that Claude Code's behavior was a flaw at all, arguing that a user who trusts a directory and approves an edit owns that decision. Defensible in the abstract, useless in practice: nobody reviewing a "set up the workspace" request is mentally resolving symlinks before they click yes. Consent that requires the human to out-think the attacker is liability transfer dressed up as consent.
The same week, Cursor patched DuneSlide - two CVSS 9.8 zero-click RCEs where a prompt-injected instruction in an MCP response or search result escaped the sandbox entirely, no approval needed at all. GhostApproval and DuneSlide put the trust boundary in the wrong place in two different ways. One relies on a human reading a dialog correctly under time pressure. The other skips the human entirely.

Per-action approval was never an architecture. It's a stopgap that asks a person to make a correct security judgment every single time, on decisions an agent generates faster than anyone can review. GhostApproval is what happens when the only thing standing between an agent and your SSH keys is whether you noticed a filename.

The actual fix is scoping what an agent can touch before it runs, not asking someone to referee each touch as it happens. A spec that enumerates which paths, which operations, which directories are in bounds for a given task turns "did the human catch this" into "was this ever a legal move." You don't need to out-think a symlink attack if the agent was never authorized to write outside /src in the first place. Write your specs to define the blast radius up front. Stop outsourcing that job to a dialog box nobody has time to verify.

AI Is Breaking the Traditional Software Pricing Model

Girish R — Thu, 21 May 2026 06:35:46 +0000

AI Is Breaking the Traditional Software Pricing Model

For decades, software pricing was built around one core assumption:

More time and more developers means higher value.

That made sense when software development was mostly manual effort. Companies estimated projects based on:

developer count,
hours worked,
sprint velocity,
and delivery timelines.

But AI is fundamentally changing that model.

Today, a strong engineer using AI can build in weeks what previously required months of effort from an entire team. Boilerplate code, documentation, testing support, UI scaffolding, and even architecture suggestions can now be generated rapidly.

This creates an important question for the software industry:

If software can be built faster, how should companies price their work?

The answer is that software itself is not becoming “cheap.” What is becoming cheaper is repetitive implementation.

Clients were never truly paying for typing speed or raw code generation.

They were paying for:

solving business problems,
making the right technical decisions,
building scalable systems,
reducing operational risk,
and delivering reliable outcomes.

AI commoditizes code generation.
It does not commoditize judgment, ownership, or execution quality.

This is why the traditional hourly billing model is starting to break down.

Imagine two companies:

one takes 6 months to deliver a platform manually,
another uses AI-assisted workflows and delivers the same business value in 6 weeks.

Should the faster company earn less because they are more efficient?

That logic no longer works in the AI era.

The software industry is gradually shifting from:

selling labor

to:

selling leverage and outcomes.

This changes how modern software companies need to think about pricing.

The future is likely a hybrid model that combines:

strategic consulting,
milestone-based implementation,
AI infrastructure costs,
recurring optimization,
and outcome-driven pricing.

The companies that succeed will not necessarily be the ones with the largest engineering teams.

They will be the ones with:

better systems,
clearer specifications,
stronger execution workflows,
reusable architecture,
and faster delivery cycles.

This is also why specification-first approaches like Spec-Driven Development (SDD) become increasingly important in the AI era.

As AI accelerates implementation, ambiguity becomes more expensive.

Without clear specifications:

AI-generated systems become inconsistent,
technical debt increases rapidly,
and teams lose alignment.

The bottleneck is no longer simply writing code.

The real bottleneck becomes:

clarity,
coordination,
decision making,
and execution quality.

In many ways, AI is not reducing the importance of software engineering discipline.

It is increasing it.

The future of software delivery is not just AI-assisted coding.

It is AI-assisted execution built on strong specifications, structured workflows, and reliable engineering systems.

Why Developers Feel Like Spectators in the Age of AI Coding

Girish R — Fri, 27 Feb 2026 07:44:03 +0000

There is a conversation happening quietly in engineering teams around the world. Developers are shipping more code than ever before, pull requests are merging faster, and backlogs are shrinking at unprecedented rates. Yet behind this surge in output, many experienced engineers report a growing unease-a sense that, for all the productivity, something essential has been lost.

The question is not whether AI coding tools work. They do. The question is whether the developer is still the one doing the work.

The Craftsman and the Machine

Software development, at its core, has always been an act of creation. The engineer who solves a particularly thorny algorithmic problem, designs an elegant data model, or architects a system that gracefully handles failure - these are acts of genuine intellectual authorship. The satisfaction they produce is not incidental; it is the primary reward mechanism that sustains long careers in a demanding field.

When an AI assistant generates that solution in seconds, the output may be functionally identical. But the psychological experience is fundamentally different. The developer did not solve the problem. They accepted a solution.

This distinction matters far more than the productivity metrics suggest.

Understanding the Accomplishment Gap

Psychological research on motivation offers a useful framework here. Self-Determination Theory identifies three core human needs that drive intrinsic motivation: autonomy, competence, and relatedness. AI-assisted development, when not thoughtfully managed, can erode all three:

Autonomy: When the AI generates the implementation, the developer's role shifts from author to reviewer. Decisions that were once deliberate choices become passive acceptances.
Competence: Mastery is built through struggle. The cognitive effort of working through a difficult problem creates durable expertise. Bypassing that struggle may accelerate delivery, but it simultaneously bypasses the learning that builds real seniority.
Ownership: Code you wrote feels like yours. Code you accepted from a model feels borrowed. This matters for long-term engagement, pride in one's work, and professional identity. The result is what we might call the** Accomplishment Gap** - the widening distance between lines of code shipped and the felt experience of having built something meaningful.

The Developer's Dilemma

This phenomenon is particularly acute for senior engineers. A developer with ten years of experience has an acute internal sense of what it means to have truly solved something. They know the difference between understanding a solution and having accepted one. AI tools, to them, can feel less like an amplifier of their capabilities and more like a replacement for the very activities that defined their professional identity.

Junior developers face a different but equally serious risk: they may accumulate output without accumulating expertise. The muscle memory of debugging, the intuition built through repeated architectural decisions, the judgment that comes from having made-and lived with-consequential trade-offs. These cannot be shortcut.

The Missing Link: Intent and Specification

What AI-assisted development currently lacks, in most implementations, is a structured mechanism for preserving the developer's intellectual authorship at the level that matters most-the design of the solution, not just its implementation.

This is the insight that drives Specification-Driven Development. Learn more about Why SDD?.

When a developer authors a specification before any code is generated-defining requirements, architectural decisions, edge cases, and acceptance criteria-they remain the genuine architect of the system. The AI becomes a capable executor of a plan that originated in the developer's own reasoning. The authorship is preserved where it most matters: in the conception.

.specs/requirements.md

REQ-001: User Authentication Flow

Users must authenticate via OAuth 2.0

Session tokens expire after 24 hours

Failed attempts exceeding 5 within 10 minutes trigger a lock

Rationale: Compliance with internal security policy SEC-004

This specification is not AI-generated. It reflects the developer's understanding of the problem domain, their judgment about trade-offs, and their anticipation of failure modes. When the AI subsequently generates code to satisfy these requirements, the developer can recognize the output as an implementation of their design-because it is.

Reclaiming the Craft

The path forward is not to reject AI tools, nor to use them uncritically. It is to restructure the workflow so that developers remain genuinely engaged with the problems that define professional software engineering:

1. Invest in the specification, not just the prompt. Time spent on clear, detailed requirements is time spent on the intellectually rewarding work of system design.
2. Review generated code with structural intent. Move beyond syntax checking. Ask whether the code correctly expresses the design, handles the specified edge cases, and aligns with the architectural principles you defined.
3. Treat the AI as a junior engineer, not an oracle. A good senior developer reviews, challenges, and improves the work of junior teammates. That relationship preserves judgment and ownership.
4. Celebrate architectural decisions, not just merged PRs. Teams that measure success only by velocity will inadvertently devalue the design work that gives velocity its meaning.

A Different Metric for Success

The engineering industry has spent years optimizing for lines of code, story points, and deployment frequency. AI tools will continue to drive those numbers higher. But the developers who sustain long, fulfilling careers will be those who measure themselves differently-by the quality of the problems they defined, the elegance of the systems they designed, and the depth of the expertise they built along the way.

But restoring the sense of creative authorship in AI-assisted development requires intentionality-from individual engineers, from engineering leaders, and from the tools themselves.

We are building SpecPilot with that intentionality at its core. We would be glad to hear how your team is navigating this challenge.

📖 Full post: https://specpilot.dev/blog/why-developers-feel-like-spectators-in-the-age-of-ai-coding

SpecPilot.dev: A Spec-Driven Approach to AI-Assisted Development

Girish R — Sun, 15 Feb 2026 07:19:00 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I built SpecPilot - an open-source, spec-driven development tool that helps engineers move away from “vibe coding” and toward intent-first software design.

SpecPilot sits at the intersection of AI and engineering rigor. Instead of jumping straight from prompt → code → fix → repeat, it encourages teams to slow down just enough to define:

Clear intent
Constraints
Acceptance criteria
Architectural boundaries

before code is generated.

This project is personal for me. Over the months, I’ve seen how AI doesn’t create bad engineering practices—it amplifies existing ones. SpecPilot is my attempt to create a lightweight but opinionated workflow that helps teams use AI responsibly, without turning software into a fragile house of cards.

SpecPilot is fully open source and available on GitHub:

👉 https://github.com/girishr/SpecPilot

👉 https://specpilot.dev

Demo

GitHub Repository: https://github.com/girishr/SpecPilot
Website: https://specpilot.dev (Its got a terminal emulator that shows how the tool works)

The repo includes:

CLI workflows
Example specs
End-to-end flows showing how specs evolve into implementation-ready artifacts

I’m actively iterating in the open, so the demo evolves as the project grows. (you can check out the .spec folder in https://github.com/girishr/SpecPilot/blob/main/.specs/planning/tasks.md to see what is planned)

My Experience with GitHub Copilot CLI

GitHub Copilot CLI played a meaningful role in building SpecPilot—but it wasn’t the only tool in the loop.

I used Copilot CLI primarily for:

Exploring CLI command flows quickly
Generating shell scripts and scaffolding logic
Rapid iteration while staying inside the terminal
Sanity-checking ideas without breaking context

At the same time, I paired it with:

GitHub Copilot Chat inside VS Code for deeper reasoning, refactoring, and architectural discussion
Multiple models depending on the task:
- Claude Sonnet for structured reasoning and spec clarity
- GPT-5.2 Codex for implementation-heavy work
- Grok Code (free) for fast experimentation and alternate perspectives

This mix-and-match approach felt natural. Different problems benefit from different strengths, and Copilot CLI fit nicely as a terminal-native accelerator, not a replacement for thinking.

One thing I appreciated was how Copilot CLI reduced friction. It didn’t try to “own” the workflow—it supported it. That aligns well with SpecPilot’s philosophy: AI should assist intent, not replace it.

SpecPilot vs GitHub SpecKit

I’m aware that GitHub already offers a similar concept with SpecKit.

SpecPilot wasn’t built as a competitor.

It exists because I personally felt there were a few gaps and ideas not fully addressed by SpecKit—particularly around opinionated workflows, extensibility, and how specs evolve alongside AI-assisted coding.

That said, both tools are aligned on the same core principle:

Better specs lead to better software.

I see SpecKit and SpecPilot as different interpretations of spec-driven development, each with its own philosophy and trade-offs. Choice is a good thing, especially in a space as young and fast-moving as AI-assisted engineering.

Closing Thoughts

This challenge wasn’t just about using Copilot—it was about understanding where AI fits best in real developer workflows.

For me, Copilot CLI shines when it:

Reduces context switching
Speeds up experimentation
Lets ideas flow without ceremony

SpecPilot is still evolving, but GitHub Copilot—especially in the CLI—has already become a trusted companion in that journey.

Thanks to the GitHub and DEV teams for running this challenge. It’s exactly the kind of space where thoughtful, open experimentation belongs.

Lightweight CLI for Specification-Driven Development

Girish R — Tue, 10 Feb 2026 20:00:00 +0000

Specification-driven development sounds great in theory.
In practice, it often breaks down.

Specs become outdated.
Docs drift away from reality.
Tools feel too heavy for everyday development.

After seeing this pattern repeatedly across teams, I started working on SpecPilot.

What is SpecPilot?

SpecPilot is a lightweight, open-source CLI tool for specification-driven development.

The idea is simple:

Write specs first
Keep them close to the code
Make specs actionable, not just documentation

Instead of heavy formats or platforms, SpecPilot uses Markdown-friendly specs and works directly from the terminal.

🔗 Website: https://specpilot.dev
🔗 GitHub: https://github.com/girishr/specpilot

Why I Built It

Most spec tools fail for one of two reasons:

They introduce too much ceremony
They don’t fit real developer workflows

SpecPilot is intentionally:

CLI-first
Git-friendly
Lightweight
Framework-agnostic

The goal isn’t to replace OpenAPI or enterprise tooling.
It’s to support teams that want clarity early without slowing down execution.

What SpecPilot Helps With

Defining clear specifications before implementation
Keeping specs versioned alongside code
Generating a clean, structured project scaffold
Reducing ambiguity during project kick-off
Improving alignment in small to mid-sized teams

Who It’s For (and Who It’s Not)

Good fit if you:

Prefer simple, readable specs
Want specs that evolve with the codebase
Work on small to mid-sized projects
Value flexibility over strict schemas

Probably not for you if you:

Are deeply invested in heavyweight spec platforms
Need strict contract enforcement at all times
Want full enterprise governance features

Current Status

SpecPilot is open source and actively evolving.
I’m rolling it out in small internal projects to test real-world usage, learn where it breaks, and improve it incrementally.

Feedback at this stage matters more than features.

Get Involved

If this sounds interesting:

⭐ Star the project: https://github.com/girishr/specpilot
🧪 Try it on a small project
🐞 Open issues or suggest improvements
🔧 Contribute if you’d like to help shape it

If you’ve tried spec-first development before and it didn’t stick, I’d especially love to hear why.

Thanks for reading.