The First Project: Setting up a Static Site
This past week, I worked on three projects. The smallest, shortest one was simply setting up this blog using my husband’s very brief, but very effective instructions. It took me a couple of hours to get the site running.
The site itself is uses Zola, a Rust based static site engine that renders the whole site as static files, eliminating the need to manage a server or a database. The site’s code is trivial to generate. Alongside all publishable content, this code is maintained on GitHub. We use GitHub Actions to build and deploy the site on AWS. All this is relatively simple, and takes no more than a few minutes.
Figuring out how to stitch together AWS resources is a whole different ballgame. While I’m usually pretty slow finding my way around the AWS Management Console, this is what took a majority of the “couple of hours”. It required:
- Creating an S3 bucket.
- Creating a Hosted Zone in Route53. Adding the name servers from the Hosted Zone to the domain registrar.
- Requesting a public certificate from the AWS Certificate Manager. Creating domain verification records in the Hosted Zone.
- Creating a Viewer Request CloudFront function to redirect to index.html.
- Creating a CloudFront distribution using the ACM certificate and the CloudFront function.
- Updating the S3 bucket policy to allow the CloudFront distribution to access the bucket.
- Adding A and AAAA records in the Hosted Zone using the CloudFront distribution as the alias.
- Adding an GitHub Open ID Connect identity provider in AWS to enable GitHub Actions to update the S3 bucket and create invalidations with the CloudFront distribution.
- Creating an IAM policy to allow these actions.
- Creating an IAM role with this associated policy so that GitHub Actions can assume this role to perform the permitted actions, with GitHub as the principal.
- Updating the GitHub workflow file in our repository to use the appropriate S3 bucket and CloudFront distribution when deploying the site.
This was a win, but it wasn’t a real win unless it kicked off another worthy project, right? What if we could automate this couple of hours of effort?
Coincidentally, Anthropic rewarded me with an invite to Claude Code the same day. Before I build generative AI stuff, it’d be nice to use it to build something plain ’n boring… was my reasoning.
The Second Project: Automating Static Site Creation
I started with Claude Code, which was now flush with $25 credits in addition to my regular Claude subscription. It was immensely fun, apart from being incredibly rewarding.
I started by cleaning up and fortifying the documentation that I used to create my blog (above), and sharing this with Claude using the following prompt.
I want to create an agent that follows the instructions in the README.md.
We need to figure out what inputs are needed from the user up front, and what authentication is required from the user as the agent progresses.
Then let’s design the application. Ideally, I’d be able to invoke the agent using the terminal.
The result was a reasonably well designed “application” that included:
- utils for logging, configuration, and prompting for credentials
- commands for initializing the project as well as setting up GitHub and AWS
- services with API calls perform various tasks using Zola, Git, GitHub, and AWS
Later I learned that this code structure aligns with Anthropic’s Model Context Protocol recommendations on separating “client” and “server” implementations, where the client is embedded in the application (e.g. commands exposed to the user) while the tools (aka services) are implemented on the server side. In situations where the client and server are combined, this unit may notionally represent a complete “agent”.
In this case, the agent is simply automating a series of steps and isn’t using an large language model (LLM). However, at a later stage, we could decide that it needs one to, say, generate a new theme.
Authentication & Authorization
One reason I wanted to avoid any LLM-driven execution is that I wanted to learn about authentication and authorization flows without an additional layer of abstraction. When setting up my blog, I used a personal access token from GitHub to push the code to the remote repo. When implementing the automation, I wanted to use GitHub’s Device Flow for authorizing OAuth apps. While it seems more secure, I’m not sure if it improves the user experience much…
Unfortunately, authentication options for AWS are limited. It doesn’t support OAuth in general (except for Cognito, Quicksight, etc.). For this scenario, I decided to create an IAM user, assign this user any relevant permissions, and use the credentials for this user to perform the required actions1. We might return to replace this with an IAM role in the future2.
Questions More Than Thoughts
First, while this automation might shrink a couple of hours of work to a few minutes, I suspect it will still require the user to be somewhat technically aware. For example, they must know about name servers to update their domain registrar. What if all domain registrar’s also provided APIs?.
Second, while my “new” site currently doesn’t offer much beyond my projects notes, lessons, and reflections, what if I offered a new tool or service? Perhaps I should set up a Model Content Protocol (MCP) server? And then perhaps register it with Anthropic’s (WIP) MCP Registry to become a “well known” provider of the service?
Third, while I could use Google/GitHub as an identity provider for my service, what if I wanted to charge for my services? Would that be separate “token” to be negotiated with the user? Would the user be required to register and enter their card information on my site again?
Fourth, if I were able to negotiate a payment token with the user, how would I trust each request as being valid? Could the user request a refund if they didn’t request it or were not satisfied with the service? Would this be negotiated through the application owner invoking the service, or directly with the service provider?
Does it feel like we’re reinventing the web and digital commerce?
Amazon does provide authorization grants to read a customer’s profile, but it’s unclear if this is useful to perform any actions on Amazon.com or its associated properties.
Use of IAM users is recommended only for specific use cases such as emergency access, applications that don’t use IAM roles, third party clients, or when IAM Identity Center isn’t available. An IAM role is intended to be assumable by anyone who needs it and is not associated with long-term credentials such as a password or access keys.