It was Apr 2, 2025 when they chose to declare a national emergency, but I got only one notification about it. Maybe it’s not a big deal. Over ten years in, I’m still adjusting to being an immigrant, what would I know? At least it wasn’t Apr 1, which would’ve truly blown my mind.

In this whole emergency thing, I’m trying to put some order to the chaos that are the new U.S. tariffs that take effect on Apr 5, 2025. I only have o get through the formulaic comedy. The tariffs have some math. But what’s the reasoning, I’ve spent the whole day wondering.

You want a reserve currency?

After WWII, the Bretton Woods system established the U.S. dollar as the world’s reserve currency. As the dollar took over the role of gold in the interntational financial system, the U.S. agreed to link the dollar to gold (at the rate of $35 per oz), with all other currencies pegged to the dollar. This worked well as most countries had transferred their gold to the U.S., which was now closest to offering the most trusted currency backed by gold. A key motivation for the Bretton Woods system was to avoid floating, independently-managed national currencies by isolationist regimes while enabling stable currencies, free convertability, and free trade.

Little did they know how this would work out.

When the system became operational in 1958, countries settled their international dues in dollars, which could be theoretically converted to gold. After WWII, as Japan and Germany recovered, their share of world production increased at the expense of the U.S. As the U.S. further extended itself with military spending and foreign aid, the world grew less confident about its ability to convert dollars to gold. As U.S. inflation rose and the risk of a gold run grew, the U.S. unilaterally ended the convertability to gold in 1971, effectively devaluing the dollar. This is a repeating trope, you’ll soon see.

Turns out, gold-backed currencies aren’t the easiest to manage. Moreover, trust can be built through perpetuating belief systems (arguably the greatest human invention). Even without gold convertability, the dollar has remained the world’s reserve currency. But this still has its downsides.

The Downsides

One, operating currency reserves for the ‘reserve currency’ allows countries to manage their domestic currency exchange rates and make domestic goods more price-competitive. To do this, they accumulate US treasuries (store of reserve currency), causing the dollar to appreciate as countries buy dollar denominated US treasuries. Unfortunately, a rising dollar makes U.S. goods relatively less competitive.

Two, high demand for treasuries encourages the U.S. government to borrow with abandon to appease their electoral constituents. This fuels local consumption in the U.S. Effectively, this consumption is funded by savings in countries that buy U.S. issued debt. Sorry, you material girl!

Devaluation

While holding the reserve currency gives the U.S. geopolitical power (e.g. through trade restrictions), it also enables other countries to improve their competitive strength while undermining investment and production in the U.S. Apparently, you can’t have your cake and eat it too. Huh. Say that again, smart pants?

Can you do all three?

Specifically, can you:

1. Depreciate the dollar
2. Reduce US debt and servicing costs
3. Maintain the USD as the reserve currency

Yes, we can. Sorry, Barack Obama!

#1 effectively delivers #2 by reducing the cost of servicing current national debt.

#2 increases the chances of #3 by avoiding insolvency.

Bonus: A depreciated dollar makes U.S. production more competitive internationally, inviting capital investment. You like that?

But inflation. And the tariffs. Omg, they’re killing me, says the whole world!

Tariffs

Generally, tariffs cause the national currency to appreciate. Specifically, U.S. tariffs would invite countries to re-baseline their currencies to make their exports attractive again. For example, during the trade war in 2018-19, a JP Morgan report recounts:

The PBOC allowed the CNY, which operates within a semi-fixed exchange rate regime, to devalue through controlled FX mechanisms. A weaker CNY partially cushioned the impact of tariffs by making Chinese exports relatively cheaper and preserving their competitiveness in the global market.

Just trade uncertainty can also lead to depreciation of currencies. Not making this up. It’s in the same JP Morgan report.

While currency devaluation can partially absorb domestic inflation, in the mid-to-long term these countries need to lower domestic interest rates. This would reduce local production costs, making exports attractive again.

