Mike Roberts - tech

2025 Website Refresh and Migration

2025-11-19T00:00:00Z

I’ve had a personal website for nearly 30 years, and a personal blog for nearly 25. For the last 15 years or so I’ve used Wordpress to host both, but for various reasons I decided it was time for a change.

The new world

I’ve used a couple of “static site generators” for my work sites, and this one uses a similar tool - Eleventy. I chose Eleventy partly because it’s popular in some of the online communities I frequent these days, and also because it’s implemented in JavaScript - a language that I’ve become fairly familiar with of late.

The site is hosted on AWS using CloudFront and S3, and deployed with CDK, since I’m very familiar with doing this. :)

Migration process

The migration is complete as of November 2025, but I actually started this process about a year ago.

At that time I downloaded an export of my Wordpress site source, and also scraped the rendered version of the site (I think with SiteSucker, but it might have been something else). I created the AWS hosting at that time, uploaded the scraped version to AWS, and switched over DNS.

That got me off of Wordpress hosting but now I couldn't make any changes, plus also the rendered version had all kinds of Wordpress gunk in it. So the migration was only half complete.

I knew there were a bunch of tools out there that could help in the move from Wordpress to Eleventy but since I just got a bunch of Claude Code on the web credits this month I decided to let an LLM take a swing at it. I created a GitHub repo containing both the Wordpress export, and rendered site, told Claude I wanted to use Eleventy and keep all my links working, and let it go.

The first pass - which didn't take Claude long, just a few minutes - actually did the bulk of the migration work pretty successfully and saved me a huge amount of time setting the base system up, and migrating all my posts. I knew I was hosting in CloudFront, and so I'd also told Claude to extend the existing CloudFront function to handle redirects.

There was really only one miss, which is Eleventy's (in)famous off-by-one problem for dates. Given some direction Claude fixed that.

Apart from that there were a bunch of iterations on mostly styling and navigation changes - which weren't so much migration as me wanting to change things up with the new system.

Maybe now I have a new site I'll post more. :)

Feeds are working of course, and there even category feeds. See here

If you see any problems or have any questions the drop me a line, or contact me at @mikebroberts@hachyderm.io on Mastodon, or at @mikebroberts.com on BlueSky.

What is the steady state of LLMs and software development?

2025-08-19T00:00:00Z

Originally posted on my LinkedIn page.

In my last AI-related post I described my angst about how the possibly massive impact of GenAI on software development is also so divisive in the industry. This post is different - if GenAI is going to write a lot of the software we write, how does that become a sustainable part of our process / Software Development Lifecycle? In other words, what's the steady state we're tending to?

This has come to my mind because of a few things. On one hand there's the discussion of disposable vs durable software, which both Charity Majors (here) and Ross Pettit (here) have written about. On the other there are the many anecdotal reports I hear of engineers having to review thousand-line changes on the regular - mostly filled with LLM-generated code.

The problem: validation

Engineering teams are faced with tricky choices when they use LLM-generated code for a production application. Should they validate the code the LLM has generated, and if so, how?

These questions aren't new - any industrial software team needs to wrangle with whether they perform code review, and how much and what type of testing they perform. But there is significantly different context when an LLM is in play, e.g.

