DEV Community: Hiya Lukka

My Instagram saves were a graveyard. So I put a sloth on my laptop to dig through it.

Hiya Lukka — Sun, 25 Oct 2026 07:55:33 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

I have a folder on Instagram called "python". Another one called "ai". Every time a reel promises to teach me something in 60 seconds, I tap save and feel like I already learned it.

I have never opened that folder to study. Saving felt like progress, so I never needed to read.

That folder is the laziest thing about me, so I built the laziest possible fix: I stopped trying to be more disciplined and made a sloth do the reading.

What I Built

SlothShelf is a local-first AI that reads the links you saved and never opened, then tells you which few are worth your time.

You paste links, drop a bookmarks file or a WhatsApp "message yourself" export. A Gemma model running on your own laptop reads every page and writes a card for it:

Verdict: read, skim or skip, with a one-line reason
The gist in a short paragraph
4 to 8 key points: tools, commands, steps, numbers
A "worth knowing" list of the tools and concepts it mentioned one thing to try after reading

On Sunday, it builds a PDF digest: your best picks with the full detail, the rest of the shelf grouped by topic, a safe-to-skip list, and a list of everything it could not read. The idea is that the PDF is the thing you read. The 40 tabs are not.

Who gets to be lazier? Anyone who saves ten things a week and reads none of them. That is me, and probably you.

Demo

Live demo page (sample data, so you can click around without installing anything): https://hiyalukka.github.io/slothshelf/

Code

hiyalukka / slothshelf

Slothshelf

SlothShelf

Save fast. Read slow. Skip the rest. A local-first AI that reads the links and reels you saved, then tells you which few are worth your time.

Live demo | Built for the DEV Hacktoberfest Open-Source AI Challenge, "Slow and Steady" | Categories: MongoDB Atlas, Gemma

What it does

Paste links, drop a bookmarks file or a WhatsApp export. A local Gemma model reads each page and writes a card:

Field	What you get
Verdict	read, skim or skip, with a one-line reason
Gist	A short paragraph covering the main ideas
Key points	4 to 8 concrete points: tools, commands, steps, numbers
Worth knowing	Tools and concepts mentioned, in one line each
Try this	One action to take after reading

Every week it builds a PDF digest: your top picks with full detail, the rest of your shelf grouped by topic, a safe-to-skip list and anything…

View on GitHub

How I Built It

Links → Deduplication → Fetch & Clean → Gemma Card + Embeddings → MongoDB Atlas

↳ Goals & Taste: Personalization signals that influence the system.

The open-source AI: Gemma (gemma2:2b) writes the cards, and nomic-embed-text makes the embeddings. Both run through Ollama, so no page text ever leaves the laptop. I use Ollama's structured output: the model has to return JSON that matches a Pydantic schema (verdict, key points, terms, topic), so the app gets data it can store instead of prose it has to parse.

MongoDB Atlas is the memory, not just the storage. There are three collections:

Links: one document per link, with the card and a 768-number embedding
Memory: my goals, plus a weight per tag that moves when I react to a card (+1 read, +2 loved, -1 skipped)
Digests: one document per ISO week

Atlas Vector Search does two jobs:

Find by meaning: I can type "that thing about evaluating RAG" and get the closest saved links, even if none of them contain those words.
Taste retrieval: Before Gemma judges a new link, I pull the closest links I previously loved and put them in the prompt.

So the sloth does not just score links against a generic idea of "good". It scores them against what I actually kept.
It keeps score on itself. The app shows an agreement rate: of the links I acted on, how often did my choice match the sloth's verdict? A tool that tells you what to read should show you how often it is right.

Why Does Open Innovation Matter?

A saved-links folder says more about you than almost anything else you own. Mine shows which careers I am eyeing, which skills I feel behind on, which hackathons I am scared of. I did not want to hand that to an API, and with open weights I did not have to.

Three things open models made possible that a closed API would not:

