Skip to main content

Vibe coding a climb recommendation tool: 10.000 routes from 100.000 climb reports in 4 days

I woke up at 10 a.m. on a Saturday with a huge headache. I was dehydrated, my eyes were half-blind from the screen, and I felt like I had slept for maybe four hours. I had gone to bed at 2 a.m. because I couldn't pull myself away from a prompt.

The night before, I had thrown a rough, three-sentence instruction at my AI coding agent to build a dynamic weather widget for a climbing map I was developing. I was too exhausted to even check if it understood what I wanted before passing out. Waking up, I dragged myself to the computer, refreshed the local environment, deployed the pending commits, and there it was: a fully functioning weather slider. I could scrub through the day and watch the weather change across a geographic grid.

I was as excited as a kid. I haven't felt this drugged by the pure progress of building software since I first discovered computer animations as a teenager.

It all started on a whim on Tuesday. I recalled a moment I had while driving home from a climb, in which I complained to my climbing partner that day that local climbing reports from our local climbing club weren't indexed by Google. Inspired by DHH’s recent keynote about "vibe coding," I figured, what does it cost to try?

I sat down and asked an AI model to one-shot an API that could scrape and return articles for specific alpine routes. By Wednesday, I had a working API deployed. It had scraped 12,000 reports from Slovenian alpinist clubs, extracted the metadata, and merged overlapping records.

When I deployed the initial version, the memory overhead of Ruby on Rails was too high for the tiny instance I wanted to rent. So, I prompted the AI to rewrite the entire backend into Python using FastAPI. It did. We wrote tests, spun it up, and it ran flawlessly on the cheapest tier using just 90MB of memory. I even built an MCP (Model Context Protocol) server so I could query the database directly from my AI clients.

Then things escalated. I wanted a map. An hour later, I had a map. But matching route names and geolocations from unstructured club data is messy. Instead of manually fixing the data, I gave the AI agents tools to research the mountains themselves. I then told the system: “Look at the climbs in this sector and fix the duplicates.” It went out, researched the names, verified which routes were actually duplicates versus just similarly named, and merged them with almost zero interaction from me.

Just as I thought I was wrapping up, I discovered something else: over 80,000 additional climb annotations hiding in the club archives. These were basic logs without much description, but I immediately ingested all of that information to drastically improve the quality of the route suggestions and seasonality histograms.

By Friday, the core of prviklin.si was done. I shared it with some classmates from the AAO alpine school on Saturday, and their minds were blown.

Over the course of the build, I spent about €200 on LLM API costs for data processing—absolute peanuts considering it standardized nearly 100,000 data points, cross-referenced driving times, and built seasonality histograms. I did hit some walls; a side quest to have the AI automatically annotate the start of climbing routes from topo images failed completely.

But watching this come together made me realize something profound about where our industry is right now. I used to think vibe coding was just for baby projects or trivial scripts. I was wrong. The project scaled, the complexity grew, and the AI kept up, adding features at a pace I could never match manually.

It’s incredibly exciting, but also a bit sobering. If I can build this today, someone with a better AI might rewrite it in three months. The barrier to writing code is approaching zero. We are entering an era of rapid, relentless idea validation. But because the code itself is no longer the bottleneck, I believe the actual moats of the future won't be software—they will be data quality, long-term relationships, and user trust.

Comments

Post a Comment

Popular posts from this blog

The Increased Addictiveness of Today's Video Games

This is a guest post by Miles Walker, a freelance writer and blogger who usually  compares car insurance  deals over at CarinsuranceComparison.Org. His most recent review looked at the best  car insurance quotes . Video games have always held some addiction, but now more than ever that addiction is growing. People are spending more time than ever playing the games, and game designers are constantly finding new ways keep it that way. Their efforts have a been a complete success, and some games have true addicts, addicts who play 24 hours a week or more. Visual enhancements Video games have come a long way since a certain duo of Italian plumbers started showing up in people's houses in the late 1980s. By leaps and bounds, video game graphics have become alarmingly sophisticated. Each graphical improvement increased a game's possibilities and added more depth to video games. Designers began thriving on this depth, making games with more achievements, unlocks, lev...
21 comments
Read more

Basic cell counting and segmentation in Matlab

Counting cells manually is a tedious error prone process for humans. Given a large data set of microscopy images this task can be achieved much faster by means of basic computer vision techniques. In this tutorial we will segment cells from an image following a method similar to the one presented by Yongming Chen in 1999. The method uses basic morphological operations  and the watershed algorithm to segment the cells. Nowadays better methods for cell segmentation exist. This method was chosen for its simplicity and ease of implementation. We start with an image of cell-like structures by Anna-Katerina Hadjantonakis and Virginia E Papaioannou . A = imread('cells.jpg'); We convert the image to grayscale: I = rgb2gray(A); To be able to extract the dimmer cells, it is necessary to perform some local contrast adjustments I = adapthisteq(I); Objects on the borders can be caused by noise and other artifacts. We can eliminate objects on the borders...
1 comment
Read more

How to differentiate between a Zeelander 44, 55 and 72?

One day, your life might depend on being able to tell the difference between a Zeelander 44, a 55 and the 72. At first glace, these boat models are quite similar to each other. You could easily think that a Z44 is a Z55 closer to you. Three different models. Which is which? To figure this out, you can spend 5 hours manually reviewing and annotating a thousands photos, deleting bad training data, and staring at tiny thumbnails photos of these boats until your eyes start bleeding. Then, put this data into a ResNet34, and see that after all of that effort you are able to tell each model from the others 60% of the time. In other words, it guesses correctly less than every two out of three attempts. A ResNet34 can tell these models from each other 60% of the time. That's crap. A waste of time and money. Here is how you differentiate these models like a human. The Z44 has windows in sets of two, the Z55 has windows in sets of three, the Z72 has an uneven window layou...
2 comments
Read more