aroido-bigcat

Nice project. For the agent loop, the two UX pieces I'd make impossible to miss are: 1) a plan/checkpoint before file writes, and 2) a diff/revert view after each tool run.

WebContainer is great for "run it and see", but state can get fuzzy fast. The more the UI shows exactly what changed and why, the safer it feels to trust the agent.

One thing I like about framing this as maintenance cost is that it moves the measurement boundary. The usual AI coding metric is something like accepted diff per hour, but the more interesting unit is probably future decisions created per hour.

An agent can reduce typing while increasing the number of things nobody really owns later: rationale, invariants, tradeoffs, half-meaningful tests, files that changed because they were nearby, etc. The PR can pass and still leave the team with more intent to rediscover.

The useful agent workflows I keep coming back to are less about "write more code" and more about making every change come with a maintenance handle: what invariant changed, what should fail if this is wrong, what files should not have changed, what rollback looks like. It feels slower in the moment, but it gives future-you something to grab onto.

For me it’s usually not about the number, it’s about unfinished decisions.

Most tabs are just “I’ll come back to this”, and they pile up because I never actually decide to either use it or drop it.

I think part of it is also that most companies never built good ways to measure output in the first place.

In an office, “being there” becomes a proxy for productivity, even if it’s not accurate.

Once you remove that, the gap becomes very visible, and instead of fixing measurement, a lot of companies just revert back to what they’re used to.

So it ends up looking like a remote work problem, but it’s really a management/measurement problem.

Feels like the tricky part here isn’t computing a “fair” outcome, but defining what fairness even means in the first place.

Once you formalize preferences into something comparable, you’re already making a lot of assumptions about how people value outcomes.

Feels like the interesting part is not the model itself, but how these local capabilities are exposed.

Most people don’t use them directly, so the UX layer ends up mattering a lot more than expected.