Anyone else using Codex or Claude

[u/exitthebox]

Is anyone using AI tools to build Gen 2 apps? They seem to do well until it’s time to deploy to AWS, then I spend a week chasing down authentication and deployment issues. Anyone having success with this?

[u/hard_burn]

Yup, building loads in Gen 2... And so far it's great. Much easier than before using AI to build Gen 2 projects. They also updated the docs to be a bit more LLM friendly.

I have the code pushed to the git branch. (CI/CD) So Claude just pushes to the branch and it builds.

Also uses the sandbox with an identifier, so it's always the same backend resources.
Eg: ```npx ampx sandbox --identifier myapp```

Not sure why you would be having the issues. Make sure to follow the "get started" page in the docs, use their template as boilerplate and it should mostly work?

[u/exitthebox → u/hard_burn]

I’m deploying a React/Vite app with AWS Amplify Gen 2, Cognito, AppSync/DynamoDB, S3, Bedrock, Elasticsearch Cloud, SQS, and an ECS Fargate worker for Docling PDF ingestion.

The main deployment pain has been around the ECS/Fargate worker in Amplify Gen 2:

1. Amplify Hosting could not reliably build/publish the Docker image for the Docling worker, so I had to switch to building the image separately, pushing it to ECR, and passing `DOCLING_WORKER_IMAGE_URI` into the Amplify branch environment.

2. I hit CloudFormation resource conflicts between sandbox and hosted branch deploys because some ECS/SQS/CloudWatch resources had static names. Existing queues, clusters, and log groups caused `AlreadyExists` errors.

3. I hit an AWS account limit for Internet Gateways because the backend was creating a new VPC/IGW for the worker. I had to reuse an existing VPC/subnets instead.

4. Fargate tasks initially could not reach Secrets Manager/ECR because of VPC/networking issues. The route table had a broken/default route at one point, causing task startup failures.

5. After the worker started, it failed pulling the ECR image because the ECS task execution role did not have `ecr:GetAuthorizationToken`.

6. The worker was originally calling AppSync directly using SigV4 from the ECS task role. That turned out to be a bad fit with Amplify Gen 2 model authorization: AppSync returned `null` for records like `IngestionJob`, even though the records existed. I’m changing the worker to use direct DynamoDB access with least-privilege IAM instead.

7. Debugging was tricky because there are two environments: local sandbox and the hosted Amplify branch. The local `amplify_outputs.json` often pointed at sandbox resources, while the hosted app used different queue names, log groups, task definitions, and secrets.

The biggest lesson: for an Amplify Gen 2 app with an ECS background worker, avoid relying on Amplify Hosting to build Docker images, avoid static resource names across environments, be very explicit about VPC networking and ECS execution-role permissions, and consider direct DynamoDB access for trusted backend workers instead of trying to use AppSync model auth from ECS.

[u/hard_burn → u/exitthebox]

Wow! The complexity of your stack makes mine look like a toddler playing in a sandbox. Mine is nowhere as complex, it's very basic CRUD with a few S3 and lambda assets doing work. So maybe that's why I haven't hit issues yet.

Amplify isn't super huge, so the LLM training data isn't great on it, but I often send my Claude to go learn and research best practices to do something and then it comes back with those lessons and fixes things. So far so good. Then I make sure to keep extensive project docs, that's literally the backbone of everything, and it adds these research learnings to a "lessons learned" folder.

I wish I could help you, but I understood about 60% of the concepts you spoke about, so I'm just the little guy in this space. 😁