Incidentally, this would also effectively cap inflation in the U.S. That would in turn open the door to lower U.S. interest rates and lower the U.S. national debt servicing costs. What do you say?!

Alternatively, companies from these countries can invest in building production capacity in the U.S.

The U.S. would benefit either way.

But why don’t countries just their lower their domestic interest rates without all this drama? Lower interest rates (aka monetary easing) can stimulate growth, but can also lead to (1) foreign capital outflows, and (2) unwanted inflation, which would hurt the local population. No politician likes this part, especially if you’re a non-elected Chinese official.

When a country isn’t willing to naturally take on these risks, it can enter trade negotiations. Dare we say that the U.S. would benefit either way?

Overall, I can’t defend the reciprocal tariff rate math by any means, but maybe that’s not the point. Could there still be some order behind the chaos? After all, yesterday’s executive order contains…

the modification authority, allowing President Trump to increase the tariff if trading partners retaliate or decrease the tariffs if trading partners take significant steps to remedy non-reciprocal trade arrangements and align with the United States on economic and national security matters.

Everyone’s calling it “vibe coding”, and I’m quite enjoying it. It’s fast and fun, like a game where you create your own levels, and keep going till you exhaust the model. I go from “working” to “working” and unlock new challenges everyday. For example, I’ve never coded in Typescript, but I’ve now built two apps, one for personal finance using bank transactions and a second one to estimate income taxes. Next, I want to fine-tune a model and evaluate it using model-generated datasets, things I’d only dreamt of doing last year…

Surprisingly, it’s fun because it’s not always smooth sailing. People are comparing generative AI coding skills with human coding skills, which I think misses the point. When I understand what the model is doing and why it’s doing it, it feels like moving at the speed of logic rather than being constrained by language and syntax.

I must admit that part of the fun is discovering the model’s limits. Maybe these are Cursor’s limits rather than the model’s limits? For the record, I’ve been using Cursor with the default model, Claude 3.5 Sonnet. I’ve also used Claude Code, but that was a different experience. I might write about it at a later point. Yesterday, someone asked me what was it like to use Cursor. So here’s a short roundup of what I discovered.

Always be vigilant

Confabulation: Even when I provided reference documentation from Stripe, the model (Cursor?) confidently responded with something along the lines of “Looking at the documentation, this is correct.” It only relented when I asked it to provide a reference. If I hadn’t read the documentation myself, it may have taken me much longer to debug situations where it generated handlers for completely made up wehbook events.

Blindness: The model uses its previously generated code as ground truth. When I manually fixed code, it didn’t seem to effect the model’s subsequent generations, though asking it to fix the mistakes helped it recognize the “fix” before I could continue. For example, when I renamed a field in a Typescript interface (e.g. short_term_capital_gains instead of just capital_gains), it would not pick this up for the code it generated after this. At least a couple of times, it created new files without taking the repo structure into account. For example, it created a new scripts folder for database migration at the root level when it had previously created similar scripts in the src/app/db level.

Specificity is no antidote to eagerness

Overreaching: When I asked to add a new button and selector to a web interface, it added half dozen new packages and four new files. We already had Tailwind CSS and basic components to add these features, and I was not expecting that it would make the task to be 10x more complex than I wanted it to be. Fortunately, reverting was simple.

Overassuming: On another occasion, I prompted it to add specific new fields to one Typescript interface, but it also added to another interface for no reason. This worried me about what else it had assumed… maybe most of its assumptions were good?

Don’t bank on its stamina

Anti-endurance: Ironically, sessions that don’t go well last longer. The session where it confidently misinterpreted Stripe’s documentation was also the session that drew on for a couple of hours. At some point, it froze in the middle of responses, leaving the repo code in intermediate state. Rerunning the prompt sometimes resolved the issue. After a point, it stopped responding altogether. It would respond to short and simple questions after that.

