I've been building devpub, an open-source CLI that publishes and tracks articles on Dev.to. Last week I was in Cursor, adding a new analytics feature - full vibe coding mode, rapid-fire prompts, one after another:
"add caching to the API client."
"fix the rate limiter."
"make the analytics faster."
Three prompts, three pieces of code generated instantly. I moved on. Two days later I realized the "fix" had silently broken my retry logic, the "caching" had no invalidation strategy, and "faster" meant the agent had removed the safety throttle that prevents Dev.to from banning my API key.
None of those prompts said what shouldn't change. None specified how I'd know it worked. I wrote them in flow, and the agent did exactly what I asked. Which wasn't what I meant.
That's when I tried NexPath, a prompt quality layer for AI coding agents. It sits between you and your agent, catches vague prompts at the moment you submit them, and offers a stronger version. I thought: why not try this on devpub? A real codebase I know inside out, with real prompts I'd actually type. If it works here, it works anywhere.
Table of Contents
- The vibe coding pattern nobody talks about
- What if something caught you before you hit Enter?
- What the enhanced version includes
- My hands-on experience with NexPath
- NexPath agent support: Cursor, Windsurf and Claude Code
- Who NexPath is for: Cursor, Windsurf and Claude Code users
- What NexPath costs
- Bottom line
The vibe coding pattern nobody talks about
Every developer using AI coding agents has a version of this story. Not because the agents are bad. They're incredibly good at generating code from whatever you give them. The problem is what we give them.
"Fix this." "Make it work." "Clean up the code." "Add auth."
These prompts feel productive. The agent responds instantly. Code appears. You move to the next thing. But six prompts later, your codebase has grown in directions you didn't plan, with assumptions you didn't state, skipping checks you didn't ask for.
The same mistakes repeat: no acceptance criteria, no rollback plan, no mention of what shouldn't change. Not because we don't know better. Because momentum makes it easy to skip.
The answer, I thought, was more discipline. Be better at prompting. Write longer, more detailed requests every time.
That lasted about three days.
What if something caught you before you hit Enter?
NexPath is not another coding agent. It doesn't generate code. It doesn't replace your agent. It doesn't try to be clever. It sits between you and your AI agent, and when you submit a vague prompt, it holds it for a second and says: "Here's a stronger version of what you meant. Want to use it instead?"
The simplest way I'd describe it: "NexPath is the thing that keeps AI-generated code from becoming a mess."
The workflow:
- You write your prompt in Cursor, Windsurf, or Claude Code
- NexPath intercepts it at submit time
- A popup shows your original alongside an enhanced version
- You pick which one gets sent
- The chosen version auto-submits to your agent
Your original intent stays visible throughout. Nothing auto-sends without your approval. If a prompt doesn't need enhancement, NexPath stays silent.
What the enhanced version includes
When the enhancement fires, it doesn't rewrite your prompt. It wraps your original request with:
- Scope boundaries: what should change, what shouldn't
- Acceptance criteria: how you'll know it worked
- Verification steps: tests to run after
- Safety requirements: rollback plan for risky operations
- Sequencing: if the task is complex, break it into ordered steps
Here's a real example from my devpub testing. I typed:
fix the rate limiter
NexPath enhanced it to something like:
Fix the rate limiter in DevtoClient._throttle(). Scope: only modify the timestamp tracking logic in src/devpub/api/devto.py. Do not change RATE_LIMIT_REQUESTS or RATE_LIMIT_WINDOW constants. Do not modify the retry logic in _request(). Acceptance: 30 requests per 30-second window still enforced, no sleep longer than 30s. Verify: run pytest tests/test_api.py after changes.
That's what I should have written in the first place. But I didn't, because I was in flow.
Another one. I typed:
push all drafts to dev.to as published
NexPath flagged the risk and added:
Push all draft articles to Dev.to with published=true. WARNING: This is a destructive action. Published articles are immediately visible to readers and cannot be easily unpublished. Scope: only modify the
publishedfield in article payloads. Safety: list all affected articles first and confirm count before proceeding. Rollback: note all article IDs changed so they can be reverted to draft if needed. Verify: check each article URL returns 200 after publishing.
The difference between "just do it" and "do it carefully," surfaced at exactly the right moment.
My hands-on experience with NexPath
I tested NexPath in two environments: Cursor on my laptop for the popup experience with devpub, and Claude Code on my EC2 server to stress-test the CLI and dig into the internals.
Installation (2-3 minutes, clean)
git clone https://github.com/hi0001234d/nexpath.git
cd nexpath
npm install # 16 seconds, 298 packages
npm run build # Build + 1,175 test validation
npm link
nexpath install # Auto-detected my agents, wrote hooks
The nexpath status command gives you a complete picture: prompt store stats, hook activity, config state, environment detection. The level of observability in the CLI surprised me. Structured JSON logs, proper error codes, debuggable output.
What I liked
Privacy holds up. Everything lives in ~/.nexpath/. A SQLite database stores your prompts locally. The only outbound calls are to OpenAI's API (GPT-4o-mini for classification). Telemetry is disabled by default, confirmed in config. Secret redaction strips API keys from stored prompts automatically.
The engineering is solid. 1,803 commits from a team of three. 1,175 tests in the VS Code extension alone. Structured logging. Environment detection (OS, WSL, CI, devcontainer). Proper config system with keychain integration. This is not a weekend hackathon project abandoned after the demo, even though it started at one (AI Hackfest 2026 by MLH).
It knows when to shut up. The system classifies your prompts into development stages (idea, architecture, implementation, testing, etc.) and only fires when it detects a transition or an absence signal: a missing spec, a skipped test strategy, a risky shortcut. When your prompts are already well-structured, it stays out of the way.
The popup experience just works. In Cursor, you type your prompt, hit Enter, and NexPath holds it for a beat. A popup appears showing your original alongside the enhanced version. You pick one, it auto-submits. No context switch, no copy-paste, no extra windows. It feels like a natural part of the workflow, not an interruption.
Environment awareness is thorough. The nexpath env command probes your OS, detects WSL, devcontainers, CI pipelines, shell type, project framework, version control, test runner, and deploy config, all locally. It uses this context to calibrate when and how it intervenes. That level of situational awareness is rare in developer tooling.
What needs work
API key handling has a rough edge. NexPath requires an OpenAI API key (for GPT-4o-mini). Their docs say it falls back gracefully to local classification when no key is available. In practice, after the first prompt, subsequent calls throw an unhandled OpenAIError: Missing credentials exception instead of degrading silently. It's a v1 edge case, easily fixable, but worth knowing if you're setting up on a fresh machine without a key configured yet.
The CLI advisory and the VS Code popup are different systems. The submit-time popup (Cursor/Windsurf) is the primary product. It intercepts every prompt at the moment you press Enter. The CLI advisory for Claude Code is a different mechanism that builds up session history before intervening. In my CLI stress test, it captured 18 prompts and intervened zero times because it needs longer session context to detect meaningful transitions. The popup experience doesn't have this limitation. It evaluates each prompt independently. If you're on Claude Code, expect a quieter experience than the Cursor/Windsurf popup.
Single LLM provider for now. It currently uses gpt-4o-mini as the classification model, a reasonable v1 tradeoff that limits flexibility for teams using other providers. The API costs are tiny (pennies per day), but multi-provider support would make it more accessible to teams with existing Anthropic or Groq setups.
NexPath agent support: Cursor, Windsurf and Claude Code
| Agent | Status (Aug 2026) |
|---|---|
| Claude Code | âś… Supported via CLI + MCP hooks |
| Cursor | âś… Supported via VS Code extension (submit-time popup) |
| Windsurf / Devin | âś… Supported via VS Code extension (submit-time popup) |
The VS Code extension (for Cursor and Windsurf) intercepts prompts at submit time and shows the popup inline. For Claude Code, it works through the CLI's hook system, firing between prompt submissions.
Important distinction: the Cursor/Windsurf experience is the polished one. You type, hit Enter, NexPath catches it, shows a popup, you pick, it sends. The Claude Code experience works through terminal hooks, which is less visual but functional.
Who NexPath is for: Cursor, Windsurf and Claude Code users
NexPath makes sense if you:
- Prompt in short bursts ("fix this", "add that") and want guardrails without slowing down
- Work on production codebases where a vague prompt can cause real damage
- Want prompt discipline without having to be disciplined every single time
- Use Cursor or Windsurf as your primary agent environment
It's less useful if you already write detailed, structured prompts consistently, or if you're building throwaway prototypes where quality doesn't matter.
What NexPath costs
NexPath itself is free (Apache 2.0, open source). The only cost is your OpenAI API key usage for GPT-4o-mini. In a typical coding session, that's $0.01 to $0.05 per day. Negligible, but not zero.
Bottom line
NexPath solves a problem I have: I write lazy prompts when I'm in flow, and those lazy prompts produce code that bites me later. The idea of a quality layer that catches me at the moment of submission, not after the damage is done, is genuinely useful.
I tested it on devpub, my own open-source project with a real API client, real rate limiting, real push-to-production workflows. The prompts I'd normally fire off ("fix the rate limiter", "push all drafts as published") came back stronger, scoped, and safe. That's the value.
The implementation on Cursor/Windsurf (submit-time popup, choose your version, auto-submit) is well-designed. The CLI experience for Claude Code needs more polish. The engineering underneath is serious, the privacy model is honest, and the team ships fast (20+ PRs merged in the 48 hours before launch).
Is it perfect? No. The API key handling has a rough edge. The single-provider model limits flexibility. The CLI advisory needs longer sessions to activate. But for a v0.1.4 open-source tool from a three-person team, it's solving the right problem in the right place, and the Cursor/Windsurf popup experience is genuinely well-executed.
I'll keep it installed. The first time it catches a dangerous prompt I would have sent unthinking, it pays for itself.
Try it yourself:
- GitHub: NexPath on GitHub
- VS Code Marketplace: NexPath VS Code extension for Cursor and Windsurf
- Open VSX: NexPath on Open VSX
- Demo: Prompt Enhancement in action
NexPath is running a Launch Feedback Challenge (ends Sep 2, 2026). They're looking for honest feedback, not praise. If you try it and have opinions, good or bad, share them at their discussion thread.
What's your approach to prompt quality? Do you write detailed prompts every time, or do you also fall into the "fix this" trap? Let me know in the comments.
Follow me for more on AWS architecture, DevOps, and AI Infrastructure:
Portfolio | LinkedIn | Dev.to | YouTube | Email | AWS Builder Center | X
Top comments (33)
Actually reminds me of a while ago, a discussion I had with @pascal_cescato_692b7a8a20 he had benchmarked a bunch of models, I asked him to try Kimi K2.7, so he did and Kimi did exactly what was asked... Except it didnt apply safe coding standards, it had left plaintext secrets, which DQ'd it, yet it had followed the instructions flawlessly, produced clean code and was cheaper... But it leaked passwords... Actually what sparked me on a journey, but that's another story, quality gating was the solution I came up with, hard-set functions in the IDE that flag unsafe edits, whereas this is essentially 'fix the prompt, before you fire it', to make sure it does what you expect it to do, not what you explicitly told it to do...
Pascal, might be worth starting Kimi up again on the benchmark, but with something like this to make it conform to safe coding standards? I'm curious how it would change the weaker models' outputs too.
Fix the prompt before you fire it is the part I kept. Leftover daily capacity on PZERO dies at UTC midnight. I quote the live leftover row first. Thin book, I shrink the job. I do not fire yesterday's leftover offer because it was cheaper.
Exactly! That is the part I wanted people to take away from it. Make the decision before you fire the job rather than dealing with the wrong outcome afterwards.
The way you described your workflow is actually a good example of the same principle. Understand the current state first and then decide what should be sent.
This is exactly the distinction I was trying to highlight in the article. A model can follow the prompt perfectly and still produce something that should never make it into the codebase.
The Kimi example is really interesting because the instructions were followed correctly but the missing safety constraints completely changed the outcome. I would genuinely like to see how the same benchmark performs with NexPath in front of it, especially with the weaker or cheaper models.
I also like the quality gating approach you mentioned. I think prompt level gating and edit level gating could complement each other really well.
And now I am curious about that another story you mentioned.
If I rerun all the prompts with new rules, the benchmark will likely be different—and possibly in a way that no one expects…
if possible please share link or anything for the benchmark you are referring to
dev.to/pascal_cescato_692b7a8a20/t...
Pascal's benchmark set
thanks for sharing the link, I'd a look and I feel it might be an interesting case study for nexpath. I will go through it once and get back to you later.
Thanks for sharing
whereas this is essentially 'fix the prompt, before you fire it', to make sure it does what you expect it to do, not what you explicitly told it to do...
=> yeah its more focused on ensuring that nexpath passes prompt with improvised instructions so that coding agent achieves what user expect it to do not what user told it to do. while safety gating comes as part of the process so yeah nexpath redact api keys, secrets etc.
Pascal, might be worth starting Kimi up again on the benchmark, but with something like this to make it conform to safe coding standards? I'm curious how it would change the weaker models' outputs too.
=> well @unitbuilds if you are planning something then do let us know by opening a discussion or issue on nexpath repo. and by the way we are already working on a benchmark but our metrics might be different than what you are plannig.
This is really helpful @sarvar_04 but One thing I’m curious about is how this compares with maintaining a good AGENTS.md or rules file. If I’ve already defined scope, coding conventions, and verification steps there, what does NexPath add that the agent’s persistent instructions don’t?
I see AGENTS.md/rules files and NexPath solving slightly different parts of the problem.
The rules file gives the agent persistent project context how the project works, what to follow, what not to touch, etc. NexPath is more about looking at the actual request you’re making right now and catching things that might be unclear, risky, or missing before you send it.
That said, I think there’s definitely overlap, and I don’t want NexPath to become something that just duplicates what’s already in the rules file. The idea of making NexPath aware of those existing rules and potentially learning from them is something I’d like to explore.
Okay got it. Thanks for the clarification Sarvar.
Your welcome
that's an interesting question pratik. nexpath's core idea is its an external entity keeping an eye on coding agent session. and then what goes through an improved prompt carries much higher value than what is inside agents md file because there is a much bigger orchestration difference plus coding agents see an instruction coming in from prompt with a completely different perspective than what is inside agents md. And by all means one can not cover everything in agents md file.
Okay got it. Thanks for the clarification Hiren.
The unstated invariant problem you describe hits a specific failure mode I've run into: agents optimize for the positive ask at the expense of what you didn't say.
make it fasterinterpreted asremove the throttleis locally valid reasoning. What catches these in my flow is treating safety rails and scope boundaries as explicit architecture constraints — literally present in the context window, not just remembered. NexPath's interception layer is basically automating that editorial pass. The question I'd have: does it learn your project's specific invariants over time, or does it apply general heuristics each time?Good question and honestly the throttle example is exactly the kind of thing I keep running into. It does both. There's a general set of checks that applies to everyone but the project specific part is where it actually gets useful. Over time it remembers what you keep vs what you edit out per project, so if you reject something a couple times it stops showing up. It also picks up on how you work from your own history and adjusts the framing. And for the project facts like test runner or backups it tries to only pull in the ones that matter for that specific prompt instead of dumping everything every time.
The one thing it wont learn away is safety and confirmation stuff. Even if you reject those repeatedly they stay protected. So the general checks are the floor and the learning happens above that. That was a deliberate call because those are exactly the invariants you dont want quietly disappearing.
yes it does learn project specific context. so its not mere general heuristics each time. I suggest you give it a try and share your feedback.
Answering your question, I stopped fixing prompts one by one. Scope, verification steps and what must not be touched live in a rules file that loads every session, so I do not retype it and I cannot forget it in the flow. Prompt layer at submit time solves same problem but per message, and per message is exactly where I am lazy when it matters. More interesting for me would be if such tool could write back into the rules file, then the lesson stays after the popup is gone.
Yeah that makes a lot of sense. I actually hadnt looked at it from the “lesson should persist” angle. The rules file approach solves the forgetting problem really well whereas NexPath today is more focused on catching things at submit time.
Having NexPath learn from those corrections and write the useful ones back into the rules file is definitely something worth exploring. Thanks for sharing this really good feedback. also if you have any other feedback or improvements you'd like to see NexPath adopt, I’d genuinely love to hear them. This kind of feedback is really helpful.
One more then. Every time somebody rejects the enhanced version that is also a signal, either rules file covers it already or the suggestion is wrong for that project. If you count which categories get rejected always and stop offering them, the tool becomes quiet exactly where it should be quiet. Otherwise it slowly turns into linter that everybody disables after one week.
This is a really good point and honestly one I hadnt considered from this angle.
A rejection shouldn’t just mean “not this time” it can be a signal that NexPath is being too aggressive or that the project already has that rule covered somewhere else. I really like the idea of using those signals to make NexPath quieter and more project aware over time otherwise like you said it just becomes another linter people get tired of and disable.
Really appreciate this suggestion. This is exactly the kind of feedback that can actually shape the product rather than just add another feature.
If you count which categories get rejected always and stop offering them, the tool becomes quiet exactly where it should be quiet.
=> yeah this needed to be taken care of and actually nexpath has feedback module which ask for reason when user rejects a prompt so that nexpath know when it needed to shut up. but yeah we are still working towards making it work end to end with custom feedbacks. custom feedbacks are where user can type anything as to why they rejected and then nexpath learns based on that and make sure that user gets better experince.
yeah writing back to rules file can be really helpful. but how often? when and when not, lets say you are using nexpath than what would you prefer like a option asking for adding in agents.md file when something important comes up?
I’ve been experimenting with NexPath on a real open-source project, and the biggest takeaway for me is that prompt quality is becoming just as important as code quality when working with AI coding agents.
The “fix this” → “fix this safely, within this scope, with clear acceptance criteria and verification” difference is surprisingly impactful.
Curious to hear from other developers: do you already write structured prompts for Cursor/Claude Code/Windsurf, or do you also find yourself firing off quick prompts when you’re in the flow? 👇
This makes me wonder about the cost side of prompt improvement. If NexPath is adding context and verification requirements to every prompt, how much additional token usage does that introduce, and does the reduction in bad agent runs actually offset it?
Thats a fair question. I was curious about the same thing while testing it. There is some extra context added but the bigger question is whether that small overhead saves you from a much more expensive agent run going in the wrong direction. I havent done a proper cost comparison yet, though, so that would be a useful thing to measure.
This is looks interesting but just curious to know if it’s open source ?
Yes the NexPath is open source and licensed under Apache.You can check out the source run it locally and contribute to it on github
Really interesting approach. I think the idea of improving the prompt before the coding agent acts is especially useful when you’re moving fast and don’t want to stop and write a perfect spec every time.
It also makes me think about how tools like CodeCan.net could benefit from similar quality and safety layers as AI-assisted development becomes more common.
Thanks. Yeah thats the main idea, catch the missing scope or safety bits before the agent runs off, especially when you dont want to stop and write a full spec every time. I think this kind of layer is going to show up in a lot more tools as agents get more autonomous.
good topic