An LLM can generate code far faster than a human. So when human review is required the proportion of an engineer's work is going to be more skewed to "review" than "write"
An LLM may generate code that is beyond the knowledge of a team member to provide effective review on
For human-generated code there's already been a review-cycle within the developer's own head, whereas an LLM is hallucinating all-the-time (it's just that sometimes the hallucinations are useful).
Engineer-written automated tests usually test at various levels of the code base - e.g. external "integration" tests vs. "unit" tests that thoroughly cover edge cases of domain logic. But when an LLM has designed and written the complete internal design of a codebase an engineer may not know where best to write unit tests, requiring slower integration tests to cover more business logic.

Disposable vs Durable

For "disposable" software we may not care too much about these questions - we can just throw something into production and see if it works. If it does, great, if not then get the LLM to fix it. Or just not worry. YOLO.

Frankly I'm not worried about what happens with the process around disposable software, it will work its way out. I know some people think that all software is going to become disposable and ... well, I don't agree. I would really rather my bank balance doesn't spontaneously drop to zero, nor all air-traffic-control systems in the world stop working. Call me old fashioned if you like.

My concern is what are we doing with "durable" software, a subset of which is "anything that's involved with the movement of money". Which is ... quite a lot of the software in the world.

For durable software we need to make sure that the system is (a) acting as intended at the time it is specified, (b) continues to act that way as changes are made over time, and (c) doesn't cost the world to change. I know, I've already lost the YOLOers with these quaintly boring concepts.

Two solutions

Personally, I only currently see two reasonable possible steady states for "durable" applications or components:

A - LLMs generate and maintain all the code, and humans only perform external system testing. The internal design and implementation is a black-box.

B - LLMs can be used as a tool, but all code must continue to be reviewed and understood by human members of the team.

(A) is a super interesting theory. Taken to its logical conclusion it means we no longer care about things like design, underlying language, code duplication, etc. As long as the code works in the functional and non-functional ways required, then it's valid. It's also a very fast way of building software, absolutely fitting with everything I see about agent swarms, and the like.

Unfortunately I just don't believe it's realistic, for durable software specifically. I think an LLM can write code; I'm yet to be convinced about all the other things that go into building software, like security, performance, etc. Maybe we can write code in small enough components that each component works this way, and humans join them all together ... but that seems a stretch. Also, there's always logic in the joins, and who writes that logic? I've seen this game of software pinball before.

If (A) does come to pass then by far the most valuable people on a software team are those that can write effective automated integration tests. Because we're going to need A LOT of them. So all you QA people, get ready!

(B) means that we're basically using an LLM like a super-charged IDE. We can write code faster, but at the end of the day the SDLC remains unchanged. We're going to need to make sure senior engineers aren't burned out just reviewing 10,000 line PRs all day, but that's definitely possible with better use of agentic LLM rules and some team culture guidelines. Personally, I suspect this is where we are headed, but I don't see how this fits into what people are saying about "10X improvement in development speed".

My best guess is that today many companies aren't settling on either of these strategies. I can't help but imagine, therefore, that the amount of unreviewed, untested, barely maintainable code being shipped today for durable systems is sky rocketing. I know one answer is "But LLMs will solve that down the road", and if so I look forward to being proven wrong. Or more than likely using an LLM, and my own experience, to fix the mess.

My GenAI existential crisis

2025-07-19T00:00:00Z

Originally posted on my LinkedIn page.

I'm having something of an existential-crisis this week re: Gen AI in software development. I’ve never seen something, that possibly has such huge consequence, be so absolutely divisive among people I respect and am friends with.

Sure, Emacs vs Vi; tabs vs spaces, those were also big fights, but those things never had the potential to upend the entire industry. And if my pro-Gen AI friends are right, it will. And if my anti-Gen AI friends are right, it’s a flash-in-the-pan that’s ethically disgusting, and doing real harm.

But here's a problem: if software development is to be 10 to 100 times faster (which is what some people I respect say [1]), then no matter of concern about the ethics is going to matter, since capitalism will (unfortunately) win. In that scenario devs who don't want to, or can't, use Gen AI will be the economic equivalent of hobbyists. [2]

So as someone who still wants a job in software for the next 10 - 20 years I find myself forced to work with GenAI, if nothing else as a hedge. But I find this motivation troubling.

FWIW, I do think GenAI is a useful tool, but I feel the revolutionary aspects of it - at least for long-term maintainable software - are unproven. I suspect in good hands it will be evolutionary and in bad hands leave a mess for others to cleanup later. I also think at some point that the GenAI vendors will start charging what this stuff actually costs and make the case for it far less certain.

But these are just educated guesses, and if I'm wrong where does that leave me down the road?

I know how this sounds - in the software industry we've heard so many cult-like pronouncements of "trends that you have to jump on or be left behind" - Web3 / blockchain, the metaverse, model driven development, etc. And of course none of those DID overhaul the industry. What's different to me this time is how many people I know saying "this IS the thing".

Optimistically, I think the skills I (and other developers) have will be easily transferable, if necessary, once all of this has settled down. And further, my strategy at the moment is to try to use GenAI every week, to try to learn how to use it better, but not to rely on it.

Even if this isn't the biggest change in software in decades, it's certainly the biggest argument. I wish we could get back to disagreeing about whitespace - there was a lot less riding on that.

[1] https://lnkd.in/eti8StCa

[2] It would be nice to say that they were artisans, but the value of software is judged on what it does, not what it looks like or how it's made. If a GenAI-using company can end up writing some software that is functionally identical to the same software written by a non GenAI shop, and sell it, sustainably, for 5-10% the price, I can't see many people buying the non GenAI version.

A Serverless path to abstraction Nirvana

2016-10-26T00:00:00Z

Earlier in the year I wrote an in-depth introduction to Serverless Architectures — defining what they are, weighing pros and cons, etc. One idea that's been on my mind recently is how Serverless solutions have come about via the evolution of other infrastructural advances over the last few years, and where differences are with Serverless vs. other approaches.

In this note I'm going to talk about one of these difference areas — that of the abstraction of the host that Serverless provides.

One argument that Serverless isn't anything new is that it is just another form of PaaS (Platform-as-a-Service) or container platform . I talk about this in a few ways in the article but one thing I want to drill into a little further is the abstraction that Serverless gives over its host environment.

We've been increasing the layers of abstraction of server host environments for years now. It started when we placed our own physical servers in hosted data centers rather than in our own offices. At this point the connection to the server-site's ISP (internet service provider) was abstracted. Continuing, we stopped having to worry about physical servers (through virtualization) and Operating Systems (through PaaS or Containerization.)

Serverless tends more towards the ultimate destination of this path — complete host abstraction for our application logic.

PaaS and Containers get close — with the former you typically don't worry about an Operating System (OS) when deploying a component — just a programmatic environment. With the latter you still think about a form of OS in the definition of a container, but due to the nature of a container it's much reduced in management need to the point of not really being an OS at all.

Serverless solutions go even further down this path. Neither with Serverless BaaS (Backend-as-a-Service) nor FaaS (Functions-as-a-Service) do you worry about any OS, but there's a more important point — you have no concern with resource allocation or capacity planning.

What do I mean by this, and why do I think there's a difference here?

Take containers as an example. When you deploy a Docker container to Amazon ECS you still need to think about the hosting Cluster that your container will run on. You need to consider such questions as:

Which Cluster would be best placed to run this container?
Does the Cluster have capacity for my container's resource needs (CPU, memory)? If not how should I expand it?
What is my strategy for deploying multiple instances of the container across multiple machines in the Cluster?
If the Cluster has multiple types of machine within it, do I need to be concerned about that when I choose my deployment strategy?
What are the security constraints of the Cluster, and do they need to be changed in order to properly host my container?

Even if you use an environment like Mesosphere which tries to help with some of this someone in your organization is still thinking about these resource and capacity questions, and typically each application team is still going to be considering them to some extent.

With Serverless you have no such questions — the hosting provider figures out all the allocation questions for you dynamically, and guarantees it will have sufficient capacity for your needs (typically up to a limit across a coarse-grained context, like an account.) This is a big deal. Not only does it remove the need for people in an organization to be worried (and spending their time) on such concerns, it also means you're not spending too much money upfront over-provisioning your host environment, nor are you constrained down the road by under-provisioning your environment.

Until 3rd-party hosting container environments remove the need for resource and capacity questions it's a clear benefit of Serverless. That's not to say that hosting environments won't ever get there, and some PaaS environments already give you some of this.

So have we reached our host-abstraction Nirvana with Serverless? For Serverless BaaS I think in many cases we have! For Serverless FaaS? Nearly, but not quite! I still think we need to gain trust in FaaS host environments (right now I can monitor certain aspects of the host container and I should never have to do this.) There's also a question in my mind about coarse-grained location / networking. For instance it would be great never to even have to worry about what region my AWS Lambda function runs in, no matter my VPC need, knowing that AWS would just 'do the right thing'.

Agile Won

2016-08-30T00:00:00Z

A few weeks ago I attended Amazon's AWS Summit in NYC. It was staggeringly huge, with many thousands of people present. And this isn't even their main yearly event, although it is free to go to. It's also astonishing to me how big the AWS ecosystem has become. Amazon alone are earning more than $10 billion a year from their cloud services, but I can't even begin to think what the total 'GDP' of the AWS-related industry must be.

The AWS summit kicked off with a keynote by Werner Vogels, Amazon's CTO. You can watch the whole thing on Youtube here. It was your usual Jobs'ian style presentation — a mixture of updates, product announcements and guest speakers from outside of Amazon. Audience-wise it was extremely broad, speaking to developers, tech ops folk, technical executives, and possibly even accountants with the nod to CAPEX vs OPEX after only 2 minutes.

Towards the end of the session the final guest speaker came on stage — Sree Kotay, CTO of Comcast Cable. At this point the late-starting keynote was 90 minutes in, lunch was fast approaching, and a few slides of enterprise organization revenue (and a questionable choice of headwear) was enough to clear many of the seats in the auditorium. Which was a huge shame, because towards the end of this section Sree gave some wonderful quotes. You can read my picks of them below, or even better just go here and watch the next 4 minutes or so.

[Through Comcast's use of the cloud, we get] agile development. And when I say agile development, I don't mean .. burn downs and sprints, I mean 'real agile' — concept to customer — the time that you have an idea until the customer gets it in their hands …

We used to ship our product every 12–18 months, in a 3–5 year period we shipped 3 or 4 releases. Now we ship 3 releases every week.

A minute or so later, after some discussion about how some companies may need to think about 'hybrid' cloud he continued:

After going through this journey for the last 5 years we've realized benefits, and these benefits are around cost and scale. And they're critical and important, but interestingly they're not the compelling bit … The key part is this really changes your innovation cycle, it fundamentally shifts how you think about product development…

One of the classic project management time/space tradeoffs has always been 'velocity' or 'quality' and what we've found is that that's no longer the case — you can have velocity and quality. If you look over the last 3 months we've shipped more features than we did in our old product over the course of 3 years. And at the same time we've dramatically increased the quality of the product .. we've reduced trouble tickets by 50% year over year.

[This agile / cloud approach] creates an opportunity for differentiation. We've seen this realized in the marketplace, this isn't theoretical. Q1 of this year we had the best .. quarter we've had in 9 years, Q2 the best quarter we've had in 10 years, and we expect that pace to continue… It's not just about the cost reduction, it's about changing the innovation cycles.

Fundamentally the message I would say to you is that the cloud change is here — it's not just an option, it's the future. You can embrace it, or you can be obliterated by it.

Wow. I don't think I've ever seen such a strong validation of an agile / lean software development approach. And let me repeat, this isn't from some snake-oil agile consultant sensei — this is the CTO of an organization whose revenue is multiple tens of billions of dollars. I can't believe I'm saying this, because, you know, this is Comcast, but congratulations to them on achieving such a huge, successful, change in how they think about technology.

Sure, this whole speech was in the context of cloud services, and the cloud has given a mighty fine assist, but I'm calling it — Agile won. It took 15 years, but really that isn't too bad to transform an entire industry.