AI Makes Adding Features Faster - So Why Not Add Just One More? | grith

grith is launching soon<br>A security proxy for AI coding agents, enforced at the OS level. Register your interest to be notified when we go live.

I've been shipping software professionally for somewhere north of thirty years. Field Logic (fieldlogic.uk) is the current company, grith is the current product, and at this point I've lost count of how many side projects I've started before deciding the scope was wrong and either cutting it down or quietly shelving the thing.

There's a pattern to side projects that anyone who's done a few of them will recognise. You write down the MVP. The MVP is small, defensible, and you can describe it in two sentences without using the word "platform". You build it on evenings and weekends. Six weeks in, you've built something three times that size, the launch keeps slipping, and the original two-sentence pitch has acquired four sub-clauses and a footnote.

The thing that used to fight back against that, in my experience, was time. Every new feature came attached to a roughly honest gut estimate: "a weekend, probably two, fine, three if I'm being realistic". You'd weigh the feature against that estimate and most of the time you'd say "later". The friction was the budget. Time was the budget. The budget was always tight, and that tightness is what kept the MVP an MVP.

That negotiation is largely over.

The unit economics of a feature have changed

I'm not going to pretend this is a controversial observation. Anyone using current AI coding tools seriously has felt it. The thing that used to take a weekend takes an afternoon. The thing that used to take an afternoon takes an hour. Some things, particularly the ones that are 80% scaffolding, take long enough to write the prompt and not much longer to read the result.

The honest version of how I work now, for a fresh feature in a system I already understand:

I write a short plan. Maybe a page. Sometimes a conversation with Claude where I describe the constraint, list the options I can see, and ask it to pick them apart. The output is a plan I'd actually be willing to defend to a colleague.

I hand the plan to Codex or to a Claude Code session running under grith's own supervisor and let it grind through the implementation while I do something else.

I review the diff, push back on the bits that are wrong, and ship.

It is not that this produces flawless code. It produces ordinary working code, with the same bugs and rough edges and second-pass refactors any human would generate, but it produces it at a rate that makes a mockery of the scope estimates I was using two years ago. The cost of "let me just try this and see" has collapsed.

Which sounds, on the face of it, like nothing but good news.

The problem nobody warns you about

Here's the thing nobody put on the marketing page. When the cost of building a feature collapses, the natural friction that kept your scope honest collapses with it. The implicit "is this worth a weekend" filter that most experienced developers run, mostly without noticing, stops doing its job. Because it's not a weekend any more. It's a couple of hours. And you've got a couple of hours.

So the question shifts. It used to be "can I afford to build this?" and the answer was usually no, and you'd move on. Now the question is "should I build this?" and that's a much, much harder question to answer in the moment. Because the answer almost always involves the future: people you don't have yet, scale you don't have yet, edge cases you've imagined but not actually hit. And the hypothetical version of your product, the one with all the features the current users haven't asked for, is always more compelling than the boring real version sitting on your laptop.

Time used to do the deciding for you. With time gone, you have to do it yourself, on every feature, and your judgement on the matter is biased in exactly the wrong direction, because each individual feature genuinely is a good idea on its own merits.

This is the trap I've been working through on grith over the past few months.

What grith was supposed to be - and what it is

The original plan was two-sentence MVP territory. Intercept the syscalls a CLI agent makes - file, network, exec - run them through a multi-stage filter pipeline, return ALLOW, DENY, or QUEUE for review. Linux only. Ship it.

The product that exists today does all of that, and does it in a meaningfully stronger form than the two-sentence pitch implied. The Linux supervisor works, the filter pipeline runs comfortably under 15ms P95, the audit chain is tamper-evident, the dashboard does what it should. The launch is later than it would have been if I'd held the line on the original scope. On balance, I am not sorry about that. What shipped is materially better than what was planned. The trick is being honest about which parts of the extra work made the product stronger and which parts were just drift.

AI didn't...