Anti-recall: On a few occasions, it added dependencies even after we explicitly decided against these. For example, I began the project by asking for options and trade offs, and directed to proceed without taking a dependency on the Prisma ORM. When I tried to add new features, it would forget this instruction, and add code requiring Prisma. This occurred enough that I asked it to find a way to remember it. It proposed to create a project plan without realizing that we had created one at the beginning of the project. I wasn’t sure if updating it would help it remember better, but the issue hasn’t reappeared since.

Intelligence != Ownership

No Reflections: On many occasions, it would leave behind spurious code or files, making no effort to clean up after I had redirected its suggested solution. Sometimes this clean up became difficult as I lost track of all the changes that had to reversed. Maybe this is a good thing, because I wouldn’t want it getting too eager overthinking its past results!

If I had asked people what they wanted, they would have said faster horses, Henry Ford is famously quoted. Yet, Ford didn’t invent cars to replace horses. He invented factories to make cars cheaper and more accessible. Factories that would make the car, according to Ford, ‘so low in price that no man making a good salary will be unable to own one.’

When Ford developed the Model T, cars had been around for decades, made ‘artisinally’, if you wish. They were expensive and unreliable. Ford’s goals were affordability and reliability. His first idea was to introduce consistently interchangeable auto-parts. His second idea was the moving assembly line, which reduced the time workers spent walking around the shop floor to procure and fit components into a car. ‘Progress through cautious, well-founded experiments,’ is a real quote from Ford. The 1908 Model T was 20th in the line of models that began with the Model A in 1903.

Borrowing a leaf from the top of the last century, more than inventing new foundation models (FMs), we need to invent the factories that make such models trivially affordable and reliable.

Billions of Models

If FMs are the new ‘central processing units’, technically there’s no limit to the number and variety of ‘programmable’ CPUs that we can now produce. A typical CPU chip requires $100-500M in research and design, $10-20B in building out fabrication capacity, and 3-5 years from concept to market. Today, FMs can be pretrained within months (if not weeks) for much less. On this path, more than OpenAI, Google and DeepSeek have accelerated affordability.

Note: MIT: Million Input Tokes, MOT: Million Output Tokens

Affordability

Affordability is admitedly relative. Software developers may be willing to pay more than marketing content creators. The value of research for knowledge workers depends on the decisions it enables them to make. Customer support may be valuable, but no more than the total cost of employing and managing human support representatives. When the returns (or savings) are clear, there is quantifiable demand.

OpenAI loses more than twice that it makes, and it needs to cut costs by a roughly an order of magnitude to be sustainably profitable. If Nvidia’s Blackwell chips deliver the promised 40x price to performance improvement, this will be the year of non-absurd business models. More power to them.

It’s possible that DeepSeek is already there. More importantly, DeepSeek might represent the price level of an API provider who doesn’t have a application business to cannibalize. Is it ironic that OpenAI is facing an innovator’s dilemma of their own?

Meanwhile, Anthropic charges a premium over OpenAI’s application-level rates. They also need an order of magnitude reduction. They might already be there with TPUs, or with Trainium 2’s 75% price drop they’re likely getting there. It’s unclear if they have a cannibalization issue yet, though their CPO definitely wants their product teams to iterate faster.

Training and adapting the model to meet specific and evolving customer expectations is the business need. On this point, popular applications such as Perplexity and Cursor/Windsurf are arguably underrated. Just as Midjourney provides a delightful experience by getting the combination of the model and user experience just right, these applications taking their shot. After all, the model is a software component, and application developers want to shape it endlessly for their end users. The faster these developers iterate with their models based on feedback from their applications, the faster they’ll see product-market fit. They can then figure out how to grow more efficient. Finding product-market fit is the only path to affordability.

People mistake such applications to be ‘wrappers’ around the model or ‘just’ interface engineering. That’s a bit like saying Google is just interface engineering over Page Rank.

Reliability

For a given use case, reliability is a function of: How often does the model ‘break’? How easy and/or expensive is it to detect and fix?

In creative work, there’s often no wrong answer. And checking the result is generally easier than generating the result.

For automation, it’s more of a spectrum ranging from infeasible to non-compliant, to varying degrees of risky, to safe & expensive, to safe & cost-effective.

