Created: 2026-01-18 Updated: 2026-01-18 6 min read

Are you learning anything from your side project?

recap

I kept releasing a feature or two for the past 3–4 months, which my friend told me ideally AI would do in a week. I am tired of answering this question, so here is my attempt to consolidate my thought process(sorry if this is all over the place and its completely okay to not agree to this). I asked my friend this fundamental question: are you learning anything from your side project, or are you just drinking a ton of tokens? Do you genuinely enjoy 20$ and watch a tool spit out code that you dont understand much about why it does this way but sometning works like a black box? This article is not ranting about how useless AI is. If you think AI is useless, you are either living in a cave or old enough to not drop your ego and accept reality. It’s even mind-boggling to see terence tao solve erdős problems with the help of LLMs. After the outburst of these AI-assisted tools, the line between side projects and actual product building is blurred. There needs to be a clear distinction between the two. I am trying to put forward my case here.

Building a software MVP has never been this easy. A bunch of prompts and you get a version of the software. Even though this version is not always 100% of what you want it to be, at least you are a few tweaks away from a refined version of your software. This is all cool. But at what cost? Earlier, it was time bandwidth to build something; now it is token bandwidth.

What is a side project? The answer to this question is very subjective and opinionated. For many, it’s everything they do outside their day job. For me, whatever you build without a sign-in page can be considered a side project. You can argue that unless users pay, everything is chill. But for me, the moment you add a sign-in page, our responsibility increases because we have their trust and data (if you make a fool out of yourself and roll your own hacky auth…).

My problem is with how we junior engineer folks who aim to improve our craft use these tools. We all know that no day job will be “cutting edge.” The market keeps throwing new things at you, and that doesn’t mean you will incorporate all of them in your day job. So side projects are a way to dip our toes into the tech sea, explore perpendicular tracks, and figure out what we genuinely like to do. At this point, everybody has this realization. But this is where the diversion starts. How do we build one? Should I take time understanding and writing a solid foundation or go all out with prompting as much as possible? We are bombarded with content where the priority is always speed. “I built xyz over a weekend,” “I was able to build 100 different things in a month,” etc., etc. For an organization, speed is very important, at least at this point with AI. One or two ideas click, so a herd of companies pivot and try building the same product, and all they strive for is first-mover advantage and capturing a large market. This is why I am reiterating that there needs to be a clear distinction between a side project and an actual startup. The idea of speed and efficiency is also slapped onto those who build fun stuff over the weekend. which I hate the most.

Everyone has the same tools now, so everyone can prompt and build the same MVP within the same weekend. So whats the real fun here? Your prompting skill as a engineer? To show the world that you can afford ton of tokens? So first, stop boasting about building 10 different version v0s in a month. This is just pure common sense. I am very sure that if you blind-prompt for a year, there will be times when the model doesn’t understand the requirement, keeps rewriting things, and starts to circle around. Then you will go check the code yourself, only to see a huge pile of irreversible mess. You keep refactoring the code again and again. more importantly will you be in a spot to error and fix it by yourself? In ideal scenario you got to tell the agent about how you want to structure the code, what exact types to use, the exact design you are planning to implement. But this never happens maybe once or twice. When you are in the groove what I noticed is the agent is let loose and eventually it does whatever it likes.

Okay, I am deviating. You should definitely use AI tools in your day job. Learn all the latest tools, build your own workflow to efficiently deliver tasks, be very proactive, and do your best to iterate quickly and accurately. Even here, I see a problem. Tools have improved, but the process in large orgs remains the same. Despite having all the tools to build quickly, the timelines remain the same (what are these lads doing in their free time now?). But you have to be mindful about your AI usage when you code over the weekends. The majority of senior folks have very strong foundations and muscle memory. They have the repetition to spot problems and majority of these senior guys really want the speed which these tools provide. very ideal for them. Pull the plug today, and they will whine for a week, but they will happily go back to the way it was. But we juniors are going to suffer. Trying to build a skyscraper on a weak foundation will obviously be a disaster. I don’t like side projects with an “AI-first” building approach as an engineer. If your goal is to build a product and monetize it quickly, cool, go ahead. Building a product is not always the end goal for a techie, it is one among a million paths. But if you think mindless prompting to build 10 projects will improve your engineering skills… sorry my friend all it does is fills your resume and a hole in your pocket. Get your priorities right. What you actually wanted to do. recap

Does this mean I don’t use AI for my side projects? You should use them but mindfully. You can also check my blog on vibe coding. I do use them. I have a Claude Code subscription, but I have a restrictive list. I extensively use AI to create documentation, write CSS for me, handle basic frontend work (I still use HTML, CSS, JS, Tailwind), and quickly look up syntax (sometimes it backfires due to knowledge cutoff). for me writing simple CRUDs is monotonous, boring, and repetitive and instead of relying on AI I try as much as possible not to build those side projects because for me a side project needs to teach me something new and challenge me.

Just because you have a subscription doesnt mean you have to max out the monthly credits and keep churning out slop code. It took me some time to rewire my brain. For a couple of weeks, I felt left out (still feeling that way), felt things were slowing down, but now my priorities are clear. My side projects are my window to learn and become a better engineer, not to be part of the token-drinking cult. Currently, I am learning a new tech stack, and since I have been coding for over a decade (thanks to my uncle and mom for giving me an early start), I have a reference point for how things used to be. So I am slowly going back to the way I was coding in 2016. Read the docs first (now I use LLMs to dig deep into the topics), read relevant materials, which I would have skipped if I blindly relied on AI. It’s all about balance, and just don’t take the pressure of building and delivering things over the weekend.

I might be blindsided, might be on the wrong track, but I am doing this for the love of the game. So it’s fun, and even if I move slowly like a tortoise, I am unstoppable.