Privacy by default: Gemma reads the pages on my machine. Atlas only stores the card, the embedding and my signals.
No meter running: Reading a backlog means hundreds of calls. Locally, a big pile costs time, not money, so nobody has to decide a link is "not worth the tokens".
Swappable parts: The card model is one line in .env. Any model Ollama can run works, and I can inspect or change every prompt.

The Lazy Payoff

Here are my real numbers from running it on my own saves:

Links imported: 6
Read by Gemma: 5
Verdicts: 3 read / 1 skim / 1 skip
Links I actually opened from the digest: 4
Agreement rate: 78% over 42 links

Prize Categories

Best Use of MongoDB Atlas: Atlas holds the cards, the memory loop and the weekly digests, and Atlas Vector Search powers both find-by-meaning and taste retrieval.

Best use of Gemma: Gemma writes every card, locally, with schema-constrained output

Your Client’s GST Bills Never Leave the Laptop: BillBook

Hiya Lukka — Fri, 16 Oct 2026 08:05:47 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built
BillBook turns GST bill photos into verified, import-ready rows for Tally or Excel. It runs entirely in your browser, so client data never leaves the laptop.

Picture a small accounting practice in the last week of the month. A pile of supplier bills, some photographed at an angle, some in Hindi or Gujarati, all waiting to be typed into Tally by hand. It’s slow, error-prone work, and it’s billed by the hour.

The obvious fix is to upload every bill to a cloud AI. For an accountant that’s a non-starter. Those bills carry a client’s vendors, GSTINs and margins. And a per-bill API cost eats the thin margin on exactly the small clients who need the help most.

BillBook takes the other route:

Drop a bill (photo or PDF) and a Gemma model of your choice reads it on your own device. Pick a smaller one for older laptops or a larger one for harder bills.
Get a structured row: vendor, GSTIN, invoice number, date, taxable value, CGST, SGST, IGST and total.
See a status on every row. Only rows marked OK are safe to import without a look.
Edit any cell and the checks re-run instantly.
Export to CSV for Tally or Excel.
Works for English, English + Hindi, and English + Gujarati bills.

Who would pay:

GST practitioners, bookkeepers and small CA offices handling bills for several small-business clients. They bill for data entry today. BillBook cuts the time per bill and costs ₹0 per bill to run.

The side hustle:

A freelancer or student bookkeeper can offer “bill digitisation” to local businesses at a flat monthly fee. There’s no API bill and no server to maintain, so the margin is the whole fee.

Demo

🔗 Live app: https://hiyalukka.github.io/Bill-Book/

Needs a WebGPU browser (Chrome or Edge). The first model load takes a few minutes, then it’s cached locally.

Code

hiyalukka / Bill-Book

🧾 BillBook: bills in, books out

Turn a photo or PDF of an Indian GST bill into a clean, verified row ready for Excel or Tally. An open-weight AI model reads the bill inside your browser, so the bill itself is never uploaded anywhere.

Live demo → ·

Built for the DEV × Hacktoberfest Week 3 challenge, Side Hustle: open-source AI that someone would actually pay for.

The problem

A small accountant or shopkeeper receives bills as WhatsApp photos, crumpled paper, and inconsistent PDFs. Someone then retypes vendor, GSTIN, date, taxable amount, CGST/SGST/IGST, and total into a sheet by hand. It is slow, boring, and one wrong digit can cause a GST mismatch.

Sending client financial documents to a cloud AI is often not an option, and per-bill API fees eat into a small tool's margin.

What BillBook does

Cleans the image (grayscale, contrast, sensible resizing).
Reads the text…

View on GitHub

How I Built It

BillBook is a static site hosted on GitHub Pages, with no backend. All inference happens in the user’s browser.

Open-weight stack

Models: a picker offering different gemma and qwen models, running on-device via WebGPU.
Text from the bill: OCR engine, or "Gemma reads the image directly", with English, Hindi and Gujarati options
Frontend: html, hosted on GitHub Pages

Why a model picker instead of one fixed model?:

