I vibe-coded an app. And also made some jewelry.

Last weekend, I took a silvercasting workshop run by a friend and made an absolute chonker of a ring. I’m going to oversimplify enormously – first, you carve the shape out of wax:

Then you press it in to sand and oil:

Then you make an alloy, melt it down, pour it in. The fumes are toxic (watch out!) and the liquid metal is extremely bright and it’s all very very fun.

Then saw off the bits, sand it and polish it for an hour or so and you’re done!

Alloying metals

The ring is made of sterling silver – 92.5% silver, 7.5% copper – but you buy those metals separately. You have to alloy them together as part of the production process.

It’s not super hard to do the math, but we got a little stuck on it, especially once we realised we’d made a mistake somewhere and needed to add a little extra after already measuring everything out.

And so I asked: “hey would it help if I just made a small little calculator app for this?”

Vibe coding

It felt like the perfect project to vibe code – I really enjoy making Web Stuff, but am slow at it and relatively unknowledgeable. The usual downsides of LLMs also don’t seem to apply to projects like this¹:

• LLMs struggle with complex state and interactions, but there’s relatively little of that in this simple calculator app.
• LLMs generate tech debt like crazy, but that’s fine here because the project is small enough that the whole thing fits into the working memory (and therefore, we can vibe our way out of the problems we vibe our way into).

I used VSCode / Github Copilot for this, almost entirely in agent mode. I started with some opinions about exactly what I wanted (and totally forgot to tell Copilot what I was actually building, lol):

And about 3 hours later, we had this:

It’s live! You can try it out at alloyz.fabi.jetzt!

Here’s where the time went

It took:

• under an hour to get the basic website built and the styling done, primarily through Chat but with some manual debugging (more on this soon)
• about an hour to polish things up, I made maybe 50% of the changes here
• about an hour to get the ServiceWorker running for offline support. Copilot was pretty much useless for this; I got something working mostly by reading the docs and googling stuff (you know, the way our ancestors used to program).

Observations

The robot can’t see the output

The LLM can’t see the output of what it’s creating – when you tell it to write code, it can’t actually run that in a browser and see how it looks or even if it works. I think this is part of why working with one is so frustrating – it can’t really independently check if the thing it’s “trying” to do actually worked or not. We went back and forth a lot on style changes before I eventually realised that the styles weren’t being used at all:

I ended up going to the Tailwind setup docs and stepping through line by line. I think Copilot might’ve been giving me configuration instructions for an old version of Tailwind.

Understanding that Copilot couldn’t examine the outcomes of its suggestions was a revelation. The interaction feels similar to getting a frontend pull request review from a coworker without screenshots or tests – it’s extremely hard to figure out what’s going on, and so you either:

• ask for those screenshots and tests,
• download and run the code, or
• just muddle through and offer mediocre suggestions, because (unlike your browser) your brain is not capable of directly rendering HTML/CSS/JS.

It seems like Copilot can’t do the first two (yet?) and so it’s kinda stuck doing the last of these, and is surprisingly good at it given the constraints.

Solid APIs / foundations are crucial

I wanted this app to work offline, so I asked Copilot to add service worker support. We’ve known for a long time that Service Workers are hard, and as programmers, we build abstractions over hard problems to make them more tractable. It was striking to me that Copilot struggled so much with Service Worker complexity, too, and it felt a little interesting that it wasn’t able to take a step up and ask if there was a higher-level abstraction that would meet the same goals (I ended up using @parcel/service-worker which got me 95% of the way). On the other hand – when I told it ‘use Tailwind for styling’ it did a great job, once I’d sorted out the build config. I suspect that the fact that Service Workers are powerful / flexible and require deep integration into a relatively invisible build system is what made it difficult for Copilot to work with.

One of my takeaways from this experiment is: the skill of designing and building great abstractions is going to continue to be super important for software developers, even as we delegate the consumption and usage of those abstractions to the machines.

Attention is a precious resource and Copilot doesn’t care about yours

Copilot’s completions are terrible. The most rage-inducing aspect is that it will often try to complete comments, which misses the point entirely. Comments are about intent; I write them to communicate, and to provide context that’s not in the code itself. It’s almost tautological – you can’t infer the comments from the surrounding code, and if you could, then you didn’t need them. There’s a plugin here which disables smart completion for comments.

