workspai

While building Workspai (our VS Code extension for backend teams), one product lesson became very clear:

chat quality alone was not enough.

We saw good model outputs, but inconsistent real-world outcomes because users still had to do most of the routing work:

• summarize terminal failures manually

• explain project context repeatedly

• guess the safest next action

• verify fixes on their own

The improvement came when we started designing around a resolution loop:

1) detect 2) diagnose 3) plan 4) verify 5) learn

What changed in practice:

• less context reconstruction by users

• better confidence before applying risky changes

• clearer verification paths

• stronger repeat behavior when workspace memory is present

Our current belief:

For backend AI, the moat is not only model quality. It is workflow trust.

Context + inspectable actions + verification + memory.

I would love feedback from founders building devtools or AI products:

1. Which part of this loop is usually weakest in current tools?

2. Where do users lose trust first: diagnosis, planning, or verification?

3. If you have productized AI flows, what increased repeat usage the most?

Medium write-up: https://medium.com/@rapidkit/what-makes-backend-ai-useful-is-not-chat-it-is-a-resolution-loop-db86fc552eeb

Project: https://www.workspai.com/

I launched Workspai this week, a VS Code extension built on top of RapidKit.

The product thesis is simple:

The AI workspace for backend teams.

Build backend systems with AI that knows your workspace.

But the more conversations I have, the more I think the real problem in AI devtools is not generation quality by itself.

It's context transfer.

Most AI coding tools can generate something plausible.

The breakdown usually happens one step later:

- the suggestion ignores the project structure

- it doesn't know which modules are already installed

- it contradicts team conventions

- it proposes code that looks right in isolation but is wrong for the actual workspace

For backend teams, that makes AI feel strong in demos and inconsistent in real workflows.

That is the problem we're trying to solve with Workspai.

Before every AI prompt, the extension reads the surrounding backend workspace and carries that context into the request:

- framework and kit

- project structure

- installed modules

- recent changes

- workspace memory and team conventions

The goal is not to pretend context makes AI perfect.

It doesn't.

What it does do is remove a large class of bad answers that come from the model starting blind.

Something else became clearer while building and launching this:

workspace-awareness is necessary, but it is not sufficient.

The second layer is trust.

Even if the AI has the right context, engineering teams still need:

- inspectable actions

- reproducible workflows

- clear operating boundaries

- human review before changes are applied

That is why I think the next generation of AI devtools will not be won by chat UX alone.

It will be won by products that combine:

1. real workspace context

2. operational trust

3. tight integration with the actual developer workflow

That split is also how I now explain our own ecosystem more clearly:

- RapidKit is the execution and trust layer

- Workspai is the AI layer inside VS Code

It sounds obvious now, but it took me longer than expected to land on a version of the story that people understood quickly.

A few things I'm still working through:

- How much context is enough before prompts get too heavy?

- How do you make AI actions inspectable without adding too much friction?

- How do you position a product that sits between developer tooling and AI assistance without sounding vague?

Would love feedback from other founders and builders here:

1. If you use AI in real backend work, what piece of workspace context do tools still miss most often?

2. If you're building devtools, how are you thinking about trust and inspectability in agent-style workflows?

3. If you've had to position two products in one ecosystem, what finally made the story click?

Site: https://www.workspai.com/

Source: https://github.com/getrapidkit/rapidkit-vscode

One thing became clearer while talking to people after launch: a lot of the frustration with AI coding tools is really a context problem.

Most AI tools are good at understanding the current file. That works well enough for isolated tasks.

Backend work usually isn’t isolated.

A useful answer often depends on things outside the file:

- project structure

- installed modules and dependencies

- framework conventions

- recent changes

- team decisions that never appear in code comments

That’s why backend AI often sounds plausible but still gives suggestions that don’t fit the actual project.

The issue isn’t always model quality. A lot of the time, the model is answering without enough workspace-level context.

That’s the problem I’ve been trying to solve with Workspai: making AI aware of the workspace, not just the file.

Curious how others think about this: where do current AI coding tools break down first in backend projects?

We launched Workspai on Product Hunt yesterday.

Workspai is a VS Code extension for backend teams. The core idea is simple: AI coding tools are usually file-aware, not workspace-aware. They can see the file you're editing, but not the broader project structure, installed modules, recent changes, or team conventions. We built Workspai so AI can work with real backend workspace context instead of generic guesses.

The launch itself taught me a few things quickly.

First, distribution is much more manual than it looks from the outside. A launch page alone does almost nothing. The actual work is in the comments, the follow-ups, the founder replies, the social posts, the DMs, and the communities you’ve already spent time in before launch day.

Second, people respond much more to a clear problem than to a feature list. The phrase that consistently got attention was some version of: “AI coding tools are file-aware, not workspace-aware.” That landed faster than talking about architecture, prompts, or implementation details.

Third, comments were more valuable than votes. Votes help visibility, but the useful signal came from the questions people asked:

- how this differs from Copilot or Cursor

- whether the context stays local

- whether this actually reduces contradictory suggestions

- how Workspai relates to RapidKit

That last one was especially useful because it exposed a positioning problem I still need to keep improving:

- RapidKit = execution and trust layer

- Workspai = intelligence layer on top

Fourth, launch-day content has to be shorter than you think. A lot shorter. The longer explanations were useful in docs and detailed posts, but the messages that worked best in public feeds were the simplest ones.

A few honest notes:

- we’re still early

- revenue is still zero

- positioning is improving, but not perfect yet

- the product is much clearer now than it was a few weeks ago

The good part is that the launch forced clarity. It made me compress the value proposition down to the version people actually understand quickly.

If I were doing the launch again, I’d spend less time polishing copy and more time preparing tighter follow-up posts and reply templates.

For founders who’ve launched devtools before: what mattered more for you after day one — distribution volume, comment quality, or product page clarity?

We launched Workspai today.

The core problem behind it was simple: backend developers still have to explain their stack, layout, and conventions to AI from scratch in every session.

I had already built RapidKit as the execution layer for backend workspaces. Workspai became the AI layer on top — a VS Code extension that reads the workspace before every AI prompt so the model can work with real project context, not just the current file.

Still early, but this is the clearest version of the product we've had so far.

Would love feedback from anyone building in AI devtools or backend tooling.

I've been working on RapidKit for two years — an open-source toolkit that scaffolds backend workspaces for FastAPI, NestJS, and Go.

It generated real project structure, installed modules, and maintained a manifest of what was already in the project. Developers liked the structure, but I kept hearing the same feedback: after scaffolding, they still had to explain their project to AI tools from scratch every time.

That was the insight behind Workspai.

AI coding tools are usually file-aware, not workspace-aware. They see the file you're editing, but not the broader project layout, installed modules, recent changes, or team conventions. For backend systems, that makes AI much less useful than it should be.

So I built Workspai as the AI layer on top of RapidKit. It's a VS Code extension that reads the workspace before every AI prompt — framework, layout, installed modules, entry files, git changes, and workspace memory — so the AI can answer with real project context instead of generic guesses.

The biggest lesson so far has been positioning. RapidKit and Workspai are closely related, but they solve different problems. RapidKit is the execution and trust layer. Workspai is the intelligence layer on top.

We launched Workspai today.

The problem behind it was simple: AI coding tools are file-aware, not workspace-aware. Backend developers still have to explain their stack and structure from scratch in every session.

Workspai exists so AI can understand the workspace, not just the file.