Users have very different hardware. A small Gemma loads fast on a modest laptop but misses more fields. A larger one is more accurate but needs more memory and a longer first download. Rather than guess for everyone, BillBook lets the user choose.

Gemma is a small model running in a browser tab, and small models make mistakes. In accounting, a confidently wrong ₹11,800 is worse than no answer. So extraction is only half the pipeline. Every row passes three independent checks before it earns an OK:

GSTIN checksum. A GSTIN carries a check character, so a hallucinated or misread number fails validation.
Tax arithmetic. Taxable value plus CGST, SGST and IGST must reconcile to the total.
Grounding. Every number Gemma outputs must appear in the scanned text. If the model invents a figure that isn’t on the bill, it’s caught.

The checks are plain deterministic code, so Gemma can be wrong without the user being misled. Failed rows are flagged for review instead of silently imported. Editing a cell re-runs all three checks, so the human fix and the machine verification live in one loop. It also makes the model picker safe: switching to a smaller model is fine because its mistakes get flagged.

Limits I’m upfront about. PDFs process page 1 only. Handwritten or badly skewed bills fail more often, which is what the status column is for. [Add anything else you found.]

Why Does Open Innovation Matter?

Four things BillBook does only because Gemma’s weights are open:

Privacy by architecture, not by policy:
A closed API means sending financial documents to someone else’s servers and trusting their terms. With Gemma running in the browser, the data physically can’t leave the device. For accountants, that turns “can I use AI on client data?” into a yes.
₹0 per bill is a real business model. Per-token pricing punishes high-volume, low-margin work like bill entry. Local inference makes the marginal cost zero, which is what lets a student or freelancer run this as a side hustle.
Open weights let me design around the model’s weaknesses. Because Gemma runs on the user’s own machine, I could watch how it fails on real bills and build the verification layer around those failures. With a hosted API I’d be hoping the vendor’s next update doesn’t change its behaviour on my bills.
Users choose the trade-off, not a vendor. With a closed API you get whichever model the provider serves, at whatever price they set. With open Gemma weights, BillBook offers a size choice and each user picks speed versus accuracy for their own hardware.

My First User

A small grocery shop owner in my neighbourhood. His shop handles supplier bills every week, and he keeps the records by hand.

I showed him BillBook on my laptop and walked him through a sample bill. His reaction was about three problems he already lives with:

Time: Writing up bills by hand takes a long stretch of his day, and the work is tedious and complicated.

Fragile records: Paper records aren’t permanent. A bill can be lost, damaged or misplaced, and then the record is gone.

Where the data goes: He liked that the bills are read on the device and don’t go to anyone else’s server. For a shop owner, supplier prices and purchase volumes are business information he wants to keep private.

What struck me is that he didn’t ask about the AI. He cared about the three things above.

Honest status: he hasn’t paid for it, and this was a first demo, not a long-term trial.

Prize Categories

Build with gemma category

Your Phone Is the Worst Part of a Walk. So I Built an AI That Hides It.

Hiya Lukka — Sun, 11 Oct 2026 05:46:36 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Every AI product I know measures success the same way: how long you stay. Sessions, minutes, daily actives. For a challenge about getting people off the screen, that metric is exactly backwards.

So I built Look First, an AI naturalist with one unusual goal: to be used for as little time as possible.

Here is how a session goes:

It refuses to name anything. Instead, it gives you three tiny tasks. Look at the edge of a leaf. Touch the bark. Listen for a repeating call.
The screen goes dark. A phone-away timer takes over the whole page: "Eyes up. I'll be here when you get back, and I'm happiest when you don't need me." Two minutes. You go and look.
You come back and report what you noticed. Only now does it answer, with a best guess, a confidence level (low, medium or high), one honest thing it might be getting wrong, and one tiny next quest nearby.
It tells you how long you spent outside. "You spent 2:00 looking up instead of scrolling." That number goes into a downloadable markdown field journal.

