Intro to Vibe Coding

This is an Intro to Vibe Coding, from my live workshop before the LFG Hackathon I helped host in Manchester. The goal is to build software for public-good, in any way, shape or form - led by experts in their field - not necessarily programmers!

Someone on the video call has just come out of a meeting about transport in Newcastle. They want a rail line from Newcastle Central through the Team Valley industrial estate, one of the largest in Europe, down to Chester-le-Street. There's no train access to Team Valley today. Part of the proposal reuses a disused railway, including a short stretch called the Bensham Curve that could connect via a hub at Newcastle Central. The old line had evenly spaced stations, but nobody knows whether those positions still match where people actually live.

The tool is Claude's Code tab, which can run code directly on your machine. The model is Sonnet, on the $20/month plan. "Hopefully we don't need anything too fancy."

Building the map

I started by making a new folder, opening a code editor, and writing a short problem statement in a markdown file (markdown is just a plain text format; a .txt works too). This gives Claude context it can refer back to later. Then I searched Google's AI Mode, in plain English, for "an open official data source, population by town, North East of England." It pointed to the 2021 Census. I downloaded the file into the same folder.

The census file was around 20-30 MB of text, so I asked Claude to create a subset of just the North East rows. While it worked, I opened the data myself and checked the columns: there was a region column with "North East" as a value. The subset came out at 12 KB. Smaller files mean faster processing and use less of the model's context window (its limited working memory), which gets you better answers.

The subset had no location data. I asked Claude whether it could get coordinates from an API (a way for programs to request data from another service) or somewhere online. It found that the ONS Open Geography portal publishes the same built-up areas, keyed by the same codes as the census, free and with no login, and added latitude and longitude columns on its own. I checked the output and noticed the longitudes were negative, then worked out why: Greenwich is 0° longitude, and Newcastle sits west of it. The numbers were correct. Worth checking, though, because the model is confident whether it's right or wrong.

For the map I used OpenFreeMap, a free map library I'd used on a side project (a live map of UK trains built from National Rail's data). You don't need to understand a library like this: find one, paste the link to the LLM. My prompt was literally "yes, build the map." I guess this is true vibe coding.

Claude plotted the towns. The attendee sent a picture of their candidate station list, including a park and ride where the A1 meets the old railway line, so I copied the names straight out of the image into Claude. It plotted those too, but it hadn't suggested anything on its own yet. So I asked for population density at the suburb level, hoping it could suggest ideal stops between Newcastle Central and Chester-le-Street. In parallel I asked Google the same question, which pointed at electoral-ward-level data. Claude had meanwhile found population clusters on its own, drawn something that looked like an electoral map, and then suggested where the stops should go.

"Flipping heck. That's so cool," said one of the group.

I asked Claude to show the old line and the new suggested line side by side. It didn't know the real track path, so at one point it tried to bridge the line straight over the river. I described the Bensham Curve to it by name and it tried again. Half the time I couldn't tell where it had found its data. "That's why we call it vibe coding, because you're vibing it."

Takeaways

The whole session ran under an hour, questions and tangents included. A few things are worth remembering if you try this yourself.

Be specific about the end question. One attendee put it well: vibe coding is still limited by your data and how you frame the problem. "How many people live more than 3 km from a station" will get you further than "where should the stations go."

Write heavy data to files, not the chat window. Don't paste a 20 MB spreadsheet into a conversation. Save it in the project folder and let the agent read only the bits it needs. Structured data like CSV (comma-separated values) or Excel files work well because the agent can write code to pull out relevant rows instead of loading everything into memory.

Run your own searches alongside the AI. Humans are still faster at single one-off lookups. LLMs win when there's a lot of data to process. I ran Google searches myself the whole session while Claude worked in the background.

Check the output at every step. The negative longitudes, the line drawn over the river: both were moments where reading the result caught a problem or confirmed a detail.

Pick your model on cost per task. I use Artificial Analysis (artificialanalysis.ai) to compare intelligence against cost per task. Crowdsourced leaderboards like Arena are useful, but they don't show cost, and cost is what matters when you pay per token.

Your turn

Claude works a lot like ChatGPT, so if you've used that, the interface won't feel alien. Google also has an AI coding tool called Antigravity that comes with a Google AI subscription. For small personal projects they're all roughly the same right now.

Pick a local problem you already care about, download a public dataset, and describe what you want in plain English. The model understands you even when you use fewer words, so don't overthink the prompt. If something goes wrong, describe what went wrong and it will try again.

Most of the people on that call weren't programmers, and by the end one of them was talking about taking the map to Gateshead Council. A question you care about and the habit of checking the answer will get you a long way.

The full transcript of the session is below if you want to follow along step by step.