Your analogy here is apt because AI-native teams are the ones that are doing the impossible. I know 4 non-technical solo-founders (all had previously courted me pre-AI coding to be a technical co-founder) that are effectively shipping real products with no engineering team. One has 4 large universities signed.

These guys are all-in on AI because they could not exist without it; by necessity every leg of what they do is AI.

Floci[0] has been great for me. Use the Testcontainers[1], too.

Bonus: works for GCP and Azure, too (so far have only used in limited capacity, though).

[0] https://floci.io/

[1] https://testcontainers.com/modules/floci/

Edit: The current one: https://github.com/aws/aws-emulator/releases/download/v1.0.3...

You can get some idea if the product name is unique enough with and looking at each of the related test scores.

And output something meaningful for some of the more popular services:

  Service            Tests  All  Happy  Reject  Ctrl  Data  Solo  Integ  Wire#  Wire%
  -----------------  -----  ---  -----  ------  ----  ----  ----  -----  -----  -----
  Data Firehose        288  77%    85%     91%   92%   72%   89%    59%     24    62%
  SES                  132  72%    65%     79%   79%   42%   79%     0%     21    52%
  EventBridge          889  71%    74%     64%   72%   68%   83%    67%     75    84%
  KMS                  432  70%    82%     69%   81%   68%   97%    36%     69    84%
  Step Functions       907  70%    79%     53%   69%   67%   73%    65%     68    76%
  DynamoDB            1437  69%    70%     61%   62%   65%   82%    53%    243    62%
  SNS                  594  69%    72%     55%   62%   68%   75%    65%     39    69%
  SQS                 1480  68%    70%     67%   61%   68%   94%    62%     29    45%
  Secrets Manager      414  68%    78%     65%   66%   72%   79%    57%     26    77%
  Cognito UserPools    781  65%    67%     66%   82%   36%   75%    33%    193    64%
  S3                  2488  62%    62%     57%   61%   57%   83%    51%    296    68%
  CloudFront           627  62%    62%     63%   70%   46%   71%    41%    190    22%
  API Gateway         1009  61%    64%     59%   77%   41%   75%    43%    200    73%
  SES v2               210  61%    63%     59%   75%   48%   77%    40%     44    30%
  Route 53             130  61%    63%     59%   62%   53%   69%     0%     49    67%
  CloudWatch          1186  60%    66%     51%   66%   53%   77%    36%    152    55%
  ECR                  392  60%    55%     75%   67%   49%   87%    27%     74    65%
  Kinesis              380  59%    69%     44%   63%   50%   62%    54%     25    44%
  IAM                  991  58%    63%     50%   60%   34%   78%    41%    228    57%
  Batch                274  58%    62%     59%   78%   20%   65%    17%     19    47%
  CloudWatch Logs     1016  58%    61%     54%   71%   47%   78%    41%    185    59%
  OpenSearch           342  57%    62%     52%   70%   29%   59%    50%     98    48%
  API Gateway v2       292  57%    64%     52%   74%   38%   73%    33%    107    27%
  EKS                  349  57%    60%     52%   65%   10%   59%    38%     55    62%
  Glue                 646  54%    51%     55%   66%   32%   69%    40%    155    43%
  Lambda              2808  53%    53%     42%   58%   48%   48%    54%    171    42%
  ECS                  808  51%    45%     52%   62%   23%   62%    34%    118    44%
  Redshift             241  49%    57%     47%   53%   52%   47%    57%     50    46%
  STS                  218  49%    58%     46%   56%   30%   57%    34%     22    50%
  ELBv2                596  45%    43%     47%   55%   19%   58%    30%    111    63%
  RDS                  659  43%    54%     45%   54%   35%   51%    31%     99    28%
  ElastiCache          186  42%    43%     49%   54%    0%   47%    17%     27    41%
  EC2                 2043  40%    35%     36%   39%    5%   44%    32%    429    33%
  CloudFormation      2019  36%    33%     31%   30%   40%   78%    24%   2161     3%
  AppSync              419  34%    35%     35%   54%    1%   44%     0%     91    13%
  SSM                  566  28%    28%     27%   27%   25%   26%    30%    175    11%
  Athena               420  22%    20%     15%    7%   28%   16%    37%     37     0%
  EC2 Auto Scaling     440  21%    19%     23%   19%   18%   21%    20%     89    16%

