AI devtools don't have a code problem. They have a context problem.
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?
One thing I underestimated here: workspace-awareness by itself is not the full answer.
It helps a lot with contradiction and generic suggestions, but the next hard layer is making AI actions inspectable enough that engineering teams can actually trust them in day-to-day work.
That seems like the real frontier now.