Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Binding Vows with AWS: The Judgment AI Still Needs

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers. →

Binding Vows with AWS: The Judgment AI Still Needs

AWS Community Day Taiwan 2026 https://awscmd.tw/en Serverless gives us real power, but only if we accept its limits. They cover execution time, resources, package size, concurrency, and API rates. In return we get managed services we did not have to build. Those limits also match what a good design should do anyway. Misread them, and the same design starts to cost us. We once said "fully serverless" and meant different systems. The word was shared; the constraints behind it were not. AI coding tools lowered the barrier to building on serverless. They still need the experience we never wrote down. This talk is that record.

Avatar for shiro seike

shiro seike PRO

October 31, 2026

More Decks by shiro seike

Other Decks in Technology

Transcript

  1. Structure AI builds Application People Domain + context Value People

    own the purpose and the context passed into the work
  2. Old setting Investigate Omit Rounding master Who uses it? No

    operational need From our team's records
  3. Planned flow Work area Revise flow Picking + movement Actual

    location Discuss with team The space was narrower than assumed From another team's record
  4. Records AI Questions People code + history find patterns facts

    + gaps confirm meaning People decide value AI supports inquiry · people confirm meaning
  5. Purpose Rule Example Correct business period Explicit reference date Missing

    date → error Owner Revisit Delegation Who decides? When work changes Agreed scope Keep it beside your README or PR checklist
  6. Request Snapshot Expected Date + version reference date master data

    business result effective time Freeze the inputs before comparing A team proposal, under review
  7. Business Port Adapter Lambda DynamoDB team owns rules GenRyu contract

    tested behavior example example Auth · dedupe · unknown commits GenRyu target design · in development
  8. Codex: plan + review Claude: implement Human: merge / deploy

    GitHub Issue AI work Checks Review Draft PR TanRyu policy AWS MicroVM candidate SHA same candidate GitHub CI Tested on 3 GitHub Issues → 3 Draft PRs
  9. Codex: plan + review Claude: implement Human: merge / deploy

    GitHub Issue AI work Checks Review Draft PR TanRyu policy AWS MicroVM candidate SHA same candidate GitHub CI Eligible check failure → bounded repair Tested on 3 GitHub Issues → 3 Draft PRs
  10. Candidate Checks Review Evidence one SHA fixed checks fresh review

    saved evidence Verify the candidate you deliver A person makes the final call Draft PR
  11. One request → one expected business outcome User API Gateway

    EventBridge SQS Lambda Expected effect · Deadline · Retry rule Agree on behavior before implementation DynamoDB
  12. Accepted ID Worker Outcome store Safety Progress No duplicate or

    unauthorized effect Every ID meets the deadline Keep unfinished and unknown outcomes visible
  13. Observe Decide Update Check Application signals + work rule owner

    context examples change Use outcomes to revisit rules Next step for GenRyu and TanRyu
  14. 15-minute limit Agree Measure Record what finishes together? accepted limits

    predict behavior vow + reason One rule · One reason · One check Put the owner and revisit condition beside the README or PR checklist