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:

1. Creating an S3 bucket.
2. Creating a Hosted Zone in Route53. Adding the name servers from the Hosted Zone to the domain registrar.
3. Requesting a public certificate from the AWS Certificate Manager. Creating domain verification records in the Hosted Zone.
4. Creating a Viewer Request CloudFront function to redirect to index.html.
5. Creating a CloudFront distribution using the ACM certificate and the CloudFront function.
6. Updating the S3 bucket policy to allow the CloudFront distribution to access the bucket.
7. Adding A and AAAA records in the Hosted Zone using the CloudFront distribution as the alias.
8. 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.
9. Creating an IAM policy to allow these actions.
10. 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.
11. 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:

1. utils for logging, configuration, and prompting for credentials
2. commands for initializing the project as well as setting up GitHub and AWS
3. 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 actions¹. We might return to replace this with an IAM role in the future².

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?

When I was in my twenties, I was asked to write an essay on “What matters most to you, and why?”

Most people that I know say that what matters most to them is finding happiness. Unfortunately, I was so far away from finding (or even recognizing) happiness that “finding myself” by “meeting more people” and “doing more things” was what mattered most to me. I felt this was a more satisfying answer than other options such as career, money, impact, changing the world, and so on.

It was more satisfying because I think it represented the curiosity that instinctively energizes me. Being in a state of curiosity was like being in a state of bliss. May be it was the child in me. One aspect that I missed was that staying in a curious state requires continuous learning and is a state of progression. Progression implies an objective. Without an objective, learning might be little better than meandering, even if one were discovering new things along the way…

What is the objective then?

One option is to define the objective to be a function of exploration and exploitation, perhaps with shifting proportions at different stages? This would allow for some wandering and some progress. But is it possible to effectively mix wandering and progress? When I’ve stopped making progress, it’s fun to wander. When I’m making progress, distractions and invitations to wander can be annoying. Is it because I’m human?

What if the purpose of wandering (exploration) is to find objectives for making progress (exploitation)? Then finding as many right objectives and then making progress on them would be the uber objective.

This week I’ve been discovering that generative AI has made a lot more objectives achievable. If I can identify the right objectives and make progress on these, I could find self-fulfilling progression, the forward energy that makes me intrinsically happy.

This week I’ve made progress on three projects, and starting this blog is one of them. Excited to write about the two other projects. Soon!

In an unusual turn of events, this blog has decided to sputter back to life.

In some ways, it feels a lot like 1999.

Living in a bubble…

Talk of looming pain…

and then may be the birth of a new era?