Staff.rip
Describe a code change in plain language and ship it
133 followers
Describe a code change in plain language and ship it
133 followers
Use AI anywhere in your codebase — frontend, backend, microservices, infra. Hosted or self-hosted, your call. Open it to your team and your clients without giving up control.
Free
Launch Team
Cedric AI Teammate for StartupsThe AI teammate for user acquisition, brand monitoring, competitor analysis and websites
Promoted
Hey Product Hunt 👋
I'm Yehdy, founder of staff.rip.
AI coding tools today are either "send your whole codebase to someone else's cloud"
(Cursor, Lovable) or "engineers-only CLI" (Claude Code, Aider). Designers, PMs, and
agency clients are stuck filing tickets and waiting.
staff.rip is the third option:
- AI anywhere in your stack — frontend, backend, microservices, infra, data, tests.
You set each project's mission.
- Hosted or self-hosted, your call — the agent runs locally, so your code never
leaves your machine.
- Open it to your whole team — chat + click-to-edit on the running app. No git, no
CLI.
Free to start (no credit card). €15/seat for Pro. Enterprise with SSO + self-host on
contract.
I'll be in the comments all day. *Where's the gap between "this sounds right" and
"this actually solves my problem"?* Tell me what's missing.
— Yehdy · @staffrip · staff.rip
@divyanshu_kandpal maybe that part was not clear, the idea is for tech people to access the code on GitHub, validate PRs etc, but clients of web-agencies, designers, product owners, pms etc have access to a dev environment without requiring to run projects on their machine, think about code, nor manage cli commands. The good practice is to separate dev environment from prod, or to give a limited set of permissions to the vps if it sits in your cloud.
the "plain language to shipped code" framing is the wedge for ai-assisted shipping. one curious thing — when staff.rip ships a change, does the PR carry a trace of the prompt that produced it? becomes useful when you want to replay what the agent was asked vs what it did.
@vivek_warrant Not yet but it's definitely something I will implement, normally your coding agent would write the changes in your PR message but having an explicit Initial prompt or a link to the messages associated to it would definitely bring value.
Worked on a team project once where the codebase was divided across people and anytime a change touched someone else’s part, everything would grind to a halt until that person was available. Even really small things would suddenly become blockers because only one person properly understood that section of the stack.
That’s honestly the part of Staff.rip that stood out to me most. The idea of interacting with larger codebases through plain language instead of needing deep familiarity with every service/component feels genuinely useful once projects start getting fragmented across teams.
The self-hosted angle matters too since most teams realistically are not going to send a production codebase to a third-party cloud.
One thing I’m curious about though, as the codebase grows and changes over time, does Staff.rip maintain some persistent understanding of the project architecture across sessions or does each session mostly start fresh?
The provenance point feels bigger than a nice-to-have. Once non-engineers can initiate changes, teams need a compact audit trail of intent -> plan -> diff -> reviewer decision, otherwise every bug turns into archaeology.
Even a lightweight record on the PR or deployment review page would go a long way: initial request, agent summary of what it thought the request meant, key tool actions, and the final reviewer decision. That seems like the piece that turns "plain language to shipped code" from a clever demo into something teams can trust at scale.
Interesting that it prioritizes self-hosted governance over raw autonomy. Curious how it handles rollback when an agent-initiated change breaks a downstream dependency — that's the hard part nobody talks about.