DEV Community: Hiya Lukka

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.