I've done some research around this for an upcoming book, and generally people who benefit from orchestrators are those that already have a solid regulation framework in place, where agents can get feedback quickly on most of the work, where deterministic guardrails (hooks/custom tools) are in place to keep the agents in their lane and where people invested a decent amount of time in making the agents run securely and know what they can or can't do (avoiding approval fatigue). you need all those prerequisites to make orchestration work well. once that's in place, running multiple agents in parallel doesn't burn man hours, but it can still burn a lot of tokens.
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
definitely. we built a custom eslint parser for scss, html, liquid and yaml and are using it to validate all sorts of rules that were previously just in people's heads. now they are codified and provide instant feedback. if we stopped using AI now, those would still be incredibly useful for human coding.
I'm working for myself (own product, decently profitable SaaS, been in production for 7 years now and used by actual customers), so I'm not sure if I fit your "employed" category or not. If I do, then here's my setup:
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.
the problem with user guides in general as a driver of specs (this is coming from surviving two such attempts 20 years ago) is that user guides tend to be written for an external audience, hiding a lot of complexity and underlying details. Sometimes this is to keep user docs focused on a specific task, sometimes this is because you don't want to disclose internal workings of a system to users).
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
great points! The difference between using this system and a spec is exactly as you said, to capture the user outcome first and work backwards from there. I don't like specs in general because they are prone to become bloated with implementation details, and they never worked as a reliable source of truth in my experience, even prior to the AI generated code.
Your points on impl. complexity, backend processes and cross functional concerns make total sense. I'd try approaching these from an end experience point of view as well. For example, the operator guide could detail steps to run a benchmark tool and inspect performance metrics. I am not sure how much that can cover though, but the core idea is that end users, admins, operators, devs are all users of the system and their experience is documented first.
The feedback cycle got a lot more segmented, as we try to catch different types of issues and get feedback as early as we can. For example, UX review is now before everything. Claude builds static demo pages for how the app will look once the changes finally land, and then there's an audit script which runs through those to measure contrast/visibility/accessibility for all elements in focus/hover/dark and light theme etc. when that passes, a human looks at the demo pages to check if the design makes sense, and iterates on that. once a human is happy, the implementation work starts. before AI, UX review was usually part of exploratory testing after implementation, but now it's both cheap and necessary to do upfront. The demo pages become a part of the spec, and they are a baseline for automated testing at the end.
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.
Whois lookup gives you the first point of contact of domain ownership. These days, most will sit behind an anonymizations service but you may get lucky and find out contact info there. If they are anonymized, and you have a legal claim, get in touch with the legal contact shown there.
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.
So I came across a website that falsely copies google reviews and trying to lure people to sign in to them and the target participants are parents. I reported the review copying to google legal already but I was trying to find who is behind the website. They are using school avenues like school watsapp group to promote their website and hence I am concerned.
EFF and sfconservancy exist, they are probably closes to what you can realistically get in this environment. They are are non profits that can try to influence policy but not much more to "protect" individual developers.
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.
small tech here - 2 people, site with ~1-2m active users per month. We do A/B tests for the majority of changes that could affect engagement or conversion. The infrastructure and plumbing is cloudfront assigning cookies and serving different HTML based on a cookie, and cloudwatch logging user interactions with the cookie included into timestream, where I can run queries manually (no automated resolution, decision making, rollback etc). An A/B test usually takes about a week to accumulate enough traffic for confidence, and we don't run them in parallel.
Each A/B test gets a dedicated expectation criteria (so we have no overall evaluation criteria that stays stable across tests). So in the "Experimentation Maturity Model"[1] language, we're kind of in the "Walk" phase.
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.
Thanks for the link. Very succinct. Coincidentally, just a week back, I ordered the book it mentions.
I completely agree with everything you mentioned (And thanks for giving in numbers too!).
Since you’ve clearly thought this through, if I can push you to the hypothetical - at what point would you want to run multiple tests in parallel? Will it be largely a function of your dev team (more productive everyone) or active users (more frequent feature build outs / cross cutting rollouts) ?
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.
We keep manual QA for non-deterministic, exploratory stuff, things that do not have an expected input and output and where spotting secondary information and insights (e.g. "why is the chrome network console logging so much when I click on this button?"). things that have a deterministic input and expected output get automated. This whole area is a terminology minefield, but one term I like from the context-driven testing community for category 2 (deterministic) is "checking". The term I like for category 1 is "exploring". If a computer can "check" a post condition given some preconditions then a human does not need to waste time on it. If you need up to go after sidequests and look for unknown factors, it requires a human to explore. Having said that, there is a role for automation to speed up exploration (e.g. record a flow through the app for some key scenario, so a human can play it at 10x speed, prefill data to bring up an app into some well known state for exploration etc), but the judgement stays human. If the QA is flooded with tickets for exploration, giving them tooling to speed up data setups, cleanups, reviews etc might help.
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.
Adding "sign in with google" and "sign in with apple" (especially google with FedCM) gives you auth with the least amount of friction you can get, since they end up being one-click events for most users.
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.
I really wanted to avoid Oauth providers and keep the auth in-house only. For a more serious site like an e-commerce or a SaaS sure, but for a very low stakes site I wanted to see what's possible with minimal 3rd party dependencies.
I'm sure many users prefer the Google/Github/Apple/Twitter? buttons, and the moment they see a email+password only wall they bounce, but I think that offering a username + auto suggested password is a superb UX.
I wanted to hear if someone who went this route later regretted it, or if they are happy with it and how they solved the problems that may appear. Mainly abuse and forgot password flows (just count that user as forever gone?).
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
reply