Most identifiers turn a living thing into a search result. Look First tries to turn you into someone who notices. By the third time you do the tasks, you may not need the answer at all, which is the point.

It is for anyone who has walked past the same tree every day and never learned what it was: students on campus, new hikers, a parent with a curious kid.

Demo

https://hiyalukka.github.io/Look-first/
The first visit downloads the model once, then it runs on your device. (Yes, I know the irony of a slow first load in a project about leaving the screen.)

Code

hiyalukka / Look-first

🌿 Look First

An AI naturalist that makes you look up before it answers.

Most plant and bird identifiers keep you staring at a screen. Look First does the opposite: it refuses to name anything until you've actually looked, then reveals what you found. It runs entirely in your browser using an open-weight model (Gemma), with no server and no API key.

Built for the DEV Hacktoberfest Open-Source AI Challenge, Week 1: Touch Grass.

▶ Try the live app

The idea

Every AI product measures success by how long you stay. Look First measures success by how little you use it.

📍 Say where you are. One sentence about what's around you.
👀 Get three tiny tasks. Look at the leaf edge, touch the bark, listen for the call. The AI will not identify anything yet.
⏱ The screen goes dark. A two-minute "Eyes up" timer takes over…

View on GitHub

One index.html file. No backend, no build step, no API key.

How I Built It

The open pieces do all the work:

Gemma (gemma-2-2b-it, 4-bit quantized), an open-weight model from Google.
WebLLM, open-source in-browser inference that fetches the model into the browser and runs it on the device GPU through WebGPU.
Plain HTML, CSS and JavaScript on top.

The idea lives in the prompt, not the code. The model gets a strict two-turn script. On turn one it is forbidden from identifying anything and must give exactly three short observation tasks. On turn two it uses my observations to guess, and it must state a confidence level and what it might be wrong about.

That second rule came from a real worry. A 2B model can sound completely sure while inventing a species. Instead of hiding that weakness, I built it into the product: every answer admits its uncertainty. Because the person has just examined the real thing, they are a better judge of the answer than the model is.

Why browser-only? Honestly, it started as a workaround. I did not have Ollama installed and the deadline was that same day. But the constraint became a feature: anyone can open a link and run the AI, with nothing to install.

Known limits:

It is text-only. You describe what you see, and it does not look at photos yet.
It needs a WebGPU browser (recent Chrome or Edge).
The first load is a large one-time download.
A small model will sometimes be wrong. Check a local field guide.

My Field Test

I took Look First to the garden behind my campus library for about 15 minutes, and tried it on three things: a big tree, a small yellow flower and a bird I couldn’t see.

What it got right. For the tree, it asked me to look at the leaf edge and feel the bark. I typed “leaves smooth-edged, bark grey and peeling in flakes.” It guessed a plane tree with medium confidence and said the peeling bark was the main clue. Checking later, that matched. What I noticed was that I’d walked past that tree for a year and never touched the bark.

Where it struggled. For the bird, I only had a sound to describe, and I wrote “a repeating chirp, then a short whistle.” The AI gave a guess with low confidence and added that sound alone wasn’t enough to be sure. It was honest, but not very useful. I did what I’d do with a person: I waited, spotted the bird on a branch, and went back to the app with a better description. The second guess was more specific.

The dark screen. The “Eyes up” timer felt a bit awkward for the first ten seconds, since my hand kept reaching for the phone. By the second minute, I’d noticed that the flower had a fuzzy stem, which I wouldn’t have seen otherwise.

Why Does Open Innovation Matter?

A product that wants you to leave is hard to build on a closed API, because a closed API is a meter that runs while you use it. Look First is the opposite of that business model, and open weights are what make it possible.

It works where the trail is. Once the model is cached, there is no connection to lose. A hosted API fails exactly where signal does, which is outdoors.
Your location stays yours. What you type says where you are and what is around you. Here it never leaves your device.
There is no meter. No API key, no bill that grows when more people use it, so a student can hand the link to a whole campus club.
The model is swappable. The page lists the Gemma models it finds and lets you choose, so a lighter one can run on a weaker laptop.

