Harnessing The LLM - Rebuilding My Podcast Website In Two Evenings And Not Two Weeks

Why is this relevant #

The meta-point that I want to drive with this post is that if you are a software engineer, product manager, data scientist, or in any other role that deals with technology and you are not using Large Language Models (LLMs) and tools built on top of them, you are missing out on some key productivity boosters. Consider this anecdata, but what I managed to accomplish with my podcast website, arguably a relatively simple project, is a bellwether for things to come across the industry.

The great rebuild #

For some time, I really wanted to rebuild my podcast website to be a bit more sleek and modern, but I never got to it. For a few reasons, of course, as these things go - I didn’t have the time to build a whole website from scratch and I there was no pre-built theme that I quite liked for the static site generator I was using (Hugo, for the curious).

That is, until I started more actively using GitHub Copilot in my day-to-day. That’s when I asked myself the question - could I guide Copilot to the experience I want?

With the “legacy” version of my website, I kind of steered the design to what I wanted but it didn’t quite click with me, and because I re-used an open-source minimalist theme, I ended up with a lot of hacks to work around existing theme constructs. I never had the desire to rewrite a brand new theme from scratch, but the more I put that project aside, the more I felt like the podcast web experience was not representative of my desire to live up to the craft.

What I had wasn’t exactly top-notch engineering and design on my part. Take a look at what the experience used to be:

It’s not terrible, but I got somewhat annoyed with the papercuts that I saw:

1. No dark theme. I really got used to valuing my eyes with dark colors, and the white was just jarring every time I visited the page.
2. Styling was stale. It really was. Not that I am claiming that I am some kind of UX expert, but the styles felt all over the place - the icons were of different sizes, buttons were of different styles, effects were different depending on the page you’d land on, fonts in some places were too small, the entire site felt somewhat disjoint. This didn’t quite vibe with the brand I wanted to create with the show.
3. Mobile rendering was bad. Because I was using a pre-built theme, the mobile experience was subpar, let’s just put it that way.
4. No reusable components. Quite a bit of stuff within each episode post was just raw HTML. I hated maintaining that, but again - never had the time to do a proper fix.

I just didn’t feel good if I had to send anyone to that website to learn more about my show and the amazing folks that dedicated their time to talk with me. But, all that being said, the core was there - I had an idea of what it should look like but I needed to speed up my production time to get it done.

Off to the races #

The first thing I did is start prompting GitHub Copilot to scaffold a podcast website for me using Next.js. I still love working with Hugo, but I wanted to push myself out of my comfort zone a bit, and I previously worked on Next.js-related items at Netlify. Frankly, though, I didn’t care much for what framework to use here as long as the developer ergonomics were there for the basics and I can tweak and organize things in a way that makes sense to me.

That’s probably closely aligned to what Andrej Karpathy talked about when he coined the term “vibe coding”:

There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like "decrease the padding on the sidebar by half" because I'm too lazy to find it. I "Accept All" always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

I can’t say that I quite pushed the slider that far to the right where I just “Accept All” for changes that AI suggests, but I certainly did try to push it in that direction and not care as deeply about the specific output. For example, when I wanted to create that gradient on the home page:

I didn’t necessarily care about how that gradient was done - I just had an idea that I want that kind of gradient, I gave GitHub Copilot the color range and the end-color that it needs to fade into, and then let it figure out the rest. I then added the code to the layout definition and I was good to go. I am by no means a CSS expert, but once I saw how GitHub Copilot suggested that, I started iterating on the gradient myself to see how tweaking the values would impact what I see rendered on the screen. This is a much better workflow than me going digging through cryptic, poorly formatted documentation - just give me the thing and let me tinker with it.

What’s also great about GitHub Copilot is that when you ask it to scaffold things, it actually generates most of the necessary basic artifacts, like package.json with the relevant packages, along with some core components and views (pages). I can then introduce some tweaks as I see fit and request changes quickly.

Now, to those of you who think “OMG web development is now obsolete” I will give you some peace of mind - it didn’t just build the entire site for me. I knew what I wanted and I knew where to look when things went wrong. For example, while Copilot was really good (and I don’t use that as an exaggeration) at producing a lot of boilerplate, I ran into some issues:

1. Inclusion of unnecessary packages. There were a bunch that were duplicative. This was especially important because I needed to parse and render Markdown, and it imported at least three different packages that solved the same problem.
2. Incorrectly assuming the file I am editing or where to put things. Several times, it suggested I add some kind of directive or style in a file that should not exist because there is already a file that serves that purpose (such as a global CSS container).
3. Suggested package versions were out of date. I had to manually go and check what the latest versions are to make sure I am not including anything with known vulnerabilities.
4. Sometimes it would get loopy. I would tell Copilot that a piece of code is bad, it would rewrite it, but that didn’t work either, so then it would go back and produce the initial version again. Usually starting a new conversation helped break out of this state.

I knew how to configure npm to get things to run, and I knew how Next.js works behind the scenes a bit so that errors were not entirely cryptic to me. And while I will not claim that at this time I am a web development expert, having extensive technical knowledge in other domains helped me ramp up relatively quickly because I had some intuition on what to do to unblock myself.

What was the outcome #