What makes the application risky vs. safe? And who underwrites the risk?

One answer is tool use. Multiple tool use protocols such as Model Context Protocol want to make FMs more aware of available tools in addition to making tool use more effective and efficient. However, there’s no significant reason (yet) for any major model provider to use another’s protocol. I expect protocols to emerge from most if not all model providers, and feel that standardization is at least a year or two away. Even then, new standards may usurp older ones, and different economic and geopolitical agendas could shape these in weird ways.

However, a sophisticated ‘tool’ or service really wants to be an agent. When multiple agents need to work together, we need distributed ownership, separation of concerns, authentication, authorization, auditability, interoperability, control, non-repudiation, and a lot more. Much of this plumbing already exists with OAuth2.0 and can be repurposed for service agents, but a lot still needs to be built. Whoever builds the most reliable multi-agent collaboration systems will likely grow to become the most trusted.

The Industrial Revolution

Unlike fantasy AI factories that spew pure intellgence as tokens, these factories will ship affordable and reliable engines that can safely power software applications. While we urgently kick off the next manufacturing industrial build out in the U.S., my guess is that these software factories will take years to build. We need to have started yesterday…

Yesterday I decided to dig into the CoreWeave’s S1. When the company called me in 2022, I’d shrugged it away. After a few of my colleagues ended up joining the company over the last few months, I’d grown more curious to learn what they’re about…

I broke down my analysis into the following parts:

1. Financial Health
2. Market incl Opportunity and Growth Drivers
3. Operating Plan
4. Leadership & Team
5. Risks

1. Financial Health

On the positive side, CoreWeave’s (CRWV) business offers a window into the economics of committed multi-year cloud contracts. Upfront and recurring payments from customers can provide a nice, steady cash stream over multiple years. CRWV has used these customer contracts as collateral to raise more capital, at lower cost. Lower cost of capital has allowed them to acheive economies of scale to certain degree. But they’re running out of headroom.

Incumbent hyperscalers used cash flows from their existing in-house businesses to fund their cloud infrastructure build out. CRWV has used contracts with ‘investment grade’ or ‘IG’ customers (e.g. Microsoft) to raise debt to fund their infrastructure build out. The company achieved nearly $2B in revenue in 2024, carrying $8B in debt, with financial covenants that limit diversification of their customer base. This is because debtors want customers to be primarily IG. Their leverage ratio¹ is about 5.4x, and can be no higher than 6.0x for certain credit facilities. And each 100bp change in interest rates would increase their interest expense by $31M (about 9% of their net interest expense in 2024). The table below breaks down their current debt. It’s a sight to behold.

As public markets invite more overhead and constraints, IPOs have become the last resort for a healthy, growing, and profitable company (exhibits: Stripe, Databricks). High debt levels in uncertain economic times are risky, which makes the timing of this CRWV IPO all the more interesting. And if further debt is financially untenable, an IPO would indeed be their next best option. Is it also possible that encumbering the company with further onerous private equity terms might strangle its IPO potential forever?

2. Market

CRWV cites Bloomberg Intelligence in sizing their market opportunity for “AI” workloads at about $400B, across training, fine-tuning, and inference. They see their opportunity across the stack as defined by ‘traditional’ hyperscalers, including Infrastructure, Managed Services, and Application Services. Infrastructure accounts for a majority of their revenue today, and includes compute and networking resources (comparable with Amazon EC2). Managed Services provide K8S-based services (comparable with Amazon EKS/ECS). Application Services include SUNK (Slurm on K8S), Tensorizer, and Inference/Optimization (comparable with Amazon SageMaker and Bedrock).

Opportunity: “Purpose built” for AI is their stated differentiation, citing delivery of more compute cycles for higher performance than ‘generalized’ cloud providers. However, their primary exhibit is from June 2023:

In June 2023, our NVIDIA H100 Tensor Core GPU training cluster completed the MLPerf benchmark test in 11 mins, 29x faster than the next best competitor at the time of the benchmark test