Open weights did not make the model smarter than a frontier model. They made it possible to build something with no incentive to keep you looking at it.

Prize Categories

Build with Gemma category

A professor couldn't find the right AI tool. So I built a model that isn't allowed to guess.

Hiya Lukka — Sun, 04 Oct 2026 14:10:17 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

A tool-finder for a friend of mine who teaches economics and commerce. She needs AI tools for research, note-taking and managing her academic work. The last time she went looking for help with a research paper, she came away confused.

My read is that "research paper" isn't one job. It's finding papers, reading them, managing references, running the numbers and writing, and each of those has different tools. So she types her goal in her own words, and the tool gives her the kinds of work involved, with tools for each.

The key design choice is that the model never names a tool. Asking a language model "which AI tool should I use?" is risky: its memory of tools is dated, and it can name products that don't exist. Here, Gemma 4 only decides which of seven fixed task types her goal involves:

Find papers
Read
References
Analyze data
Write
Notes
Teaching and admin

Plain code then looks up tools for those types in a catalog of 21 tools that I wrote by hand.

Demo

It runs on a local model, so there is no hosted link. Screenshots are below.

Code

hiyalukka / ai-tool-guide

Local, open-model helper that tells a non-technical professor which AI tools to use. Runs on Gemma 4 through Ollama.

Which AI tool should I use?

A small local tool built for a professor friend who found it hard to pick AI tools for research, notes and teaching.

She describes her goal in plain words. A local open model (Gemma 4, through Ollama) decides which kinds of work the goal involves. The page then lists tools for each step from a hand-written catalog. The model never names tools itself, so it cannot invent one. Nothing she types leaves her laptop.

Run it

You need Ollama and Python installed.

ollama pull gemma4:e2b
In one terminal: ollama serve
In another terminal, in this folder: python serve.py
Open http://localhost:8000/ai-tool-guide.html

Switch to gemma4:e4b with the dropdown for better answers, but slower.

Limits

The tool catalog is written by hand and covers 21 tools, aimed at economics research and teaching. Tool descriptions may go out of date.
I did not run a formal evaluation, so…

View on GitHub

How I Built It

Model: Gemma 4 E2B, run locally through Ollama on a 12 GB student laptop.
Structured output: the model's reply is constrained to a JSON schema whose only allowed values are the seven task ids, at temperature 0. That is what makes an invented tool impossible.
Catalog: a hand-written array in the page, where each tool is tagged with the task types it serves.
Front end: one HTML file.
Server: a small Python script that serves the page and forwards requests to Ollama, because browsers blocked the page from calling Ollama directly.
Setup: ollama pull gemma4:e2b, then ollama serve, then python serve.py. The repo README has the details.

Why Does Open Innovation Matter?

Her data stays with her. Unpublished drafts and student work never go to an API.
No internet needed.
Costs nothing to run. No key and no billing.
Swappable and editable. The page has a model dropdown, and the behaviour lives in two things she can change: the task list and the catalog. No vendor decides what gets recommended.
Gemma 4 is Apache 2.0. That makes it open-source in the plain sense.

What it cost me

I asked Gemini (Flash, in the Gemini app) for help running a regression on survey data from 300 households in Excel. It suggested Excel's built-in Data Analysis ToolPak, a practical answer that needs no code.

I gave my tool the same question.

My catalog has no Excel entry, so it could not give Gemini's answer. The restriction that stops it from inventing products also stops it from knowing the obvious one. For a non-coder with spreadsheet data, that is a real cost, and it's the main thing I learned.

What I saw

I did not run a formal evaluation, so I won't give accuracy numbers.

For "120 answer sheets to grade this weekend and it's taking forever", it chose one category, teaching and admin, and returned Gradescope and Notion. The model made a single decision: the category. Tools within a category are not ranked, so both appear. That run took 56.4 seconds on E2B, probably including model loading, and I did not measure warm runs.