I see the power of the LLM here as the great idea and iteration enabler. I, quite literally, rebuilt my entire podcast website in two evenings instead of two weeks of figuring out how to adapt a million of weather API samples or cloning massive, bloated repositories to slice the pieces that I need to learn Next.js.

That’s actually part of the superpower - personal context. In my scenario, GitHub Copilot built the Minimum Viable Product (or, MVP for you startup folks) exactly for what I needed - a podcast website. I didn’t need to go and figure out how a view should be structured or a component defined to be used for an episode page. The context was right there, filled for me. I would still steer Copilot in the right direction, but it felt like I have another engineer next to me who could produce some code to implement my idea.

I think it turned out quite nicely:

Takeaways #

In this limited experiment, I had a few “aha!” moments, that I should summarize here. Feel free to take this with a boulder of salt because it’s a reflection from my own experience and own experience only. It’s not a definitive statement about the future and is just as much of me reading the tea leaves as any other technologist. Things will get better, faster, and more efficient.

I now have a tool to speed up my time from idea to implementation. Yes, I only used this in the web domain of expertise and if I take this to reverse engineering an unknown protocol it’s probably going to struggle a bit more, but it was amazing to see how quickly I went from a vision in my head of how things should behave on the page to a real, tangible website. GitHub Copilot enabled me to focus on the problem (“I want a modern, maintainable podcast website.”) instead of digging through the insides of a React-based framework.

My experience with the LLM doesn’t negate the need for learning the tech. You might think that if I delegate something entirely to a LLM, I will become “dumber” - after all, if I just keep prompting for changes that I do not understand, what if the LLM produces horribly inefficient code? Remember how I called out that in my early experiments, Copilot kept adding npm packages that were duplicative? That kind of stuff still requires you to understand why things are happening and how to mitigate some of the mistakes. And because I was immersed in a concrete scenario that I cared about and it’s not just some abstract sample, I had a front-row seat on seeing how a Next.js application of the kind that I am building would be laid out. If I had doubts, I could then dive into the documentation to understand a concept or approach a little better.

I am still limited to the training set cut-off date. If React or Next.js introduced a new way to load pages faster today I wouldn’t get that from a LLM. But that’s mostly OK - I think this ties nicely to my previous point that just because I am using a LLM doesn’t mean that I no longer need to learn anything about tech. New, creative and innovative approaches to solving problems ahead of us will require humans to do the work too, and that work will be outside the boundaries of LLM’s knowledge.

Most web development samples online are kind of dead to me. That’s a bold statement to make, especially considering that LLMs train on those samples, but the perpetual problem with samples that I have is that they usually cover scenarios that are completely orthogonal to what I am building and often include things that are not even closely involving the types of infrastructure I am using. I have to then go and spend time reading documentation just to create a “duct tape and baling wire” solution. With an integrated LLM like GitHub Copilot I can steer it to the right context and see exactly how things should plug into my own experience.

LLMs are an indispensable tool in your software engineering toolbox. There are people who are either completely against LLMs or those that think that LLMs are going to destroy humanity as we know it. I am not anywhere on those extremes of the spectrum. LLMs are a tool. Use it where it’s appropriate, and don’t use it where it’s not. In the context of software engineering, and especially in the context of web development, tools like GitHub Copilot are really good at transforming ideas into viable experiences quickly. I’ve seen the same to be the case with Python code - I use it extensively for charting with matplotlib.

No point in being a purist in everything. With the proliferation of LLMs in the software engineering context, we will see a decline in the “purism” aspect of coding. There are places where strict standards, quality controls, and compliance requirements are non-negotiable. Medical equipment, financial systems, airplanes, and many other critical systems should always be under high scrutiny and maintain the highest bar for any changes. But there are a myriad of systems where that’s not even close to a requirement. If I want to write a tool to quickly transcribe my podcast episode and clean up the filler words from the text to make it readable, do I even care what framework it’s written in? Or that it uses three helper classes instead of one? Absolutely not. As long as it solves my problem, it’s good enough. I might even go as far as to create “throwaway software” that is designed to quickly fix a specific issue I have (I’ve created numerous PowerShells scripts with Copilot that I will never use again). I think the advent of LLMs in software will bring a new perspective on “Get this product to solve a problem and don’t worry about what’s under the hood.” Again - not applicable everywhere but it doesn’t need to be.

The bar will get higher. A lot of basic CRUD apps, landing pages, and basic sites will be easily created with LLM-integrated tools. Shops and individuals that were focused on building that and simple experiences of the kind will find themselves in trouble if they don’t figure out a moat. So, in a conversation with John Lam, I asked him the crucial question - if a lot of this software logic gets entirely abstracted away by LLMs, what’s the moat for a human? His answer - “Agency.” I couldn’t agree more - a LLM is good at being the executor of your instructions, but you still need agency and taste to know where to direct the vector. If you don’t have good product taste, a sense of what your customers need, or how they interact with what you’re building, a LLM is not going to help you. A crappy experience built by a LLM is still a crappy experience. I am not as fatalistic as Chris Sacca when it comes to AI replacing engineering as a discipline just yet, but I think this just means that the bar for what a great engineer is will be raised. We should prepare ourselves for that.

Long story longer #

If you haven’t yet, check out the website that I rebuilt with GitHub Copilot - The Work Item podcast home page. I’d love to hear your thoughts and feedback!