They cite the difference between observed MFU (Model FLOPS Utilization) of 35-45% compared to the theoretical 100% as a significant opportunity for unlocking AI infrastructure performance potential and therefore the improvement of quality of AI overall. While general purpose clouds created over a decade ago and were designed for general purpose use cases such as search, e-commerce, generalized web-hosting, and databases, they claim to have reimagined traditional cloud infrastructure for AI. Their primary exhibit here is the removal of the hypervisor layer (and other unnecessary managed services that cause performance leakage). They claim this allows them to deliver 20% higher MFU than general purpose clouds. In my experience, most sophisticated customers can achieve 40-50% MFU as they’re fairly capable of optimizing every dimension of their training environment… but who am I to say?

They add that delivering this performant AI infrastructure is immensely challenging, which I totally believe. However, I found little in their description that suggests how it’s different or ‘reimagined’ from traditional cloud infrastructure:

Depending on the configuration of the data center, a single 32,000-GPU cluster may require the deployment of approximately 600 miles of fiber cables and around 80,000 fiber connections. Acquiring the necessary high-performance components requires managing a complex global supply chain, and configuring and deploying those components in data centers requires deep operational experience. The data centers themselves need to be specifically designed for high-performance compute, which requires specialized heat management capabilities such as liquid cooling, with heat exchangers and subfloors to support high density racks and high power supply per rack.

Growth Drivers: Two dimensions have definitely worked in their favor. One is speed, the second is power.

Doing as little as possible is a brilliant way to be fast. They source GPUs exclusively from Nvidia. OEMs assemble it for them, and they ‘deploy the newest chips in our infrastructure and provide the compute capacity to customers in as little as two weeks from receipt from our OEM partners such as Dell and Super Micro.’ They also lease their data centers. They do automate provisioning and testing the infrastructure, ‘ready for consumption within hours of customer acceptance.’

In short, CRWV acquires the financing and project manages the conversion of Nvidia’s GPUs into a usable product, data center compute with power. There’s plenty evidence that demand has far outstripped supply of foundation models these last couple of years while hyperscalers have been power constrained. While hyperscalers have been power constrained, CRWV has helped Nvidia shrink the gap between demand and supply by finding scarce power.

The key question is: Will CRWV build sufficient value faster than the industry closes this gap?

On a slight tangent… in addition to rapidly deploying Nvidia’s GPUs and getting these into the hands of end customers faster, CRWV also helps Nvidia diversify their customer base, presumably beyond the incumbent hyperscalers?³

This raises another question: Will CRWV be the undifferentiated cloud providing Nvidia’s GPUs while the other three differentiate by vertically integrating with their own chips?

3. Operating Plan

Business Model: CRWV’s average cash payback period on their GPU infrastructure is expected to be about 2.5 years. Assuming contracts continue to range from 2-5 years as they do today, they expect to profit from the residual value of the GPUs past the contract length. This assumes the GPUs are still worth using beyond the contract life and haven’t died from inherent failures and high-pressure workloads. Anyway, the faster the GPUs depreciate, the faster they can be replaced with newer, higher performing ones, and the cycle repeats. It’s not clear if this is a good business model itself, unless there’s more value for customers. This explains the push for Managed and Application services, especially if these can be designed for AI workloads rather than be redesigned to accept AI workloads. This strategy makes sense, but their execution becomes thinner as it goes up the stack.

More than seemingly lucrative committed contracts⁴ (96% of revenue in 2024), more interesting is the quality and nature of their customer base: their top customer, Microsoft, accounted for 62% of revenue in 2024. Payments from Microsoft would definitely qualify as IG. Their second largest customer accounted for another 15%. They mention other customers such as Cohere, Mistral, Meta, IBM, Replicate, and Jane Street (also an investor), but if Microsoft drops their commitment would they be able to maintain at least $1B in contracted revenue (for financial covenants)? Not to worry! OpenAI is stepping in to purchase a five year $11.9B contract, supposedly taking a stake in the company to boot. Maybe this is a better outcome, if Microsoft was just a front for OpenAI?