Edit: Also worth a look: https://ministack.org/blog/aws-emulator

They'll have something like this:

    MySchema:
      type: object
      properties:
        enum_member:   { enum: [foo, bar] }
        enum_member_2: { enum: [quz, qux] }
      if:   { properties: { enum_member: { const: bar } } }
      then: { required: [enum_member_2] }

So your Rust API is full of Option, and it gets really annoying when you're testing things like say Bedrock, which takes 10 minutes, and then fails because what you submitted 10 minutes before doesn't match their schema.

I understand this can be fixed by reading the documentation in more detail, but it has gotten so verbose, and sometimes you just want to start something.

I suspect this is built by agents through bleeding the soul of GPUs until it gets too expensive (unfunded mandates are free after all on the OP1/2). Then it just decays into the place all good PR/FAQs decay once their sponsors are promoted, burned out, or are laid off.

Official statements made by a company are still poor representations of their current business plans, and don't mean anything 3 months later (no matter how much they pinky promise). But a HN post isn't even that.

That said, it’s been announced publicly here: https://www.aboutamazon.com/news/aws/how-autonomous-ai-agent...

Additionally Swami, our SVP of AI blogged about it separately and our CTO is tweeting about it - which is more than a number of products get in terms of coverage.

I think this is a super interesting direction, but how can we trust the accuracy of this simulator? Agentic loops are great and all, but they can still miss plenty of things.

Or maybe a better question: where is the accuracy of this simulator going to be guaranteed enough that we should trust it?

Like, what am I actually getting here? Is it just happy path operations being correct here?

Hopefully AWS has had enough internal guinea pigs before they published this!

The border between AWS and AWS emulator becomes fuzzy. And the users of AWS will be agents as well. A completely offline emulator will save a lot of resources and could be a great training ground for more focused (offline) models.

This feels like table stakes for an emulator.

It’s actually interesting that such a thing exists. It’s in Amazon’s interest that the only way to test a lot of services is to have a test environment in AWS.

> It’s a real product that we plan to maintain.

29,684 commits in a repository less than a month old does not instill confidence in this being a "real product." That is roughly 1,000 accepted commits per day.

[0] https://aws.github.io/copilot-cli/

Google builds up a product over time and abandons it. This is annoying for long term adopters.

AWS has a habit of throwing a bunch of products at the wall, but only bothering to maintain & build up a few of them. This is annoying for early adopters.

Not many, and not often but it is annoying.

The Copilot CLI https://aws.github.io/copilot-cli/ you can feel polish and pride of the team that built this, as an example.

For the AWS people behind this, it means going the extra mile(s), with a level of care and depth that you typically mostly see within great startups. Perhaps agentic coding will enable AWS to reach this, perhaps it will stay relatively abstract.

I didn't have a good experience with test containers, but perhaps it'd work better with fast starting containers. We run our test fixture with compose, and have the tests manage their data in isolation - so we don't pay the startup penalty in our test suites.

I think I'd trust this project at least as much as Floci. Embedded Rust mode also looks very interesting for us.

    > How we built the agents that built AWS Emulator
    > Thousands of autonomous AI agents wrote every line of code in AWS Emulator, a new local emulator for AWS now available for download. 

Doesn't feel like a real product. But I also didn't look very hard for docs; I kind of expect it to be linked on the GH in the site and have a nice `llms.txt` for me to give to my agents.

The product documentation is here: https://docs.aws.amazon.com/emulator/latest/userguide/what-i...

While the GitHub project is young, the internal effort to build this has been going for quite some time now.

> Doesn't feel like a real product. But I also didn't look very hard for docs

You should try, they're there.

> I kind of expect it to be linked on the GH in the site and have a nice `llms.txt` for me to give to my agents.

