gojkoa

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.

This is a minimal boilerplate so that part was excluded but in the real setup this was extracted from we use AWS SSO from the CLI to authenticate against AWS (short-lived tokens) and the keys for other things are in the AWS SSM parameter store as secure strings (encrypted), locked down with IAM so that agents can only access specific (test) keys while developing.

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.

if you have a profitable business, and don't have previous experience selling, there are three options:

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)

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

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.

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.