Created: 2026-03-14 Updated: 2026-03-14 7 min read

I hate AI coding agents for my side projects

image this is just my continuation of my blog which I posted in jan called ai pessimism. I would have covered most of it in that blog but today I want to just rant, go all out and vomit whatever I feel while using claude code for my side projects. I see a trend now on how people go about building software. they do something called AI specification grounding driven vibe coding. read about it from here. in short this is nothing but the same thing what we used to do, the architect nails the spec first and then the team blindly implements it. now you don’t architect the technicalities, you just guide similar to how a product manager asks for features and the LLM generates the grounded spec first which has all the details from structures, APIs and everything. then you ask the LLM to generate a plan to implement the spec. it will spit out pointers like step 1 do this, step 2 do that from the spec etc. finally you again ask the LLM to implement the plan.md file step by step. 99% of the time your work ends here. then it will generate some working bullshit and you commit the code and go to sleep. You can ask me: don’t you review the code? ideally you should but let’s be honest if you are going with this spec driven approach, obviously you wouldn’t have read the spec properly because it can be as extensive as 20-30 md files based on your use case. at most you would rope in an AI reviewer like cursor bugbot, code rabbit etc.

Obviously the end product might work (definitely would have subtle bugs or unhandled edge cases) but I did this experiment of reading the code it generated. OH MY GOD. what shitty code. these agents don’t care unless we explicitly micro control and ask them to follow very specific instructions/code style. But in this spec driven development even if the API is nailed, a lot of subtle obvious things are missed and even if you get those things written in the spec, since you are loading insane data as instruction, the majority of the time it skips a few instructions and takes the shortcut. This is one way of vibecoding which I see very commonly. If you are asked to develop software this way and you don’t have the option to resist, if you are paid then go ahead, do this, take things step by step and be careful. One problem here is if a company is pushing you to follow these methods that clearly indicates they care about speed more than anything. so you have no other choice but to catch up with others and go ahead and generate all the pile of code.

Now you have enough context, now comes the main crux of my rant. my definition of vibecoding here is letting some tool write a large pile of code while you scroll your phone or do whatever. If you are paid to spit out code quickly and get some version out, sure you have to follow the company culture and do what it takes to get it there. But my problem is doing the same on your weekends. I got caught in a situation where it’s a CRUD thing which I needed to build over the weekend as my personal project. I got carried away with everything going around me and the easiest way to get it done was through vibe coding. so I started with it first thing on Saturday morning, 1 hour in I felt miserable. I am not used to this feeling because all of my personal projects are hand coded. the way I use AI is like a Stack Overflow, I go ask for quick questions or mostly syntax. I have a claude code subscription and I use it to set things up, fix grammar errors, add comments and sometimes help me debug and nothing more. claude code seems to do thinking and I don’t know what to do while it’s thinking. how awful it is to stare at the screen. this might be offensive but it really felt like coding cuckold. someone doing your favourite things instead of you and all you do is stare at it. funnily the whole tech scene enjoys spitting maximum lines of code and encourages this.

I code every day. I have to use LLMs/claude code at work to get things done. I started a new series called dev log where for 40 days (not continuous) I would enter whatever new things I have learnt. whenever I learn something interesting I would go there and put in an entry. it’s almost 35 days and I have only 15 entries but I code every day. all of those 15 entries are coincidentally the ones I did on my leisure time and nothing learnt on my work where I use coding agents extensively. sure I would have learnt a thing or two but the code generated by coding agents didn’t give me the confidence that I have learnt something new. it didnt stick in my brain.

here is my perspective:

in the end who wins here? it’s just the LLM providers. no one else. a 20 dollar plan won’t be enough. you can’t wait idle for 5 hours to restore tokens so you will get a 200 dollar/month plan, you will pay an additional 20 dollar for a code review bot and buy a 1,000 dollar Mac Mini to just run clawdbot and this goes on and on. so I have decided to create a proper boundary for when I will use these agents and when I won’t. This is very essential for me. I am early in my career. I want to become a world class engineer. I want to prioritize learning over anything else to sustain in this industry. This means stepping away from building weekend projects that involve heavy vibe coding. fortunately I haven’t built anything 100% vibecoded yet. today was the first experiment and maybe I will get through this and throw it away. for example I am not a frontend developer. I am not going to build a fullstack application if I am not going to learn react. I see picking up projects as very important because at this point you can build any v0 and 99% of the side projects we give up after the first release. I would rather dive deeper and give focused attention to whatever I wanna learn and improve rather than be a mindless money drinking token. funny how I have way too many thoughts after just day 1 of vibecoding. I feel really sorry for those early career engineers who do it without understanding these consequences. my aim is not to make money but to become a world-class computer engineer and help people solve harder problems; for that I need to go back to the basics, embrace all these changes on weekdays but touch grass on the weekends.