There's an official Amazon Documentation site that's linked. There's also an `AGENTS.md` file in the repository.

This post https://www.aboutamazon.com/news/aws/how-autonomous-ai-agent... doesn't set the right tone for me at all and it has nothing to do with agents and everything to do with the lens of looking at this as a science experiment instead of a real enterprise tool.

This feels like such a weird nit-pick when AWS is criticized for not moving quickly enough. Why should I care if there's a link in the side bar, when there's plenty of links in the `README`? If anything, I'm happy that there's alternatives to Localstack that are supported by AWS themselves that I can begin incorporating. They have a well written `README` that I can start working with and a User Guide to get me started. What else could I want?

> Did you look at the blog post as well?

I did.

> Does it look like a product that some team there loved and will care for? Or the output of some exercise for some enterprise content?

Do you even have the grounds to cast judgement like this when you admittedly didn't even look hard enough?

This lacks polish.

Small details like getting your GH repo set up for a public audience. Lacking. Compatibility and support matrix clearly advertised? None.

If this public facing artifact exhibits a lack of care and love, what does it say about the code? I am all for vibe coding and agent software factories, but then the humans should show some love with all of that extra time saved.

Look at Floci (I have no affiliation) https://floci.io/ the blog https://floci.io/chronicle/ and the labs https://floci.io/labs/

Do you agree that there's a polish here that shows a team's pride in that work that is clearly missing in this work?

    > ...especially when engaging with (presumably) actual AWS employees in this thread replying to you

No and I think the inverse is also possible and if anything more likely. You can make a website look really pretty, really easily and have the product still suck. This is "product as a slide" in a new age where making visual eye candy with AI has never been easier.

> I do not care if their feelings are hurt because this "product" clearly shows a lack of polish and love.

The point isn't about hurting feelings. The point is about providing critque and feedback based in reality, not based on "vibes." You're trying to gatekeep people releasing software because you dont like the way they're launching it lol.

??? It's in bold just before the "Quick start" section

The team didn't even take the time to review these small details of the repo, you know, by editing the repository details to place the docs URL there.

I mean, I don't know about you, but I feel like I still like to see people care about the stuff they produce and missing something as basic as the repo website URL in GH settings shows a lack of polish and love.

    > As for TypeScript? Absolutely loathe it.

The main things I don't like about TS are the volatile tooling, bad habits from other devs (not declaring types), compromised ORMs, require lots of package hunting, and module system.

Language is fine, tho.

AI is great at following patterns and loves to write tests. Start with good patterns that most teams would not have the discipline to write by hand and it is possible to get very robust code.

Try:

    - Clearly identify the invariant being tested focus on exercising the invariant
    - High volume, low signal tests increase CI and build times
    - Avoid low signal tests; raw coverage is not the objective
    - Avoid write-then-read tests when risk is low (no transformations, no business logic in application code on write or read path)
    - Use explicit test execution [Explicit] when test code is used to exercise code in local environments only and should not run in CI

You also need to understand why agents write high volume, low value tests: because other ways of exercising the code (e.g. Playwright, E2E, curl) are even more expensive and not as consistent. So you have some recourse here by: 1) giving agents another way to exercise the code (e.g. provide it a REPL to your code) or 2) tell it to write some unit tests as explicit only (does not run in CI).

For our tests, we also added a small helper library[0] that cleans up tests to make them easier to read (smaller context for both humans and agents) as well as to write. Agents write average code by default. Your job as an engineer in this age is to help agents write good code.

[0] https://github.com/zeeq-ai/zeeq-biome

    > VCs can't hop on a flight to do some due diligence?

Asking them to operate in new jurisdictions requires a lot of effort and legal know-how; it's not just a matter of cutting a check, but understanding how to navigate the legal landscape for these financial transactions, rights of the investor, tax implications, legal recourse, etc. There's going to be a lot of friction such that they'll either: 1) not seek those opportunities, 2) ask the founders to move to the US if it's a really promising team (see this a lot; was in one startup where a co-founder moved from AUS to the US).

