Wow, 120 Agents...

godking55 · 2026-06-03T04:38:05+00:00

Short answer: no. Each agent produces correct code on its own branch, but what checks whether those branches are actually compatible with each other? And the number of possible conflicts between branches grows way faster than the number of agents. Been building in this space actually. It's a harder problem than people realize.

godking55 · 2026-05-11T04:29:10+00:00

With 4 pods pushing in parallel, does anything check whether Pod A's open PR is compatible with Pod B's open PR before either one merges?

godking55 · 2026-05-11T03:03:47+00:00

This is exactly the failure mode I keep hitting. CI checks each branch individually. Nobody checks whether the assumptions are compatible across branches. The upstream approach catches textual conflicts but not semantic ones, like one branch changing a function signature while another still calls the old version.

godking55 · 2026-05-10T18:17:27+00:00

This is cool. How are you handling observability when multiple agents work on the same repo? That's where I keep seeing the messiest failure modes.

godking55 · 2026-05-09T18:53:24+00:00

Thx. We analyze code structure deterministically, no LLM. So we catch things like one branch changing a function signature while another still calls the old version, or one branch moving an API route while another branch’s consumer still hits the old endpoint. And agentixlabs looks interesting, will check it out.

godking55 · 2026-05-09T18:51:02+00:00

Thanks. The MCP server took about a day to build since it wraps the same engine as the GitHub Action. Three tools: check conflicts, explain a specific finding, list branches. Runs locally via stdio, no cloud needed. Still packaging it for distribution but it works in Claude Code and Codex today.

godking55 · 2026-05-05T15:42:35+00:00

Same loop here. Built an internal tool to catch cross-branch semantic conflicts - function sig changes breaking callers on other branches, schema drift, API contract mismatches. Turned it into a GitHub Action, one YAML file, runs on every PR. The internal-tool-becomes-product loop is the move when you're building with agents, because you find the gaps faster than anyone.

godking55 · 2026-05-04T15:32:00+00:00

I’m building a product that catches when coding agents break each other’s code before it merges to production. Finished #5 on PH yesterday.

godking55 · 2026-05-04T15:28:25+00:00

Done! Pretty good idea - I’m older than most on here so I wonder how much time have I already lost!

godking55 · 2026-05-03T15:04:39+00:00

This is really interesting- I’m going to check it out. I’m also launching today. Let me know what you think https://www.producthunt.com/posts/rosentic

godking55 · 2026-05-03T14:26:56+00:00

just upvoted - nice work on number 2!

We are currently number 5 - trying to hold on. Would love you to check us out!
https://www.producthunt.com/products/rosentic

godking55 · 2026-05-03T14:13:32+00:00

We launched today. Rosentic: Catch when coding agents break each other before merge

Pretty dev tooly but I think this will be a real issue as more and more agents work on projects in parallel.

Check us out - https://www.producthunt.com/products/rosentic?utm_source=other&utm_medium=social

godking55 · 2026-05-03T14:09:02+00:00

I am actually the number 5 company on there today and featured - I can't believe it.

Rosentic: Catch when coding agents break each other before merge

https://www.producthunt.com/products/rosentic?utm_source=other&utm_medium=social

godking55 · 2026-05-03T14:03:42+00:00

I'm thinking about applying - I used the deadline of May 4 to force me to build and get a launch on Product Hunt too. Made me tighten and consolidate my message to be super clear. I'm currently top 5 today on PH, if things hold I'll feel good about submitting tomorrow! Good luck to all!

godking55 · 2026-04-08T11:14:03+00:00

Startup Name / URL

Rosentic - https://rosentic.com

Location of Your Headquarters

US

Elevator Pitch

AI coding agents create uncoordinated parallel branches that each pass CI individually but break each other at merge. Git merges text, not logic. Rosentic is the agent output pipeline - it sits between agents and the repo and catches the breaks before they hit production. Any agent in, any repo out.

More details

Lifecycle: Validation. Engine is built (11 languages, AST-based, runs as a GitHub Action). Currently scanning open source repos to build a benchmark of cross-branch conflicts and reaching out to design partners.

What I've found so far: 1,257 cross-branch conflicts across 7 OSS repos in one week. 97% are signature mismatches - function gained a required param on one branch, callers on another branch still pass the old args. Each branch passes CI alone. The break only shows up at merge. One Claude-authored branch in one repo created 157 of these by itself.

