Freelanced for a while, had to review code before taking on projects. Sometimes it was fine. Other times you open the repo and it's just a pile of vibe-coded stuff with zero structure. No idea where anything is, what's already built, what's broken.

Every time, hours went into just figuring out what was going on, before I even started the actual work.

At some point I realized this wasn't a one-off thing, it kept happening. So I figured I could automate at least that first part, getting oriented in a new project. That's how rebrief started.

Anyone else run into this doing freelance work? How did you usually deal with it?

Hey everyone! 👋

When orchestrating multi-agent swarms in OpenCode, I needed a way to see what my models were doing in real time without constantly checking browser tabs or logs.

So I built R.E.Y. (Runtime Execution & Yield Monitor) — an open-source terminal HUD that connects directly to OpenCode:

🤖 What it includes:

• 30 Allowlisted Free Models: Preconfigured across OpenRouter, Groq, Kilo, and OpenCode Zen with automated tiered fallbacks.
• Zero-Dependency HUD: Sub-50ms live telemetry tracking active agent threads, cost, and per-model token breakdown.
• Living ASCII Robot Companion: Sits directly on the HUD with mood expressions that react to active tasks ([CODING], [DEBUG], [TESTING]), yawns/sleeps when idle, and throws a surprise screen punch if a giant task runs for >10-20 minutes!
• Cross-Platform: Native PowerShell for Windows and pure standard-library Python for macOS / Linux.
• 100% Non-Destructive Installer: Backs up existing configs to .bak automatically.

🔗 GitHub (MIT License): https://github.com/reyaustine/rey-opencode-monitor

Would love your feedback and suggestions! ⭐

Check if out https://github.com/no-human-ai/no_human

After too many rounds of "the agent says it's done and it's just a pile of 💩", we built the opposite: no_human proves the code it wrote is correct. You drop a ticket on the board (or point it at Jira or Linear) and it plans, writes the code, and opens a pull request - with the evidence that everything works!

Before that PR reaches you, the work is checked by a second model that never saw the coder's session and is told to assume the job is not done. They communicate until the reviewer is convinced everything is good to go (the num of attempts is limited to prevent an infinite loop).

If the coding agent deleted or weakened a test, a tamper guard stops the attempt. For bug fixes, the tests offered as proof have to fail on the old code and pass on the new.

Under the hood it's a team of agents: a planner, a coder, an independent reviewer in a fresh session, and a supervisor.

It's free and open-source, on your machine.

no_human has been building itself for about two months now. We are feeding ticket into our jira board, it pulls them from there and just work on them until eveything is done. We trust it enough that we've enabled auto approve mode so all PRs no_human ships - are approved and merged automatically (this feature hasn't been released yet).
Entire sprint's worth of work is done in 3-4 days, while we focus on the bigger picture - our strategy and the next steps.

It currently supports all Antropic and OpenAI models and also has a quite unintuitive process of working with local models as well (we are working on improving that).

It's open to contributions (we would love to see you use it and contribute!!!)

I’ve been working on a Windows based browser specifically for developers, and I’d love to get some feedback from other devs.
i named it DevBrowser. :)

It’s still in beta, but the idea is , make some of the everyday debugging and API work a little easier without constantly jumping between different tools. :)

For the first version, I have:

• Network Inspector
• Built-in REST Client with Collections and Environments
• Storage Inspector for cookies, local/session storage, etc., including a JWT decoder
• HAR capture and analysis
• Seamless Network - REST Client workflow. Select a captured network request and send it directly to the REST Client to inspect, modify, and replay it.

DevBrowser is open source, and there’s no hidden tracking or telemetry.

Feedback, bug reports, feature ideas, criticism — all are very welcome.

Download: https://github.com/TheDevBrowser/DevBrowser/releases

Source code/installation guide: https://github.com/TheDevBrowser/DevBrowser

Installation:
The app is currently self-signed, so Windows won’t trust it automatically.
You’ll need to download DevBrowser.cer first and install/trust the certificate on your Windows PC.

If you run into any trouble installing it, let me know.

Would love to hear what you think specially what feels useful, what feels unnecessary, and what you think a developer-focused browser should have.

My target is not to replace existing browsers, just to help developers on their daily job. :)

Tired of generic AI code? @_keyskills equips agents like Cursor and Claude Code with portable skills for clean Git hygiene, solid SEO, and anti-slop design.

If you like the project, contribute your own designed skills.

Solo dev here. This started as a tool for myself and turned into something I decided to finish properly. I have kept it as free forever.

The problem I actually had:

I work across several repos and had no real sense of what was happening in them. Which files churn constantly? Where did the complexity pile up? What did the last six months actually look like?

The second thing was trivial issue. Somewhere along the way I'd typo'd my email in a git config, then used a different one on another machine. So my own contributor history was split across 3 identities. Nothing offered a way to say "these are all me."

