DEV Community: Krešimir Iličić

Guided Vibecoding YouTube Summary Project

Krešimir Iličić — Sun, 15 Feb 2026 15:08:04 +0000

Right now we are in a phase where everyone creates their own "AI SAAS". LinkedIn is flooded with these "AI will replace all devs" dumb posts and I can't wait for it all to fade away.

In the meantime, I've decided to take AI and use it as it should be used, as a tool. However, this time I wanted to go all-in and see how good code could the best AI models write if I guide it from architectural side and review what it's doing.

The majority of the code was written by Claude Opus 4.6 while minor tasks were done either by Claude Sonnet 4.5 or GPT-5 mini for super simple ones.

But first, let's start with from the beginning.

The problem origin

It's super hard to keep up with all the newsletters, YouTube channels, documentations and I simply don't have enough time to go through it all. So what I usually did is if I run into an interesting YouTube video but it's too long, I'd use Perplexity or other AI platforms to summarize it for me.

Manual workload

Even though that process saves time, it is still manual and I would need to browse through YouTube to find what I want to summarize in the first place.

I knew there is room for further improvement.

The solution

The first idea that came to my mind is what if I could have a scheduled job of curated YouTube channels that I handpick summarized each day. Sure, I'd need to spend some time initially to choose which channels to put there, but that's still better than the previous process.

It's a 1 hour total investment vs 1 hour daily investment.

That's when the idea was born.

I wanted to have some kind of a "dashboard" which I could access from multiple devices hosted on a server and available 24/7. The design had to be:

Responsive
Simple
Intuitive

The channels would be added through an "Admin panel" where I could add or remove those I want summarized. The trick is, I didn't want to summarize all available videos from each channel as some of them might have more than a thousand videos.

That's when I decided to put a scheduler (cron) job to fetch videos from the channels on the list every day at a certain time. If the channel had any new videos published in the last 24 hours, those will get summarized and shown on the dashboard.

Since the page would be publicly available, I had to protect it with some kind of a login for the "admin panel" as I didn't want other people messing with it. The stack I chose was:

VueJS for the frontend
ExpressJS for the backend
PostgreSQL for DB
... and a few more external services visible in the diagram

Fetching the videos

The first piece of the puzzle was to fetch YouTube videos of given channel. To do that, we can use the YouTube Data API which allows us to fetch videos sorted by date.

We are only fetching videos published in the last 24h so we are passing the "publishedAfter" prop to get those.

After fetching, we need to double-check the database to see if that video was already processed. If it wasn't, proceed to fetch transcription for the given video.

Fetching the transcription

Fetching the video transcription can be done through many different 3rd party libraries, but I wanted to do it for free. To do that we need to use the native YouTube transcript API which is used in NPM package called "youtube-transcript-plus". The downside of this approach is that YouTube can change its API in any time and break the app, but since I'm building it for myself, it was a tradeoff I can live with.

Summarize with AI

Now comes the fun part. How to choose an AI model with so many to choose from? Well, my goal was super simple:

Spend the least amount of money
Doesn't have to be the best model on market
Gets the job done

I decided that it doesn't have to be the "best model" because the task is super simple and generally all AI models are good enough with such simple tasks. After all, it's taking a bunch of text and summarizing it.

So which one did I choose? Random free models from openrouter. What do I mean by "random" ? Well, OpenRouter can be seen as a platform for different AI model providers and they can update their models to no longer be free, so I've let OpenRouter choose a model for me instead.

How to do it through code? One simple line.

Basically, we just write "openrouter/free" as model and let the platform choose appropriate/available one for the task. We can also specify the instructions for summarizing, such as this simple one:

Finally, we get the summary and store it into the database. At that point we can access it via dashboard and it looks something like this.

Key notes

The project is hosted on Oracle VPS Cloud. It is dockerized and uses nginx as the reverse proxy. Total amount of money I spent during this project is less than 10$. That's because I'm using Github Copilot Pro and carefully craft every prompt.

Room for improvement

There is always room for improvement, depending on the end goal. I started this project as a simple way of keeping up with the news and to see which video is interesting enough for me to watch whole. It serves it purpose at the moment.

However, other people might benefit from some additional features like:

Configurable interval when the videos are fetched
Configurable models to process transcripts and summarize them
Multi user support
Simpler way to add channels (At the moment there is no automated mechanism to fill channel ID)

Everything being said, it was a fun small project and the AI tools are definitely great addition to programming when properly used. I've made myself a tool that I can use each morning while I sip my coffee and that's enough for me.

The most issues I've had when vibecoding this project was related to nginx and docker. I really wanted to force it out without manually intervening with it.

P.S I didn't waste time optimizing anything in the code, the goal was just to get it working. This is definitely not a production ready project.

Github repo available at: https://github.com/kresohr/youtube-summary

TypeScript to Go: Why does it really matter?

Krešimir Iličić — Mon, 07 Jul 2025 17:57:29 +0000

