humans supervising agents, not dark factory where agents supervise agents. providing a very high degree of automation, not fully automated. controls implemented using deterministic tools, not via markdown prayers.
40 karma · joined July 12, 2026
The agents are running inside a docker container (this is part of the setup) and only share the workspace and tmp dirs with the host. They run under user permissions in the container, not root.
1. aggregators and small PE (sureswift, tinycapital, mudbrick group, sass.group, fullstack capital) that buy smaller SaaS and then consolidate support/operations etc
2. brokers who will help you sell the business, kind of like a realestate broker (quiet light, FE international)
3. maketplaces (sideprojectors, microaquire, flippa)
I wrote something recently on how we made the orchestration not burn that many tokens at all. With a few deterministic tools we got the token cost of orchestrated workflows down by 80%. Check out https://news.ycombinator.com/item?id=49587379
1. I have a custom-built minimal flow of 5 "commands", that take an idea to implementation through capturing intent, impact analysis, iterative planning, execution orchestration and then review/demo. each of these effectively builds up a single shared plan file. The intent command takes one or two lines of free text and turns it into a structured intent document (goals/anti-goals/constraints...); impact-analysis takes the intent document and maps it to the codebase, looking for functional gaps and things that need to change. iterative-planning takes the result of the impact analysis and splits into tasks/phases that are independently verifiable and deployable, and builds a task list... so they all build on each other, and update the same plan file that sits in git and I review it as it goes through the pipeline
2. we have a minimal CONTRIBUTING.md that explains the shape of the workspace and the key rules how to work, that's applicable to humans and agents. CLAUDE.md loads it from @CONTRIBUTING.md
3. the guardrails of what the agent is allowed or not allowed to do mostly sit in deterministic tools, such as custom linting rules, custom style checks, and they are all invoked from eslint via the custom language plugin. this has grown to thousands of rules, linting programming language code but also html, scss, yaml, liquid, markdown.... Eslint runs as a post-tool use hook on edit and write, so each file an agent writes gets immediate feedback and fixes. when we catch the agent doing something it should have not done with the code or docs, we get it to write another custom rule with unit tests for the rule. With each rejection Claude also gets a helpful message what to do instead.
4. there's a "regulator" script that helps us avoid decision fatigue for approvals. it runs as a pre-tool use hook for Bash commands, does deep parsing of whatever sausage Claude wants to run, goes into loops, function definitions etc, then goes through our rule set and approves/rejects or forces an ask. With each rejection Claude also gets a helpful message what to do instead. (e.g. don't run npx, use eslint directly from the path). Each time claude asks, we run the command through a debug script to understand why it's asking, and add another rule.
5. the latest addition is an orchestrator script that takes our plan file format and turns into Claude Dynamic Workflow descriptions deterministically, and parses the progress of the workflows so suggest what's slow and what can be moved out of LLM processing to deterministic tools. This significantly reduced the token spend (now running at about ~20% of the token spend for workflows before) and time (from average 5-6 hours per workflow to about 20-30 minutes). It also removed the 10-15 minute wait that we had while claude was LLM constructing workflows from our plans.
6. there's a demo command that flies through the user interface based on the plan to demonstrate what users see with the new version, recording it to webm using playwright, and I can play it at a higher speed to quickly get an overview what an agent did.
7. we tend to look for ways to get faster feedback on things that agents repeatedly do badly, such as UX or UI changes. We have a set of static HTML pages with the visual design language, showing styling for key elements and components, and a set of static demo pages showing key application pages with realistic data in lots of different states. as part of the impact analysis, agents will update demo pages or add new ones so we can review/complain. there's a script that audits demo pages for WCAG and other styling issues. another example are end-to-end api tests, which evolved massively to prove api contracts but also allow agents to get their own feedback and troubleshoot quickly. generally, divide and conquer for feedback.
This tends to work generally well. I feel productive. I still review most code when it completes via git diff, but it's mostly clean because the linting rules are forcing it to write code the way I want it to be written. We use a method based on the attribute-component-capability matrix to figure out what needs manual exploratory testing and how much, and do that in addition to automated tests when needed.
happy to provide any more info if you're interested.
Specs can influence (and potentially be even a source for generating parts of) user docs, but user docs can't replace specs.
On the other hand, the idea to write the guide, do mockups etc first is a great way to think through what the user would experience before you do the specs. We have something similar with agents creating demo pages so we can check them, and they become parts of the spec (and something to match the final product against).
But that's not a good fit for backend processes, cross-functional concerns (performance/security) etc, or things you do because your business needs it and not the users (payment fraud prevention) that also need to be specified
Lots of rules and checks evolved from common feedback and now work in custom linter rules, custom checkers, custom-built rule engines to prevent Claude from making similar mistakes.
Similarly to you, we have a "demo video" skill that records a flow through the app demonstrating newly build functionality so a human can look at it at a higher speed and notice if there's something obviously wrong, before doing exploratory testing.
If it's a relatively established website, they likely have a trademark on the name, so the next point of call would be USPTO or WIPO to search for that trademark. That usually gives you non-anonymized data.
Unions (at least in theory) have a way of bringing an employer to the negotiating table by getting a large enough portion of the employees to stop working and bring the employer's business to a halt. in the days of factory picket lines, they were able to prevent other people from working even if they wanted to. this is what gives a union negotiating power. I can't see anything similar for OS developers. What would be the threat? "We'll stop giving you free code?"
regarding a protection union, what you're talking about seems to be legal insurance, and that already exists, but it's significantly more expensive than $20/month.
1) running multiple tests in parallel becomes important where the product/dev frequency exceeds waiting for a single test to finish, which is roughly a week for us. the business is currently relatively stable and doesn't change a lot, and I don't have big ideas that would need measurement so frequently, but if I did, I'd probably look for ways of running things in parallel. So I don't think it's a function of the dev team as much as what you reasonably want to measure. Having said that, I can imagine a larger dev team implying multiple product people, and those might want to have their own experiments/ideas measured in parallel, so there is something there definitely about the size of the dev team as well
2) if we wanted to be very scientific about the whole thing, we'd need multiple tests in parallel, particularly for novelty/primacy holdouts and to reconfirm that certain things actually hold across time. e.g. if I decided that variant A is better than variant B but our traffic changes (which it kind of it did over the last 3-4 months with AI overviews killing clicks from Google), maybe the reduced set of people we get behaves differently than the larger set we measured against a year ago. so I'd probably want to re-run critical experiments and just confirm them.
The overhead is not really significant, as the whole thing is pretty much automated now. We just have two different versions of HTML built and deploy cloudfront by turning on a parameter in the deployment template which pages to split for A/B.
I definitely feel it's worth it. Tweaking things on the homepage brought a measurable 17% increase in conversions. Testing out a redesign of a key component of a proposed redesign showed that we'd be significantly damaging engagement. Lots of results contradicted my intuition over the years (in both directions). Because it's easy to spin up a test, I tend to do it whenever there's an important decision to make.
Our ad-hoc setup prevents us from reliably running multiple tests in parallel, and we do not have any kind of systematic measurement for novelty and primacy effects, but at the level and complexity at which we operate that's fine. I treat test results as more evidence/confidence, not as final evidence. If the test looks OK we'd deploy, then still monitor if the key engagement metrics go up or not, and if not we'll roll back. This happened more than a few times over the last few years. In theory a more systematic platform helps to prevent that, but even then if you aim for 95% confidence, this means that 5 out of 100 decisions you made are probably not justifiable, so it doesn't absolve people from follow up monitoring and judgement. We did A/A tests and holdout testing for a bit but gave up on it (since it's difficult to run multiple things in parallel with our setup, then an A/A test or a holdout would delay further experimentation).
> Trying to understand at what “scale” does A/B testing make sense for organisations
My thinking about this is that when the traffic you have crosses the threshold where you can get meaningful results in a reasonable time (few weeks). Before that it's just numerology. You'll get some numbers, but they can't really drive decisions reliably.
[1] https://www.votito.com/methods/experimentation-growth-model/
I've picked up a framework for deciding what/how much to test manually from James Whittaker's ACC matrix a while ago, and it's been incredibly helpful to create a policy around when something requires manual testing, how much and what the manual testing should actually cover. It's covered reasonably well in the book "How google tests software". Having a policy around that means that there's no misunderstanding what gets automated and by whom, and what's left for exploring and by whom.
Having said that, none of this prevents people from creating fake accounts. On our system I can see people regularly signin in with multiple google accounts, with incrementing digits in the name, trying to abuse the free tier. You'll need to build something yourself for that, depending on your risk surface. For us this involves tracking requests across IP addresses, blocking free access from data centre IPs, blocking bots using AWS WAF, analyzing task patterns to spot people who use multiple residential IPs and a bit more.
It's quite sobering to look at the list of active versions and see a long tail of what's actually connecting to our backend.
- When responding to the user, respond in ASD-STE100 English. You can extend the dictionary if you need, but respect ASD-STE100 rules as much as you can.
- When writing comments, technical documentation and internal documents (roadmaps, plans, design references) use ASD-STE100 English. You can extend the dictionary if you need, but respect ASD-STE100 rules as much as you can.
- When writing plans: no timeline estimates, no complex code. unless specifically requested, no deployment sequence. use pseudo-code only for non-trivial operations where clarifying complexity is crucial
- feed from people I actually follow, in an actual chronological timeline (not optimized for engagement, not deprioritized because it has an external link)
- topical feeds with topical filters (e.g. I don't care about politics but care about tech news)
As internet became more hostile and social networks started hiding posts to external sites, I ended up posting a lot less frequently, so the blog mainly became a place where I could put a longer explanation or a reference, effectively to stuff up to point people from workshops and short conversations more easily. From that perspective, a blog really helps me clarify my thoughts about something so I can force myself to research it in detail. The way I write also shifted because of this. Early blog posts were more like a presentation or a story, now I mostly write stuff that's like a reference.
I get it that some people don't know how to write shell scripts or IaC templates, so in theory maintaining a LLM skill is easier than maintaining a makefile, but if you have a coding agent available, it can do the updates.
I treat comments inside code as smells. They exist sometimes because the author wanted to say something else but was prevented from doing it because of existing conventions, sometimes because a piece of code is difficult to understand, sometimes because a large piece of code has multiple responsibilities. For things like that, I tend to clean up the code to make the design more intention revealing and break large pieces of code into smaller pieces with appropriate names. I tend to document behaviour using unit tests (where the unit test has the name that would be in the comment). This was a rule before claude code, and it still is for us.
In general, this leads to better code, that's easier to understand, manage and maintain. It also leads to functional decomposition that's easier to test than a large blob, so fewer bugs.
We have linting rules preventing claude from leaving comments inside code, and forcing it to apply these refactorings. The one to write tests to document behaviour instead of just commenting it is especially useful as there's proof that the code is actually doing what the comment suggested, and ongoing checks that it still does that. a comment may become stale easily without you noticing.
as for the reason why claude is doing it, my best guess is training material included lots of comments.
I’ve tried it from safari on an iphone.
Don't pitch the product, talk about researching for the product (which is what you'll be doing anyway, but some of those initial interview people may become your best advocates). People that genuinely have the problem you want to solve will want to help.
Steve Blank has a nice segment on the ideal people to involve here in The Four Steps to the Epiphany, calling them Earlyvangelists. One big thing to look for is that people have identified a problem that you're solving, tried to solve it themselves, and in an ideal scenario have a budget for a better solution (see https://www.votito.com/methods/earlyvangelists/ for more).
_The Mom Test_ book is an excellent interview guide for this stage, and you'll figure out the questions to ask from there. here's my checklist from when I used it a while ago (not verbatim from the book, so best to actually read the book).
- how do you currently solve X - and how much time do you spend on it? can you show me how you do it? - what happened the last time X came up? talk me through the last time it happened. - if not solved, why not - have you tried finding a different solution for it? - why do you bother doing it? - what are the implications of that? - what else have you tried? - who else should I talk to? - anything else I should have asked?
to find if the problem you want to solve even matters at all: - how much time do you spend on it each week? - which tools and services are you using for it? - what have you already tried doing to improve this? - what are the 3 big things you’re trying to fix or improve right now?