What's next

Add tools she already has, like Excel, alongside the AI tools.
Rank tools within a category.
Have my friend write 15 of her real requests and label the right answers, then measure it properly.
Compare E2B with E4B.

Prize Categories

Best Use of Gemma. Gemma 4 E2B running locally through Ollama.

When Impressive Code Isn't Actually Working: A Vibe Coding Epiphany

Hiya Lukka — Sun, 26 Jul 2026 15:52:31 +0000

- The Setup

I've been working on a semantic recall application called VaultAI for AI tools and prompts I've previously used and needed to remember, and somewhere along the way, I realised that I've relied too much on "vibe coding" (describing what I want to code and mostly letting the AI generate the actual implementation) to create a chatbot for recalling those entries via a prompt

This has ultimately led to the creation of an impressive, working demo, which impressed my AI/ML club peers and got me good positive feedback for a presentation I gave at the club

- The Bug

A bug that would have been apparent at first glance of the demo wasn't the real bug; it was discovered later when trying to implement more proper API calls and test the chatbot at a closer distance. I ran into issues with some of the API not being handled correctly, and upon inspecting the code to fix them, I noticed that I couldn't actually understand it

The code I've been working with wasn't simple and elegant; it was overengineered in a way that the AI thought would make it seem better than it actually was. It took me a while to realize that the bug was my own ignorance of the code I was writing

- The Realization

I realized then and there that I didn't actually want to be a software engineer, creating generic applications and websites with no particular purpose other than to fill requirements

I want to become a machine learning engineer, and to do so, I have to think like one, not a generic software engineer. Vibe coding let me off the hook by doing the easy way out, and the demo worked well enough for me to get positive feedback from others, but I wasn't thinking properly and assumed the code to be good when it wasn't.

- The Resolution

So instead of pushing the commits to fix the API calls, I did the responsible thing and decided to rewrite VaultAI from the ground up, in steps

First, I wrote the lowest-level implementation of VaultAI I possibly could

I wrote the CLI and got all of the core logic to work, and made sure I understood every single line of code. With that being said, I began working on the next step: working on the backend, slowly implementing it with SQLite, then ChromaDB for vector storage, then FastAPI for the backend API, making sure to understand each and every part before moving on

While it did take longer than vibe-coding the whole thing at once, it ultimately helped me.

- The Resolution Part 2

The resolution wasn't really fixing the bugs; the resolution was me realizing how far I've been letting myself go. Being able to catch myself before I go too far down a slippery slope is important to me, and this time, I've done exactly that.

If you find yourself in a similar situation to me, I suggest you take a moment to ask yourself why you are even doing what you're doing. If you can't explain all of the code you've written, there is likely something wrong

What a Creativity Book Taught Me About Being a Better AI/ML Engineer

Hiya Lukka — Sat, 25 Jul 2026 05:59:40 +0000

I picked up a creativity book expecting a light read between semesters. What I got instead was something that quietly rearranged how I think about engineering itself.

Here's the thing nobody tells you when you start out in AI/ML: the syllabus teaches you tools. It teaches you Python, it teaches you models, it teaches you the math underneath. What it doesn't teach you is the thing that actually separates a good engineer from someone who just knows how to use tools — and that's the part this book is about.

Creativity isn't invention. It's problem-solving.

Most people hear "creativity" and think of inventing something out of nothing. The book reframes it completely: creativity is your ability to find possible solutions to a single, specific problem. That's it. Not magic, not talent you're born with a habit you build.

And the habit starts somewhere uncomfortable: asking questions out loud.

I noticed this about myself and about a lot of us in tech: we stay quiet when we don't understand something. We Google silently. We assume. We nod along in lectures and figure it out later, alone, at 1 AM. But that silence is exactly where creativity dies. If you never voice the question, you never get pushed toward the answer that isn't the obvious one.

Connecting dots is a skill, and it's literally what AI is built on

