101–110 of 122 posts
Earlier quoted context omitted.
If you have to describe the code to the ai and then read through each line of it anyways, why not just write the code yourself?
Because it's significantly faster at both typing and looking up small details than you are.
I always wonder what kind of slop people are creating when they say they have a bajillion Claude instances all churning out code.
Earlier quoted context omitted.
The reality is that hacking code isn't always beautiful. Most of the time, it is mundane grunt work. You can always leave the core logic for your to work on and have the AI handle all the bits that you don't like to do. This is what we do for modelling for example, AI helps with the interface and data backends, the core modelling logic is hand-crafted.
> mundane grunt work. this is my favourite kind of work. i can switch my brain off and just do something repetitive for a bit. boredom is necessary for good ideas.
I think the article could be more accurately titled "A Guide to Gen AI / LLM Vibecoding for Programmers who hate their job" To me, someone who actually love programming, it makes vibe coding look like hell. > The workflow of vibe coding is the same as managing scrums or helping a student through a research thesis Which programmer wants that?! Just hearing the word "scrum" makes me want to run away and I know I am not…
But, what I found over time is that as my role grew, the amount of work that could be done grew exponentially. In grad school I had one project to work on, by postdoc there was 10 papers that could be juggled, now there's so many different projects/collaborations/contracts/etc. that I could be a part of that it's all just a matter of "do I have time for that?". Then the team sizes start to grow: having one student turns into 5, into a lab, into a team at one company, then a growing team at another, and an open source organization. In one decade life changed from "wake up, figure out what to program, make it" to "wake up, see the deluge of issues and PRs, start code review, try to get that done so I can start 'my' day", and I think most people in programming tend to have a trajectory like that. The role changes from "build something" to "find out where others are getting stuck and unblock them", plus 200+ issues files about trivial shit. The goal here is to to have the LLMs handle the trivial shit, I unblock someone, and then finally the glory hour of me getting to build something is back!
But I think this is why there are lots of very smart people who have decided they wanted to be individual contributors in Silicon Valley instead. And they are really well-respected, and you want them in your squad! If that's the direction you want to go, then you probably also are of the kind that avoids LLMs a bit (and are thus a good person to have on a team, balancing velocity people with precision people). But if you want to start driving bigger projects, sooner or later teams grow as that's the only way to put out the bigger grander idea.
But I do think that if Anthropic made a Claude stuffed animal with a very punchable face it would be a very hot selling add-on as while this can accelerate the day, sometimes it makes the stupidest decisions and you really have to think "okay it doesn't hate me, it's not trying to spite me, it doesn't even know me, but damn it tried to hide that it commented out the one most crucial test!"
generic advice about how you should use the same tool and methodology (claude code, scrum) that everyone’s already using, lot of hand waving about being “senior,” This may be the most 2025 blog post ever written. if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning the transcendental nature of LLMs and software, not…
> generic advice about how you should use the same tool and methodology (claude code, scrum) that everyone’s already using, lot of hand waving about being “senior,” This may be the most 2025 blog post ever written. This part tracks. It's honestly rather generic. > if anyone takes the art of software programming further using LLMs, it’s going to be young inexperienced people who grow up closely observing and learning…
I am definitely worried about that. I got into a mode of doing morning code review every morning due to having a bunch of active open source repos, so over time as they grow in activity I learned to adapt my schedule, mind set, and everything around how to do the right amount of code review (when to finish the PR yourself, when to give pointers to train a new contributor, when it's not worth your time yet to say more than "tests fail", etc.). I started for years pulling every piece of code locally, running it, figuring out why someone would make a change like that, etc. and then it took like 5 years before I could actually start to do code review well just by reading a git diff. I needed to know the domain, the language, the problem space, and how people tend to work, all well enough to make that simple enough to have a mental model.
Then, I tend to see some junior programmers put up LLM stuff and I go "oh just handle the extra memory allocations and it's good to go" and they go "wait handle what where?". If you can't eyeball that in under a minute of scrolling through the code... then you shouldn't be doing code review by scrolling through it yet. But if they keep doing it like this, they will never build that skill.
That's why I think the right LLM usage is really for those who have already built that code review skill. It's not to gate the usage of LLMs, but people will never learn if they aren't strongly engaging with the code at some level.
Let’s just call it like it is, Vibe coding takes away the thinking of the execution of steps to solve the problem and offloads that part of our mind to a text generator with intelligent emergent properties. If you enjoy keeping the intelligence sharp for laying out the steps to solve the problem and executing the steps then don’t vibe code. If you don’t mind the engineering skills atrophy then go ahead and vibe code.…
I don't see why it's an either or. As explained in the article, I'm still coding all day. Just some trivial PRs are getting done and tidied up while I'm doing so. You still have to do all of the code review, and you still have to solve all of the hard problems, you just do less of the refactoring by hand.
My recent vibe code experience made me realize it's almost exactly like being a tech lead managing offshore development. I learned early on that the key to leading successful offshore projects is precise, detailed specifications, and very rigorous code review and testing. Now I'm using the exact same discipline to "vibe" code. I really think there needs to be a different term for professional solution engineering usi…
Yeah, maybe it needs another name because yes when you say you're vibe coding everyone imagines some 20 year old kid with sunglasses spitting out Javascript and calling it Python. While the tools are the same, the understanding and the discipline is very different.
I think "tech lead managing offshore development" is an excellent analogy.
> For the record, I now have about 32 Claude agents continuously running in tmux windows that I can ssh to, so all day long I can just check via laptop or phone and keep plugging along. What's the cost of 32Cph?
This illusion that senior engineers are too good to fall in all the traps laid by vibe coding really needs to stop. Just yesterday I was reading the comment of a Principal Engineer saying "of course vibe coding carries a huge risk for more junior engineers that don't understand when the LLM does something that looks right but is actually wrong", as if just because they have more experience THEY CAN. No, you can't eit…
I always wonder what kind of slop people are creating when they say they have a bajillion Claude instances all churning out code.