I also found that Copilot put way less ’effort’ into developer experience and consistency than I do. I said earlier that LLMs don’t optimize for maintainability, and I think this is directionally similar. When I was trying to get the service worker running, there appeared to be no attention to ensuring that the code behaved somewhat similarly in dev or prod, which made it incredibly hard to debug and test. When I eventually switched to using @parcel/service-worker, they’d thought about this detail, though! There’s more that goes into good code than just that it’s technically functional in prod.

Magic ✨

There were a couple of moments that truly felt like magic. I’d asked my friend for a list of alloys that she wanted in this calculator app, and she sent me a screenshot of a website in Spanish. I copy-pasted that in and Copilot just… did the right thing.

At some point, it suggested that the extra metal added to the calculation was for sprues, which is a word that I’d never heard before and definitely had never used. It was pretty cool to just learn that as a side effect of working on the app.

I didn’t really read the HTML / CSS/ JS and I loved vibing my way through the styling

I didn’t really look at the HTML / CSS / JS until after I’d finished building. At some point I had the weird realisation that the code was completely foreign to me, even though I’d been working in it for an hour.

I find styling really annoying and I really enjoyed tweaking the layout / CSS with Copilot. I’d definitely do this again. Saying “hey make this look vaporwave but also like a calculator” and then having it get the aesthetic pretty right pretty quick was great. Part of this is probably that CSS is at the limit of my skill and I don’t always feel like messing around with it (though I love it for all its quirks). I definitely wouldn’t have sunk so much time into a theme as obnoxious as this if I were building by hand. Also, part of the problem with LLMs is that they add a bunch of superfluous code on (falsely) assumed needs – but this is actually really fun for styling in well-constrained environments. I’m very here for LLM-hallucinated design maximalism.

The disadvantage of not scrutinizing the code carefully is that I miss the opportunity to understand the problem better by making loads of tiny decisions as I prototype the solution. I think at this scope it was still very possible to get that feedback loop by just reading the code – but it’s worth thinking about if applying LLM tech to larger projects.

Miscellaneous one-line observations

• I suspect that strong constraints made this build easy – it’s a static site, which also makes it painless to deploy (it’s on Netlify).

• LLMs are terrible at consistency, and Copilot used 3 different shades of grey for the same type of hint text in three different places in the app. It’s worth noting that Tailwind’s design makes doing this easy, compared to e.g. defining a ‘hint’ class in CSS and using it everywhere.

• Copilot is either extremely cheap or very heavily subsidised at the moment. I’m on the free plan, and have only used 10.4% of my chat messages for the month. I could build something like this twice a week without paying a cent.

Which brings me to…

You could ship something small and fun like this every day

What’s really interesting to me about this is: you could build and ship something small and fun every day like this; something like Inktober but for tiny websites, or Advent of Code but more about the “what” than the how.

Back in 2011, when the Lean Startup stuff was first taking off, I met some guys at a startup hackathon² who were trying to MVP a new product every week for a year (I think they called themselves “52 startups”). At the time that felt nuts; I remember thinking it was simultaneously not enough time to prove out a concept properly, and also extremely ambitious. It’s weird thinking that the build time has shrunk even to the point where you could bang out one prototype a day.

I’ve built a bunch of small web experiments like this in the past and they usually take longer than three hours to build. Reasons to Celebrate was the last thing I made like this, and it took two solid weeks of tinkering, in total³. I’m honestly not sure that the LLM is faster at writing code, though – maybe the upsides are the same as the downsides; maybe it just runs roughshod over your sense of caution and makes a bunch of decisions really quickly. I find it much easier to say “that’s good enough” to something produced by a machine than I do to something I produce myself.

Ship it?

If you take something away from this this, I hope that it’s not:

• that LLMs will solve all your code authoring problems (they won’t)
• or that they’ll make developers more efficient (efficiency is a means, not an end, but also, jury’s still out?)
• or that they’re coming for your job (they are though)
• or even that they’re rapidly improving (they are).

It’s that you can use them to bring small, joyful, neon pink and teal websites into the world with (maybe?) less effort than ever before and you should totally just make a small silly website for the heck of it, for yourself, or for someone you love.

You might also enjoy:

• An Ode to Houseplant Programming
• Glitch is Killing Free Hosting, So I’m Saving One Special Corner of the Internet

And, if you’re in Berlin, SZ Jewelry Studio’s workshops.