Melanie Perkins talks a bit about this in the Canva episode of How I Built This[0] and how SV wanted them to relocate. AUS government ended up matching some of the investment through a new program so they reached their target for their raise.

[0] https://www.npr.org/2021/02/26/971813519/canva-melanie-perki...

    > A trading floor is a bad place for unreviewed code written by people who can't read it, and the information barrier problem would be reason enough on its own. Requiring that agent-written code come from people trained to review it is a sensible rule for a regulated business.

Agentic engineering needs to be "all in".

To deal with the volume, the system needs more checks than humans can handle. Additionally, the humans no longer understand the details at the low level of implementation at scale. Therefore, the system only needs to assert that it is following agreed patterns.

So the initial scaffolding needs to be agent friendly. The processes need to be aligned to agents. The tooling needs to be agent operable and put on rails. The patterns need to be documented to be enforced.

Otherwise, teams get volume that cannot be handled by humans. So full speed agentic engineering requires teams to be all-in.

A piece of this is to leverage the harness to normalize or standardize output. Standard patterns, standard architecture, standard UI libraries. These are all much easier to enforce with agents than with humans, but requires extensive platform and harness engineering.

Teams do not really understand this yet. Engineering teams still think their job is to build product faster. By the 10th time you tell an agent "implement issue #15639", you realize anyone could have done that. Engineering's job now is to own the enterprise harness (context layer, ephemeral agent env, ingress channels, auth proxies, MCP servers, quality gates, agent ops, etc) so anyone can build the product. That's what "all-in" means.

Once this system is set up and well executed, it really doesn't matter who writes the initial prompt. An enterprise harness designed to enforce safety, security, and best practices applies to a senior dev or a junior dev or a product owner all the same. All-in on engineering the enterprise harness, not the product.

You have to go all in on agentic engineering. And if you're all in on agentic engineering and doing it well, then anyone should be able to build safely and no one needs to look at code. The code should look highly consistent and agents should be enforcing best practices, approved architecture, running security scanning, etc.

The gains at the middleground compromise are not really significant and, IMO, creates frustration and friction.

Works best to go all in. GS should let everyone have CC and GH and focus on making their enterprise harness safer for everyone.

And, no, it doesn't actually work. Agentic engineering is a myth by people who got high on their own farts.

Key is to get folks to unload their heuristics and rules they use for their daily workflow and judgement.

What does good code look like? What are you looking for when reviewing code? What anti-patterns are your senior devs looking for? How can you see the evidence of agent adherence?

Some of it comes down to system architecture and essentially creating rails. Agents are very good at following patterns and copying existing code (it's all just text). Establishing strong patterns, documenting them, and creating deterministic checks (linters, analyzers) helps unlock broader audience of builders.

There's nothing that fundamentally cannot be written down as a set of heuristics and given to agents to enforce except that most folks in software are very bad at writing.

This is just adding wishful thinking to the pile of trash.

In a single session? Agree. The agent is bad at enforcing rules against itself. In a multi-agent, disconnected session setup? You'll see that this works very well.

Rules and code are both just text, after all.

Fully switched from TUI 4 weeks back while testing it out for another use case.

Wrote about my setup here: https://chrlschn.dev/blog/2026/10/larping-with-agents-and-wh...

Open models: we're already seeing this at some scale. https://news.ycombinator.com/item?id=50350004. I do expect to see more of this.

    > ...a problem I've had with RAG - when a fact isn't local to a single patch of text

    > GitHub ToS actually allows that since April

3. Account Requirements

We have a few simple rules for Accounts on GitHub's Service.

You must be a human to create an Account. Accounts registered by "bots" or other automated methods are not permitted. We do permit machine accounts:

A machine account is an Account set up by an individual human who accepts the Terms on behalf of the Account, provides a valid email address, and is responsible for its actions. A machine account is used exclusively for performing automated tasks. Multiple users may direct the actions of a machine account, but the owner of the Account is ultimately responsible for the machine's actions. You may maintain no more than one free machine account in addition to your free Personal Account.

One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine).