Osloq

The "works on my machine" framing hits home — as a solo founder most of my bug reports come from non-technical users, so the "repro steps" are usually "it just broke" with no stack trace. Does Osloq still get somewhere useful when the issue text itself is vague, or does it lean on the reporter having written decent repro steps to work from?

Are there any plans to turn this into a full manual QA bot? Reproducing bugs are one thing but testing that the code is working as expected is also a tedious part I would love to do away with.

I like that the report is evidence-backed rather than just a polished summary. The detail I’d want in a team workflow is a clear “could not reproduce because…” state, so an issue can move back to the reporter without another manual triage loop.

How's it different than Linear's agent?

@enessss since Osloq stops at a confirmed repro with evidence rather than proposing a fix, is the output structured enough, or is it more of a human readable triage report at this stage?

the hard part with most repro bugs I've dealt with isn't running the code, it's the missing state - a specific user's data, a race condition that only shows up under load, third party API responses that vary. how does the sandbox handle issues that need real production-like data or timing to actually trigger, or is this mostly aimed at the straightforward "steps to reproduce" kind of bug

the setup loop is the sharp edge — the agent iterates until the repo's up. but a whole class of bugs is 'doesn't build on clean checkout,' and something whose job is to get it running will quietly patch past exactly that.

Running the actual code instead of reasoning about it is the right call. Curious how Osloq handles repos with external service dependencies - database calls, third-party APIs - where the bug only shows in a specific environment setup.

Hey Enes, the reproducing part has always been the bit that quietly eats my afternoon, so seeing something take that off my plate genuinely made me pause. Feels like the kind of help I'd actually welcome.

How does the sandbox handle repos with heavy infra dependencies like docker compose or database services. Does it spin those up too or just the app code in isolation?

I would like support for retrying failed reproductions. Multiple execution attempts could separate random failures from actual bugs.

The evidence-backed part is the important line here. For a small team, a bug-repro agent is useful only if the report can become a reviewable artifact: exact assumptions, commands, env gaps, and ideally a tiny failing test or script someone can rerun. That keeps it from turning into another confident AI opinion in the triage queue.

Curious how it handles repos with external service dependencies like a database or third party API. Does the sandbox spin those up too, or do I need to provide credentials before it can run anything?

The "no evidence, no claim" stance is the right call — I build agents for commerce checkout flows, and verifying an agent's claims against what actually ran is where most of our engineering time goes too.Two things I couldn't tell from the page: how do UI-only bugs work — if an issue only reproduces in a rendered front-end (dead button after hydration, checkout step breaking), does the sandbox drive a real browser, or is it limited to what's exercisable from CLI and tests?And how do you keep the agent itself honest over time — do you re-run it against a benchmark of previously-verified issues when prompts or models change, so repro accuracy doesn't silently regress?Congrats on the launch @enessss

Neat concept. Does it handle bugs that need specific user state or production data to actually reproduce?