One line from the book stuck with me: creative people don't always have more ideas. They just notice connections that others skip past.

Sit with that for a second as an AI/ML student. Recommendation systems connect your past behavior to future choices. Language models connect patterns across billions of sentences. That's not magic; that's structured dot-connecting, done at a scale humans can't do manually. The systems we're all trying to build are, in a strange way, just automated versions of the exact skill this book is asking me to practice by hand.

Everyone looks. Very few actually observe.

This might be the idea I've carried with me the most. Hardas talks about slowing down enough to notice what's already in front of you the details everyone else walks right past.

Translate that into engineering terms and it becomes almost uncomfortable: before you build any AI solution, you have to actually understand the problem. Not skim it. Not assume you already know it because you've seen something similar before.

The best AI models don't fail because of bad algorithms. They fail because someone didn't observe the problem carefully enough to begin with. Creativity and good engineering both start with paying attention.

The line that stayed with me

"Engineers who can think creatively will build things AI can't automate."

This book didn't teach me to be an artist. It taught me to be a better engineer.

That distinction matters more than it sounds like it does. As a second-year student watching AI automate more of the "tool-use" layer of engineering every semester, the actual differentiator isn't going to be who can write code fastest. It's going to be who asks better questions before writing any code at all.

I'm building VaultAI and learning ML engineering in public — sharing the real process, struggles included. If this resonated, I'd love to hear what you're reading right now that's changed how you think about your own field.

What Nobody Tells You About Learning to Code in the Age of AI

Hiya Lukka — Sat, 06 Jun 2026 06:28:32 +0000

Six months ago, I sat down with a YouTube playlist, a blank notebook, and one goal: learn Python. What I did not expect was how hard it would be, not the Python itself, but figuring out how to actually learn it.

I started with a YouTube playlist. Simple enough. Except nobody tells you what to do after you watch a video. Do you rewatch it? Take notes? Jump straight to code? I had no system. I'd watch a concept, feel like I understood it, open VS Code, and stare at a blank file.

That's when I realized I had fallen into passive learning. And passive learning in the age of AI is a particularly dangerous trap, because it's so easy to confuse activity with progress. I could watch a video, feel good. I could ask Claude to explain a concept, feel good. I could even ask AI to write code, read it, nod along, and feel like I'd learned something. I hadn't. I'd just consumed. There's a difference.

The real moment of honesty came when I was stuck on a coding problem. My instinct, everyone's instinct now is to open ChatGPT or Claude immediately. And I knew, sitting there with the cursor blinking, that if I did that every single time I got stuck, I was building nothing. My brain would never develop the muscle of working through problems. I would be someone who can prompt AI to code, not someone who can think in code. And in a world where AI can already write decent code, the person who can't think independently isn't valuable. They're replaceable.

So I had to build a system that forced me to actually learn. After a lot of trial and failure, I landed on a 5-phase checklist that I wrote out by hand and kept next to my laptop.

Phase 1: is what I call First Contact — watch one focused video, then write a summary purely from memory, then discuss it with an LLM not to get answers but to pressure-test what I thought I understood.

Phase 2: is Deep Understanding — read a written source, write proper notes, map the concept visually, and list every edge case and exception I can find.

Phase 3: is Hands-On Practice — write 3 to 5 small isolated examples from scratch, then intentionally break the code, because understanding why something breaks teaches you more than getting it right.

Phase 4: is the Stress Test — ask an LLM to quiz me until I break, teach the concept back to it, and ask "what would an interviewer ask about this?"

Phase 5: is Cement and Connect — use the concept in an active project, write one thing I'd tell a fellow learner about it, and schedule a spaced review.

The rule I set for myself throughout all of this: AI is a tool for testing and pressure, not a crutch for getting unstuck. When I'm stuck on a problem, I sit with it. I struggle. I come back. Only after genuine effort do I use AI — and even then, I ask it to guide me, not solve it for me. It wasn't comfortable. It still isn't. But six months in, I'm now working through Python libraries and starting ML theory, and for the first time it feels like a foundation, not a facade.

