My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…
> Instead of fixing the things in the original PR, I'd often get a completely different approach as the response to my first review. Again, often broken in new and subtle ways. I didn't expect this initially but I am seeing it a ton at work now and it is infuriating . Some big change lands in my lap to review and it has a bunch of issues but they can ultimately be worked out. Then kaboom it is an entirely different c…
Writing Code Was Never the Bottleneck
161–170 of 400 posts
Re: Writing Code Was Never the Bottleneck
#162Earlier quoted context omitted.
I have a team that’s somewhat junior at a big company. We pretty much have everyone “vibe plan” significantly more than vibe code. - you need to think through the product more, really be sure it’s as clarified as it can be. Everyone has their own process, but it looks like rubber ducking, critiquing, breaking work into phases, those into tasks, etc. (jobs to be done, business requirement docs, domain driven design pl…
I pray for whoever has to review code you didn't bother writing
Not sure what to tell you otherwise. The code is much more thought through, with more tests, and better docs. There’s even entire workflows for the CI portion and review.
I would look at workflows like this as augmentation than automation.
Re: Writing Code Was Never the Bottleneck
#163Earlier quoted context omitted.
> - Many bugs were of a new kind (to me), the code would look like it does the right thing but actually not work at all, or just be much more broken than code with that level of "polish" would normally be. This reminded me of a quarter million dollar software project one of my employers had contracted to a team in a different country. On the face of it - especially if you go and check by the spec sheet - everything w…
This sounds like a tale of failed 'waterfall model' software development. Was it not possible to sees the quality issues before the project was finished?
The contractors simply wanted to get paid, naturally. The people who paid them didn't understand the original codebase, and they did not communicate with the people who designed and built the original codebase either. The people who built the original code were overworked and saw the whole bruhaha as a burden over which they had no control.
It was a low seven figure contract. The feature was scrapped after two or three years while the original product lived on and evolved for many years after that.
I hope that management learned their lesson, but I doubt it.
Re: Writing Code Was Never the Bottleneck
#164My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…
If LLMs will be able to write unit tests, this will get worse, because there will be no time spent reflecting about "what do I need" or "how can this be simplified". These are, in my opinion, how to characterize the differences between a Developer, Engineer, and Architect mindset. And LLMs / vibe coding will never develop actual engineers or architects, because they never can develop that mindset.
The easiest programming language to spot those architectural mistakes in is coincidentially the one with the least syntax burden. In Go it's pretty easy to discover these types of issues in reviews because you can check the integrated unit tests, which help a lot in narrowing down the complexities of code branches (and whether or not a branch was reached, for example).
In my opinion we need better testing/review methodologies. Fuzz testing, unit testing and integration testing isn't enough.
We need some kind of logical inference tests which can prove that code branches are kept and called, and allow to confirm satisfiabilities.
Re: Writing Code Was Never the Bottleneck
#165Coordination, communication, etc… honestly not that big of a deal if you have the right people. If you are working with the wrong people coordination and communication will never be great no matter what “coordination tools you bring in”. If you have a good team, we can be sending messenger pigeons for all o care and things will still work out.
Just my opinions.
Re: Writing Code Was Never the Bottleneck
#166Earlier quoted context omitted.
Not unless it is deterministic If I have to manually review the boilerplate after it generates then I may as well just write it myself. AI is not improving this unless you just blindly trust it without review, AND YOU SHOULDN'T
I'm not sure many seasoned developers are really using AI that much in their workflows.
If there's a secret, silent majority of seasoned devs who are just quietly trying to weather this, I wish they would speak up
But I guess just getting those paycheques is too comfy
Re: Writing Code Was Never the Bottleneck
#167Re: Writing Code Was Never the Bottleneck
#168Earlier quoted context omitted.
I guess answering "you obviously didn't write it, please redo" is not an option, because then you are the dinosaur hindering company's march towards the AI future?
Honestly, I don't think it matters who wrote it; ultimately it's about the code and the product, not the individual author. That said, a lazy contribution - substandard code or poorly LLM generated - just wastes your time if your feedback is just put into the LLM again. Setting boundaries then is perfectly acceptable, but this isn't unique to LLMs.
Re: Writing Code Was Never the Bottleneck
#169Wow a lot of the stories people are writing here are super depressing. If a junior developer is delivering you a pile of code that doesn’t work, hasn’t been manually tested and verified by them, hasn’t been carefully pared down to its essential parts, and doesn’t communicate anything about itself either through code style, comments or docs … then you are already working with an LLM ; it just so happens to be hosted i…
I see it as a sign of how bad juniors are, and the need of seniors interacting with LLM directly without the middlemen.
Re: Writing Code Was Never the Bottleneck
#170Earlier quoted context omitted.
I'm not sure many seasoned developers are really using AI that much in their workflows.
If they aren't I wish they would speak up more and push back against management more If there's a secret, silent majority of seasoned devs who are just quietly trying to weather this, I wish they would speak up But I guess just getting those paycheques is too comfy