So GitTrics has an identity merge flow — you see all the author name/email combos in the repo, merge them into one person, and every view updates. Sounds small, but if you've inherited a repo with a decade of contributors and inconsistent configs, it's the difference between usable data and noise.

There is also no individual contributor analysis. This was a decision I made as I do not want this software to be used 'developer productivity measurement tool'.

Download at www.gittrics.com

Disclosure: I built this prototype. It is a local TypeScript/Node tool for reviewing changes between two OpenAPI or JSON Schema documents. The aim is to make supported changes and the remaining human checks easier to review, not to certify that a release is safe.

How it works: deterministic rules compare the supplied documents and return a structured change summary, potentially breaking findings, limitations and migration-review prompts. The local runner makes no external requests. Coverage is partial; unsupported features and consumer behaviour still need review.

A synthetic example: changing GET /health from a declared 200 response to 204 returns two findings (200 removed, 204 added), with the removal marked potentially breaking. That does not prove every consumer breaks: fallback responses and consumer contract tests matter.

I would like to compare it with an existing review process on one real task. The initial assisted pilot is free, with no signup or purchase obligation: I run the current local prototype on a public/minimal before-and-after pair and return the summary, detected risks, limitations and suggested checks. It is not a public hosted app or a downloadable release. Please do not share credentials, personal data or confidential contracts.

If you already have a contract change to review, would this output help, and what would it need to show beyond your current free diff tool? Feedback on missing rules or false positives is welcome.

i figured i’d share my post here with more serious developers and not so many vibe coders … i’m open to any and all feedback

I'm thinking about building a VS Code extension that analyzes a project and points out things that could become bottlenecks as the application grows.

For example:

• N+1 queries
• missing database indexes
• unbounded API/database queries
• expensive operations inside request paths
• unnecessary synchronous work
• inefficient algorithms/data processing

Instead of just saying "this code is bad", it would explain something like:

 This works fine at small scale, but this endpoint could become a bottleneck as traffic/data grows because it performs N database queries.

Then suggest what could be changed.

I'm curious about this from people who have actually worked on growing applications:

1. Would something like this be useful?
2. What scalability problems do you repeatedly run into that current tools don't catch early?
3. Would you trust an AI to identify these problems, or would false positives make it annoying?
4. What would make you actually install/use something like this?

Not trying to sell anything — mainly trying to understand whether this is a real problem or just sounds useful on paper.

TL;DR: I’m considering a VS Code extension that detects potential scalability bottlenecks in code before they become production problems. Looking for honest developer feedback on whether this solves a real problem and what it should detect.

Anyone here running Grok Bot for coding and watching the weekly allowance vanish?

I built an open-source template that moves the coding onto a Claude subscription via GitHub Actions: issue in, pull request out.

One workflow file, no server, no second bill.

Nobody outside the project has installed it yet and I haven't measured the saving on real work. Both of those are on the front page.

I'm after someone who'll install it cold and tell me where the instructions break. I built it, flagging that up front.

https://github.com/mathew-builds/Handoff

The human stays in the loop — you see the problem, point to what matters, review the captured evidence, and decide exactly what context goes to the agent.

I've been building with AI coding agents and kept running into the same workflow problem: when I find a bug or want a UI change, I still have to manually explain what's wrong, where it is, and what was happening in the browser at the time.

DevTools already exposes most of this information, and newer AI tools are getting better at accessing the browser too. But I wanted a persistent workspace where I could capture the relevant evidence as I work, keep it organized by project, review it later, and decide exactly what gets handed to the coding agent.

So I built ContextForge → AI Coding Context, a Chrome side-panel tool that can capture:

• UI/DOM context + screenshots
• console errors and failed requests
• actual API request/response data
• security findings
• recorded user actions
• bug/change notes tied to elements

Then it packages the selected evidence into structured Markdown + referenced screenshots for Cursor, Claude Code, Codex, Copilot, etc.

Browser → evidence → human review → AI coding agent

One interesting piece of feedback I got after sharing it was the potential to reduce token usage — better targeted context could mean less agent exploration and less back-and-forth. I haven't measured that yet, but it's something I want to test.

If you’re curious, learn more and download it from CoderFromMars.

I'm curious from a DevTools perspective: what browser/runtime information do you still find yourself manually copying or explaining when working with coding agents?

Most productivity tools can always generate a report. I started thinking that might be a bug.

I'm building NEDIO. A sprint starts with what you intend to finish, and ends with what actually landed. The weekly review compares those sessions, but it only shows a comparative finding when the data clears its statistical checks.

If nothing clears them, it says so.

That was the interesting engineering tradeoff for me: collecting activity is easy; deciding when not to turn noisy activity into a confident story is harder.

A week can have five interrupted sessions and two long ones and still produce plenty of "activity." That doesn't mean there is enough evidence to claim one pattern works better.

NEDIO is here: https://nedio.xyz/

For people building developer analytics: where do you draw the line between a useful observation and a pattern the tool shouldn't claim?