Comment by mcdeltat
5 days ago
Depending on your standards, seems like a potential indicator of companies to avoid?
Personally I still believe that despite AI being moderately useful and getting better over time, it's mostly only feasible for boilerplate work. I do wonder about these people claiming to produce millions of lines of code per day with AI, like what are you actually building? If it's then Nth CRUD app then yeah, I see why... Chances are in the grand scheme of things, we don't really need that company to exist.
In roles that require more technical/novel work, AI just doesn't make the cut in my experience. Either it totally falls over or produces such bad results that it'd be quicker for a skilled dev to make it manually from scratch. I'd hope these types of companies are not hiring based on AI usage.
When doing more technical / novel work you can’y vibe code it but you can still use ai tools to make things faster. Having Claude implement small chunks with strict direction and oversight is underrated in my opinion. Or just using it to search the codebase (where is the code that does x), implement tests, and do code review are all helpful. There is a lot of e-peen measuring around vibe coding but I think it’s really not the must useful workflow, it’s just chasing a dream.
Out of curiosity, can you elaborate on the size and nature of the "small chunks"? I'm very curious for examples!
Sure! I went through my Claude history and pulled out some of the most recent ones (anonymized a bit). I had it write code when it was rote / boilerplate work to save time, and other than that I used it more to discuss the code rather than write it for me. In between these, I was writing code myself.
Writing code:
- can you remove this <zustand store> and move the state here into <a new slice in a different zustand store>
- Can you update the unit tests for the working copy changes that need test updates / created (it wrote a bunch of tests which were satisfactory, I just deleted some redundant ones)
- I removed this <TypeName> type can the usages in this file be safety replaced with <OtherType>? (it analyzed the type differences, confirmed it was safe, and made the replacement, though an IDE could have done the replacement too)
- Can you fix this type error (it built a type guard function to address it, which is boilerplate code)
- is there a way to add the output here not just the input (it found a way to plumb some context through the codebase that I needed, pretty rote)
Other stuff I did in this time:
- can you review the code in commit <hash> (been doing this a lot)
- Seems my changes in this branch has broken <feature>. can you add logging to help me diagnose what is now wrong, and also analyze the git history to maybe get some theories on what maybe broke it (this can save a lot of time, digging through git history manually can be time consuming)
- This file doesn't work as expected anymore given that we've implemented <feature>. Can you investigate (another good time save, it's good at digging through a bunch of changes quickly)
Hope this was of interest to you!