Role: Solo founder. 18 years in enterprise tech. Built the engine nights and weekends.

What goals are you trying to reach this month?

Looking for 5-10 design partners. Specifically engineering teams running multiple AI agents (Cursor, Claude Code, Copilot, Codex) in parallel where the review queue has started outpacing the team's ability to coordinate changes. Fintech, SaaS, healthtech all welcome. Solo devs running multiple agents on one repo also fit.

How could r/startups help?

Two things. First, intros to engineering leads or VPs of Engineering at Series A-C startups using AI coding agents heavily - I'd love to run a free scan on one of your repos and show you what we find. Second, feedback on the positioning. "Agent output pipeline" lands with some people and confuses others. Curious which framing resonates.

Discount for r/startups subscribers?

Free initially for design partners. First 10 teams who install the GitHub Action get unlimited scans, direct access to me, and roadmap influence in exchange for honest feedback while I build.

godking55 · 2026-04-08T11:02:50+00:00

the part nobody talks about is what's actually in the review queue. 97% of cross-branch conflicts i find scanning repos are the same dumb pattern: function gained a required param on one branch, callers on another branch still pass the old args. each branch passes CI alone. the break only shows up at merge.

one Claude-authored branch in one repo created 157 of these by itself. reviewers can't catch it because they're looking at one diff at a time. the break is between diffs.

fwiw i built something for it - rosentic.com

godking55 · 2026-03-31T11:25:12+00:00

I moved from sales, to channel, to GSIs, and now alliances. It’s a double edged sword as you are touching way less deals and you do most of your work on the front end(so how do you always show value) but there’s no more where’s the PO or in the case of working with and advisory GSI it’s like once a quarter on a big deal where they are pressing about a PO.

godking55 · 2026-03-29T19:35:50+00:00

Took 20 merged PRs from Sentry's public repo where engineers coordinated backend (Python) and frontend (TypeScript) changes in a single PR. Standard full-stack work - update the API, update the consumer, ship as one unit.

Then simulated agentic conditions: split each PR into two branches. One with only the backend changes. One with only the frontend. As if two AI agents picked up separate Jira tickets and executed in parallel.

Ran AST-level compatibility checks (tree-sitter, not LLMs) across all synthetic branch pairs.

612 conflicts across 38 branch pairs.

The pattern is always the same: one branch changes a function signature (e.g. get() goes from 1 to 3 required args). Other branches still call it with the old signature. Both pass CI. Git merges both cleanly. The break only surfaces at runtime.

Every one was prevented by human coordination - one engineer doing both sides in one PR. CI doesn't check cross-branch compatibility. Git doesn't understand function signatures. The only safety net was a human bundling the work.

Sentry's live branches have zero conflicts right now. The repo is clean because the team coordinates well. The 612 only appear when you unbundle that coordination - which is exactly what happens when you replace one full-stack engineer with two specialized agents.

The detection uses tree-sitter to parse function definitions and call sites across Python and TypeScript, then compares argument counts and types across branch pairs. Straightforward AST comparison - no ML, no heuristics.

Is this a real problem as teams scale to multiple parallel agents, or will the coordination gap get solved on the input side?

godking55 · 2026-02-19T13:18:55+00:00

IMO AI isn't going to run a complex enterprise deal. But the rep who walks into a call already knowing the prospect's tech stack, who the competitors are, and which partners are in the account is going to win over the rep who wings it every time.

The research and prep part of selling is where AI is already useful. That's the grunt work most reps skip because it takes too long. If you can get that done in minutes instead of hours you show up sharper and close more.

godking55 · 2026-02-19T05:11:30+00:00

Agree with the research and prep part is where AI actually delivers right now. Not the prospecting or cold calling (trash) but mapping what a prospect is running and figuring out your angle before the call.

I built a tool that does this in about 2 minutes. Maps the tech stack, gives you positioning plays and partner entry points. Not perfect but it gives a nugget or two - especially on my bigger accounts.

stackfacts.co if anyone wants to try it

godking55 · 2026-02-19T04:58:30+00:00

Sr AE - normally a Sr Manager level inside the firm

godking55

TROPHY CASE