OpenAI expects to make $11.6B in revenue by burning through $14.4B in 2025, some of it presumably going to CRWV now. Such an irrational investment may itself appear as a deterrent to others⁵, limiting CRWV’s potential customer base to model builders who feel compelled to lose money for years⁶. Focusing just on OpenAI, if their usage grows per plan, would they take Microsoft’s capacity over CRWV’s? Or does CRWV come into play only if OpenAI grows beyond expectations and Microsoft is unable to meet their demand? Or they come into play if Microsoft intentionally wants to diversify its capacity across other model families, and hold back from OpenAI?

Combined with the economic uncertainty around interest rates, uncertainty around competitors and customers compounds CRWV’s operating risks. But Nvidia and OpenAI really want this tenuous link to exist, at least for now! The IPO adds some overhead, but likely increases its chances of survival. With the new capital, CRWV plans to:

• Capture more workloads with existing customers, mostly capture OpenAI’s?
• Expand to more customer segments, though non-IG customers must be limited to 35% of revenue?
• Expand internationally, though it’s unclear if they can repeat their growth playbook in other regions.
• Integrate vertically, though would it make sense for sophisticated customers such as OpenAI to use their vertically integrated services?

CRWV’s biggest advantage is that they have nothing to lose, and no prior services or operations to shutdown. They can redefine what cloud infrastructure means for AI workloads. Their vision of specializing around AI can be disruptive, but despite their claims of a unique ‘corporate culture’, it’s unclear if they can realize this advantage in a meaningful way.

4. Leadership & Team

Co-founder, President, and CEO, Michael Intrator, was previously co-founder and CEO of Hudson Ridge Capital Asset Management LLC, a natural gas hedge fund. Chief Strategy Officer, Brian Venturo, was also a Partner at the same fund. Both have prior experience overseeing investments in energy products. Their understanding of energy related risks, financial engineering, andthe hustle to bring it all together in such short time is quite stunning.

Despite all the financial savviness, their oversight of material weakness in financial reporting processes, systems, personnel, and controls doesn’t inspire confidence.

The material weaknesses identified pertained to the lack of effectively designed, implemented, and maintained IT general controls over applications that support our financial reporting processes, insufficient segregation of duties across financially relevant functions, and lack of sufficient number of qualified personnel within our accounting, finance, and operations functions who possessed an appropriate level of expertise to provide reasonable assurance that transactions were being appropriately recorded and disclosed. We have concluded that these material weaknesses existed because we did not have the necessary business processes, systems, personnel, and related internal controls.

In all fairness, this is fixable. But I suppose this IPO happens now, or there’s a risk that it never happens. It’s also convenient for the investors, who would love a timely exit. While the founders have cashed out large amounts over the last couple of years, employees can also get a ride through the IPO. But they’ll be limited by lock in periods.

At least one investor isn’t limited by lock in periods: Coatue has a put option that entitles them to receive cash equal to the OIP (Original Issue Price) of their Series C shares plus any accrued dividends. Alternatively, they can choose to sell their converted shares at any time after the IPO without being subject to a lock in. Their put option expires only if the stock trades at or above 175% of the Coatue’s Series C OIP during any consecutive 30 trading day period, which would allow them to sell their shares at an attractive price. Did I say how convenient this is?

5. Risks

Not mentioned yet, but CRWV also bears the risk of vendor concentration, with top three suppliers accounting for 46%, 16%, and 14% of total purchases. Again, it’s fixable, though they already carry OEM financing liabilities from these existing vendors.

This is already getting long, so let’s set aside what the regulators might throw in.

To summrize, in addition to indebtedness in an economic uncertainty, customer concentration in a fast evolving market, weak financial controls, and vendor concentration, the company operates in a market with three entrenched, well capitalized, and fierce competitors. One might say that these traditional hyperscalers see winning AI to be an existential risk.

CRWV will certainly be an adventure. Not for the weak hearted, if you’ll allow me to add…

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?