So Long Sam, Bye-bye Language Lock-in
It was never about the code.
I’ve been trying to write this post for a while but struggled to find a good angle until Quinny Pig’s ‘Last Week in AWS’ Newsletter #473 pointed me to Simon Willison’s short blog article remarking on Mitchell Hashimoto’s response to the recent Bun Rust rewrite and comparing his own recent experience. Essentially agentic AI makes it practical to port between coding languages to the extent that it’s no longer a commitment.
Programming languages used to be LOCK IN, and they’re increasingly not so.
- Mitchell Hashimoto
I have nothing like the stature of any of these guys but this is something I already did, back in December 2025 on one of my own projects with the deployment stack - moving From SAM (CloudFormation) to Terraform (and also changing the Lambda architecture from AMD64 to ARM64 at the same time):
‘So Long’ SAM
A couple of years ago I had wanted to evaluate a few other deployment frameworks beyond Terraform. I had been working in a CloudFormation shop and had the opportunity to do some stuff with AWS SAM-CLI. For manual work without agentic AI/LLM integration it was ‘good’ in that it was relatively quick to get working compared to plain CloudFormation and that it handled a lot of implied resources without having to specify everything explicitly. There were some really annoying bugs with documented behaviour that did not seem to be getting much love and wasted a lot of time, and of course it’s an abstraction over CloudFormation, which has all of its own issues but it was ‘ok’. I wrote about this, both considering various deployment languages- CloudFormation, SAM, CDK and Terraform in Production 2024-07-05 - and for this specific use case -Modularising My Mini Monolith with Microservices 2024-08-05.
What happened in that year and a half?
I’d been working mainly with GCP for the previous 9 months, so obviously no CloudFormation or associated. Mostly a mix of Terraform and kube-native stuff. I’d kept my personal projects beyond labs on AWS.
In 2025 I got big into agentic AI1. A very fast moving and changing field for all of us. I think I’ve changed my toolset almost monthly over the last year. I generally don’t bother to write code directly myself now- I architect and review it. I consider this essentially similar to how in the past I might review code from a junior or an open-source contributor, but with the advantages that I won’t cause offence and they won’t get bored with repeated re-iteration. It’s easy to forget that it’s only been just over three years since ChatGPT launched to the public and a significant number of people started coding with it. I can recall working in businesses where we were directed not to use AI for work whilst management thought about it and now of course many businesses demand, or at least expect, it for the job.
For me this sort of ‘Agentic architecting’ approach largely negates the ‘convenience’ of the support for implied resources and attributes in SAM. If I am using, e.g. Terraform, then it’s obvious that my stack/project/configuration/whatever will need x, y, and z resources, e.g. If I want a public https endpoint then I’m going to need a DNS entry and a TLS certificate. There is of course a rich ecosystem of public Terraform modules for common use cases, which will include a lot of this sort of thing by default. I have used my own public static website Terraform module to serve React applications for my own and third party APis. By contrast, SAM CLI has 513 open issues as at May 2026 including this one from Nov 2022 which has bitten me previously - ‘sam deploy doesn’t update params in the stack when modified in the CF template #4404’. That’s more than 3 years for pretty core/basic functionality and of course I can’t really ‘fix’ the issue myself because it’s a proprietary abstraction over a proprietary abstraction over a proprietary API.
I’d also been doing a few personal web applications with React and was no longer comfortable having my three layer application all compressed to a single layer that looked like pure back end. I needed to refactor.
Welcome back Terraform and on!
I don’t actually recall now how long the port took using Claude Code. From recollection it was about 20 minutes on the first pass and then maybe a little longer to fix the errors and omissions. You can see the PR on my own project here. I was ‘back’ to Terraform and could put all of the foibles and foolishness of SAM and CloudFormation aside. I continued on with the agentic improvements to move what was initially 3 separate, visually very basic CLI-style, Lambda web servers into a React Frontend, an ARM64 Go Lambda and an S3 backend with a modernised API Gateway using my own and third party public Terraform modules. A much more professional presentation!
My Takeaway
I would say that in any meaningful sense the window for SAM has closed. If you truly want CloudFormation then you’re probably best going as close to that as you can, or possibly using CDK- SST already moved to Terraform. The convenience features of SAM lose a lot of their value when you can get the equivalent with any tool agentically. Coupled with the proprietary layers and stubborn bugs, I can’t see a strong argument for using an additional abstraction layer focused on developer convenience. It’s essentially just an additional issues layer.
Even if you don’t agree that ‘it was never about the code’ then I would hazard that it really isn’t now
Footnotes
-
Whilst ‘AI’ is the generic term, people are typically using it to mean LLMs, as I am here, and I do realise that this is essentially a probability engine more akin to autocomplete than anything else and certainly not magic or a solution in itself. ↩