If you're somewhere in the early weeks of learning to code, the question isn't which resources to use. It's whether you're actually building something in your brain, or just moving content through your eyes. The difference matters more now than it ever did before.

I watched a machine do the impossible. Now I'm learning to build one.

Hiya Lukka — Sat, 30 May 2026 05:53:00 +0000

There is a specific kind of silence that happens when you watch something that breaks your understanding of what is possible.

Not loud surprise. Not excitement.
Silence. The kind where your brain is working so hard to process what just happened that everything else goes quiet.

I felt that silence watching a machine play a board game.

Not because the machine won. Because of how it won, by making a move that no human player had ever made, in thousands of years of the game being played. A move the world champion later said he found beautiful. A move that came from no human tradition, no human teacher, no human intuition.

It came from a model that had learned to find patterns in complexity that the human brain cannot hold simultaneously.

That was the night I understood what ML engineering actually is.
And that was the night I decided what I want to do with my life.

What nobody tells you about ML engineering:
The popular version of AI right now is tools. Chatbots. Productivity apps. Automated workflows. And those things are real and useful.

But they are not what stopped me cold that night.

What stopped me was this: a machine that nobody explicitly programmed to win, that learned entirely through playing itself, millions of times, with no human data, no human guidance — found a solution that centuries of human expertise had never found.

That is not automation. That is not a smarter search engine.

That is a new kind of intelligence finding structure in problems that were structurally unreachable before.

ML engineering is the first discipline in human history where a person with the right model and the right problem can reach solutions that no human could have arrived at alone. Not improve on existing solutions. Not iterate faster. Reach solutions that were simply not reachable before.

And the people building those models are not working on productivity apps.

They are working on protein folding. Drug discovery. Climate systems. Problems that have broken every generation of scientists before ours, not because those scientists weren’t brilliant, but because the tools didn’t exist yet.

I want to be one of those people.

Where I actually am right now:
I want to be honest about this part. I am a computer engineering student. I have no internship. No research publication. No industry mentor. I am on Lecture 0 of CS50. I am working through NumPy. I am in the early weeks of ML theory, where everything is still matrices and probability and gradient descent and nothing yet feels like the thing I watched in that documentary.

Before I started this path, I built ClassFlow — an automated timetable generator that handles faculty constraints, room allocation, semester structures, and conflict detection for college departments. It works. It solves a real problem that colleges across India still solve manually in Excel.

But it does not learn. It cannot improve from its own mistakes. It has a ceiling, and that ceiling is the exact reason I am here.

My mornings now start with Python before anything else. Not after breakfast. Not after checking my phone. Before. Then CS50. Then ML theory. Then I watch people who are actually building in this space — not for motivation, but to learn how people inside this field think about problems.

Some mornings the gap between Lecture 0 and where I want to be feels so large it is almost funny.

I sit with that feeling. I do not try to resolve it with motivation or affirmations or a highlights reel.

I just open the laptop and keep going.

et is Google DeepMind. Or somewhere doing work at that level. Somewhere the question on the table is not how to make a product more engaging — but how to make a model capable of something no model has done before.

The students who start before they feel ready, who stay in the chair when the gap feels too large — are the ones who actually arrive.

Demis Hassabis was once sitting in a room full of the most brilliant minds he had ever seen, and he had a thought that most people would have called arrogance: what if we took all of this and aimed it at the problems that actually matter?

He was not yet building DeepMind. He was just in the room, with the idea, not yet knowing how to execute it.

I think about that a lot.

Every ML engineer who ever built something that mattered was once exactly where I am, at the beginning, with the theory still abstract and the application still distant. The difference between the ones who got there and the ones who didn’t was not talent. It was whether they stayed in the chair.

I’m staying in the chair.

If you are somewhere in the middle of this path, what is the one resource that genuinely changed how you think about ML? I am building my stack right now, and I want to know what actually moved the needle for people further ahead.