If you are in the web development world, you already know that TypeScript compiler will be migrated to Go (unless you've been living under a rock). But why should you care about it? Well the answer is simple, the typescript compiler migration to golang will improve your developer experience.

In this article I'll skip the stuff you have already seen and go straight to the point. People keep claiming “oh it's 10x faster!” but let’s pause. What does this actually mean for the folks writing code every day and is there a catch?

What’s Really Changing?

TypeScript itself isn’t changing. You’ll still write code the same way. What’s really changing is the compiler. You may know it as that strange thing that turns your TypeScript into JavaScript so browsers and servers can run it.

Before: The compiler was written in TypeScript, currently running on Node.js.
After: The compiler will use Golang instead.

Why Go, why not simply improve on TS?

Node.js (which is great for lots of things) just isn’t built for heavy lifting in this way. It’s single-threaded, easily gets bogged down, and eats memory like a hungry raccoon.

On the other hand, Go compiles straight to machine code. It has built-in concurrency (think of it as doing lots of things at once without breaking a sweat).

What Will Actually Happen?

1. Faster Builds
You change a file and the build will finish before you blink. Editors like VS Code will feel much faster. Autocomplete, error checking, all those little helpers? They’ll speed up quite a lot, even in monster-sized projects.

2. Less Memory Meltdown
The Go compiler uses less RAM. No more laptop fans sounding like Boeing 747 when you open a big repo.

3. Easy Installs, Fewer Headaches
Forget the “delete node_modules and pray” ritual. The Go-based compiler can be a single binary. Download, run, done. No more dependency tangles or Node version drama.

4. Scales Like Crazy
Got a huge codebase? Go handles it. Multi-core CPUs finally get used properly. Builds and checks can run in parallel, not stuck in a single line.

What Stays the Same?

Client-Side Performance:
The JavaScript that ends up in your browser is the same as before. Browsers don’t care how fast your code was compiled, they just run the final JavaScript. So, your website or app’s speed for users won’t change because it's still JavaScript at the end.

Server-Side Runtime:
If your TypeScript code runs on Node.js, it also won’t run faster at runtime for the clients/requests. Only the build process is affected.

You can basically think of it as an improvement for you as a developer rather than the end client. However, if we end up shipping the product faster, the clients will be happier as well 😆.

But… Is There a Downside?

Let’s be real. Nothing’s perfect.

Ecosystem Shift: Some tools or plugins that relied on the old Node.js-based compiler might break or need updates. Not everything will work out of the box, at least at first.

Learning Curve for Maintainers: If you want to hack on the compiler itself, you’ll need to learn Go. Most folks won’t care, but some will.

Platform Quirks: Go binaries are easy to ship, but there may be new platform-specific bugs or edge cases, especially early days.

Not Magic for Runtime: Your actual app won’t run faster in the browser or Node.js. Only the build and tooling speed up.

Happier Devs: Less frustration, more focus. That’s worth more than raw speed.

To read more about the decision behind migration, you should read the "A 10x Faster TypeScript" post from Microsoft.

The Fetch API Trap: When HTTP Errors Don't Land in Catch

Krešimir Iličić — Wed, 25 Jun 2025 17:04:11 +0000

Many developers assume that if an HTTP request has an error status code like 404 or 500 then the Promise will automatically reject and flow into the catch block. It might surprise you, but that's wrong.

HTTP errors remain in the try block when using native fetch API unless you manually throw an error (or use something like Axios).

What actually happens when we get HTTP 404 from our backend?

The native fetch API is implemented in a way where it only rejects (and triggers your catch block) when there's a genuine network problem. For example, your internet cuts out or if someone misconfigures CORS.

And what about those HTTP status codes like the 4xx and 5xx? They will come back as resolved promises which won't land in the catch block. UNLESS you manually throw new Error.

// Here's what happens with native fetch
async function getFetchData() {
  try {
    const response = await fetch('https://api.example.com/nonexistent');
    console.log('Response status:', response.status);

// You've got to manually check if everything's actually okay
    if (!response.ok) {
// This line ensures it gets picked up by the catch block.
      throw new Error(`HTTP error! Status: ${response.status}`);
    }

const data = await response.json();
    return data;
  } catch (error) {
    console.error('Caught in catch block:', error);
    // By default only network failures or other errors end up here
  }
}

If you work with native Fetch API, you have to specifically check that "response.ok" property to see if something went wrong.

Why This Confuses So Many Developers?

No wonder so many developers get confused when you consider that popular libraries like Axios work completely differently. Axios actually does what most of us expect would happen - HTTP errors automatically trigger the catch block.

How?

Axios is set in a way that the promise will get rejected if we get HTTP status like 400 or 500. You may read-up the Axios documentation to see how it works behind the scenes.

// With Axios, it works like you'd expect
import axios from 'axios';

async function getAxiosData() {
  try {
    // HTTP errors (4xx, 5xx) will immediately jump to catch
    const response = await axios.get('https://api.example.com/nonexistent');
// This only executes for successful responses (2xx)
    console.log('Data:', response.data);
    return response.data;
  } catch (error) {
    // Both network errors AND HTTP errors land here
    console.error('Caught in catch block:', error.message);
    console.error('Status code:', error.response?.status);
  }
}

Why Should You Care About This?

This isn't just some technical trivia - it actually matters for your day-to-day coding because:

Switching between libraries can introduce unexpected bugs if you're not aware of this difference
With fetch, forgetting to check response.ok can lead to silent failures that are a nightmare to debug
Legacy codebase might often use native fetch API rather than something like Axios