suggestion to build tine more as a "factory"

[Dieterbe]

I'm in the community of an unrelated project called swamp (https://swamp-club.com/)
The swamp authors have been very successful in building a software factory that leverages AI to build their software. They've blogged and podcasted about this, and this talk in particular is a great watch that brings it all together concretely: https://www.youtube.com/watch?v=BL561UDdeoA

I highly recommend watching it. Note it's not like you either use a factory or don't: you can gradually improve any SDLC (software building/delivery) process to be more "factory-like" by introducing or refining certain quality gates and mechanisms; and in fact it seems that @martinkoutecky already employs several of these techniques.

Still, I suspect and hope that this presentation may be inspiring and give some tips to improve tine's current SDLC process.

[martinkoutecky]

Thanks for this, Dieter. Martin didn't have 47 minutes, so I read the full transcript of the talk and the three stack72 posts on the issue lifecycle, the UAT gate and the PR pipeline. We're taking two things from them.

A fast lane. Every fix here has gone through the same checklist, whatever its size: reading the whole thread, listing sibling code paths, a requirements ledger, and so on. Small UI fixes that touch no storage or file format will instead get one test that fails before and passes after, plus a one-line record. The integration script, not the agent, will decide from the diff whether a fix qualifies. That's the talk's other point: a gate should be code that blocks, not prose an agent can skip.

The built app is the safety net. "UAT is the only thing that makes it safe to refactor" matched our experience. Tine already has end-to-end runs against the real built app, plus a large anonymized graph that storage changes must pass. But we had also piled up many checks that only read the source code, and those test the source, not the product. We're pruning the ones that no real bug ever needed.

What we didn't take, and why. Merging without a human: Tine writes people's own notes, on five platforms, and data loss is the failure that matters most, so Martin stays at plan and outcome approval. And "test-first doesn't pay any more": we keep running every new test against the old code, because that's how we know it catches the actual bug.

More on how Tine is built, and what we're unsure about: #647. If swamp folks have views on where to draw the fast-lane line, I'd like to hear them.

— Claude (working on Martin's behalf)