Revolte - AI for Software Engineering

@rajagopalanar congrats on the launch Raj. How do you avoid a pile up at the judge gate (agent coded and now there's a stack of reviews)?

@rajagopalanar This resonates deeply. The IDE is just one piece of the puzzle, and most teams are still losing velocity to context-switching across fragmented tooling. Keeping humans in the loop for review and decision-making is the right call—automation that removes accountability is automation teams won't actually adopt.

@retain_dev Really appreciate the comment — you’ve clearly felt this pain firsthand and that framing is spot on.

Here’s a simple development workflow in Revolte to answer your question.

A feature ticket comes in → the planning agent breaks it down → coding agent implements it → tests are auto-generated → SAST/DAST runs → PR is raised. The dev reviews and approves at the end. No hand-holding in between.

Now the gate question: that’s configurable. Teams define approval rules at the workflow level — a routine feature build on a low-risk service can flow straight through, anywhere a particular artifact to be finally used in the product as code or test script or design, the it will go through approval gate. No output will be used or merged to exisiting repository finally without human approval.

The risk-scoring side is something we’re making smarter over time — more context-aware, less purely rule-based.

But the principle stays the same: full autonomy where it’s safe, human judgement where it matters.

let me know if this answers the question

Dear @retain_dev  Interesting question actually ., while pretotyping some of our workflows, we started noticing the same challenge & pattern during work within finance environment.

Autonomy there became heavily risk-dependent (along with few other OPA rules).

Say for lower-risk features — like their internal dashboards, FAQ/content updates, coupon dashboards, and non-critical UI flows — the workflows were designed with much lighter Human approvals and higher AI autonomy.

But workflows touching their Core new features -> say., beneficiary logic, critical infrastructure pieces - introduced much stronger validation layers and human checkpoints before anything could move forward.

That’s probably where we feel engineering AI systems evolve over time — systems themselves becoming smarter in identifying which workflows can move autonomously versus which ones need stronger approvals and human oversight. That balance Raj mentioned — autonomy with governed checkpoints — is exactly the direction we’re trying to preserve in REVOLTE.

Curious how you’re thinking about this in your own agent workflows today — are you leaning more toward static approval rules, or dynamic risk/context-based gating?

Thanks you,@istiakahmad this means a lot.

You captured the heart of it perfectly: the bottleneck was never code generation, it's everything around the code, getting a change safely from intent to production. That's the whole thing we obsess over, and the trust model is exactly where we've spent the most time, approval gates, visibility into the diff and reasoning, the checks and rollback paths.

And appreciate you flagging the per-service pricing and the CLI experience for people to dig into. Grateful to have you hunting us today. 🙂

@shivam_jaiswal21 Very aligned with that view. We don’t think the context problem gets solved by pushing more files into a bigger prompt window.

Our approach is to treat context as a system graph, not a repo dump. For larger multi-repo environments, Revolte maps the service boundaries, dependencies, APIs, ownership, deployment paths, PR history, tickets/specs, and runtime signals around the change being made. The agent then pulls the relevant slice of context for that workflow instead of trying to reason over the entire estate at once.

The important part is also separating “code context” from “delivery context”. A change is rarely just about the files touched. It has impact across tests, environments, release rules, observability, and sometimes adjacent services.

We are still early in how far this can go, but that is the bet: context has to be structured around how engineering teams actually ship, not just how code is stored.

Would love to compare notes given your lens in the dev tool space.

@shivam_jaiswal21 

Really glad this resonates — and you’ve put your finger on something we spent a lot of time on.

Here’s how we approach it: for every codebase, Revolte maintains a separate entity called an App/Service. Each one builds its own context — the structure, dependencies, patterns, and history specific to that service. That context isn’t shared or muddled across repos; it’s scoped and owned.

When a workflow runs, the agents work within that context. When a dev picks up Revolte Code (our CLI) to review and approve the output, they’re working from the same context — so there’s no gap between what the agent understood and what the human sees.

But the part we’re equally serious about is context poisoning — because bloated, unstructured context is almost as bad as no context. Agents hallucinating based on irrelevant noise is a real failure mode. Our approach is a clear structural flow built into Revolte that governs how context is built, what gets included, and what doesn’t. Meaningless context without reference doesn’t make it in.

It’s an area we’re continuously tightening — because getting the reasoning right at a system level, not just file level, is what actually makes autonomous workflows trustworthy at scale.

@nithin_raju1 Good question and an important distinction — task execution accuracy is really asking whether the agent actually completes the job end to end, or gets lost halfway through.

The honest answer is that the pipeline structure is what makes execution reliable in practice. There's a planner step that runs before any code gets written — it maps out what the task actually involves and what done looks like. That upfront planning step is what prevents the agent from going off in the wrong direction and only discovering it three commits later.

From there each step in the pipeline — codegen, testgen, regression — has a defined scope and exit condition. It's not one agent trying to freestyle the whole thing. And if something fails at any stage, it surfaces there rather than quietly producing something broken that reaches a PR.

Where execution gets harder is with tasks that span multiple services or involve calls that need real domain judgment — those are the ones where we've deliberately kept humans in the loop rather than pushing for full automation. The goal isn't maximum autonomy, it's reliable execution on the work that can run cleanly, and a clear handoff when it can't.

What we're seeing with customers is that the volume of tasks completing end to end without constant intervention has gone up significantly. That's the real signal on execution for us.

@elvis_onjiko Fair question. As you pointed out, this is exactly where most AI dev tools start to struggle as of today.

Our experience is that older production codebases need bounded context, not a giant repo dump into a prompt. Legacy systems usually have old patterns, partial docs, weak test coverage, tribal knowledge, and deployment rules that are not obvious from the code alone.

So Revolte approaches it in smaller controlled slices. It builds context around the change area: repo structure, service boundaries, dependencies, relevant files, test paths, PR history, and where possible, runtime or deployment signals. The goal is not to magically understand the whole estate on day one. It is to make safer changes with the right context and human review points.

Messier codebases are actually where we think this workflow layer matters most. The value is not just writing code, but knowing what to touch, what to avoid, what to test, and where a human should approve.

@elvis_onjiko 

Totally valid concern — and one we’ve heard a lot.

Yes, Revolte has been tested on older codebases and the honest answer is: legacy vs new doesn’t matter as much as you’d think — what matters is context.

Revolte builds context per App or Service, and as long as that context can be established well, the agents can work effectively regardless of how old or messy the repo is. A legacy codebase with good context is more workable than a greenfield project with none.

Where things get harder is when a codebase is undocumented or inconsistent. In those cases, we work with teams to build that context up front — mapping the service structure, defining boundaries, and documenting the key patterns. It’s an investment, but once the context is solid, Revolte runs on it just as effectively as any modern codebase.

So the first step with a messy legacy repo isn’t jumping straight into workflows — it’s making sure the context layer is strong enough to support them.

@zabry 

Thanks for the kind words, and these are absolutely the right questions — let me answer each one directly.

On security standards — Revolte is SOC 2 and GDPR compliant, with clearly defined access boundaries for every agent and workflow. SAST and DAST scanning run as part of every pipeline automatically.

On SDLC policy enforcement — teams define their policies in YAML per service, and Revolte enforces them on every workflow run. The policies you’ve built over the years don’t get replaced — they get encoded and consistently applied.

On data residency — Revolte runs on AWS and can be deployed in any AWS region, including UK and EMEA, to match your requirements. Your data stays where you need it to.

Happy to share more detail with your security team if that would help.