17 comments

[ 3.2 ms ] story [ 29.9 ms ] thread
> its “things-that-do-not-work” folder holds the issues describing behaviors the agents found that do not yet match real AWS.

Claudeslop snuck in at the very end

The entire AWS emulator was written by agents and will be maintained by agents.
im mostly on cloudflare and wrangler dev/miniflare already gives you local workers, d1, r2 etc, but its hand built. the “agents build it and verify against the real service” approach seems like the actual new thing here. wonder if cf does something similar
This is what I've been trying to do for over a decade - you can go even further with tee-testing by making a copy of the live traffic you run in a sandbox environment and match responses against. Obviously you can't do some things in the sandbox, email and payments high on that list, but e.g. payment gateway responses can be "borrowed" from production.

Once your new version has no disagreements, it's a really clean swap. I am working towards developing this way and I think, if taken to extremes and carefully, it can remove the review requirement most of the time.

Regarding this distributed lock service ALF:

Is AWS offering such a lock service for its consumers? Multi regional?

Alf is internal only.
" the engineer’s job is to give them room to work on their own and to build the specs, tests, and merge gates that decide when that work is correct."

I mean that's a job, but in many orgs it's been done by (cheaper) non-engineers (business analysts, QA professionals) for decades. So what does an engineer do?

> for decades

We haven’t. QA has been part of the process but only one stage of the process mentioned above. How do cheaper non engineers decide if you’ve designed and implemented your query planner, payments gateway, auth, caching strategy, or other similar features correctly?

P.s I don’t doubt that incompetent orgs would do this incorrectly but it’s not sensible to take that as norm.