Earlier quoted context omitted.
LOC is useful here not because it's a metric for output but because it's a metric for _understandability_. Reviewing 200 lines is a very different workload than reviewing 2000.
It’s still a bad metric. I have worked with code where 1000s of lines are very straightforward and linear. I’ve worked on code where 100 lines is crucial and very domain specific. It can be exceptionally clean and well-commented and it still takes days to unpack. The skills and effort required to review and understand those situations are quite different. One is like distance driving a boring highway in the Midwest:…
Vibe coding and agentic engineering are getting closer than I'd like
111–120 of 958 posts
Re: Vibe coding and agentic engineering are getting closer than I'd like
#112Earlier quoted context omitted.
LOC is useful here not because it's a metric for output but because it's a metric for _understandability_. Reviewing 200 lines is a very different workload than reviewing 2000.
It’s still a bad metric. I have worked with code where 1000s of lines are very straightforward and linear. I’ve worked on code where 100 lines is crucial and very domain specific. It can be exceptionally clean and well-commented and it still takes days to unpack. The skills and effort required to review and understand those situations are quite different. One is like distance driving a boring highway in the Midwest:…
Re: Vibe coding and agentic engineering are getting closer than I'd like
#113> If you can go from producing 200 lines of code a day to 2,000 lines of code a day, what else breaks? The entire software development lifecycle was, it turns out, designed around the idea that it takes a day to produce a few hundred lines of code. And now it doesn’t. It is so embarrassing that LOC is being used as a metric for engineering output.
Do you reject all stats that treat the number of people involved (eg. 2 million pepole protested X) as "embarrassing" ... because they lump incredibly varied people together and pretend they're equal?
Re: Vibe coding and agentic engineering are getting closer than I'd like
#114Earlier quoted context omitted.
That's assuming the 200 lines are logical and consistent. Many of my most frustrating LLM bugs are caused by things that look right and are even supported by lengthy comments explaining their (incorrect) reasoning.
Ok? No one is saying that all LOC are equal. Ceteris paribus, 2000 lines is 10x more time consuming to review than 200
Re: Vibe coding and agentic engineering are getting closer than I'd like
#115Have you noticed that the coding agents get really close to the solution on the first one shot and then require tons of work to get that last 10% or 5%? If we shift the paradigm of how we approach a coding problem, the coding agents can close that gap. Ten years ago every 10 or 15 minutes I would stop coding and start refactoring, testing, and analyzing making sure everything is perfect before proceeding because a bu…
Re: Vibe coding and agentic engineering are getting closer than I'd like
#116People in the future are going to wonder what the hell we were thinking, when 30 years down the line everything is a hot mess of billions of lines of code generated by LLMs that no human has read almost any of it and is no longer possible for anyone to maintain neither with nor without LLMs. And the LLM generated garbage will have drowned out all of the good quality code that ever existed and no one will be able to f…
By then, the fix will be easy. Fire up the latest LLM, point it at your codebase and tell it "rewrite this from scratch. do it well. fix the architecture mistakes"
The system that makes it have an opinion about good vs bad architecture or engineering sensibilities will be something on top of the transformer and probably something more deterministic than a prompt.
Re: Vibe coding and agentic engineering are getting closer than I'd like
#117Perhaps I've missed a few weeks worth of progress, but I don't think that AIs have become more trustworthy, the errors are just more subtle. If the code doesn't compile, that's easy to spot. If the code compiles but doesn't work, that's still somewhat easy to spot. If the code compiles and works, but it does the wrong thing in some edge case, or has a security vulnerability, or introduces tech debt or dubious archite…
The current fever pitch mandates from above seem to want it applied liberally, and pushing back against that is so discouraging and often career-limiting as to wear the fabric of one's psyche threadbare. With all the obvious problems being pointed out to people, there are just as many workarounds; and these workarounds, as is often revealed shortly thereafter, have their own problems, which beget new solutions, ad infinitum.
At some point it genuinely seems like all this work is for the sake of the machine itself. I suppose that is true: The real goal has become obscured at so many firms today, that all that remains is the LLM. Are the people betting the farm and helping implement the visions of those who have done so guaranteed a soft exit to cushion them from the consequences, or is rationality really being discarded altogether?
Sure, sound engineering principles can help work around these problems, but what efficiency is truly gained, in terms of cognitive load, developer time, money, or finite resources? Or were those ever an earnest concern?
Re: Vibe coding and agentic engineering are getting closer than I'd like
#118Claude Code in particular seems really uninterested in this aspect of the problem and I've stopped using entirely because of this.
Re: Vibe coding and agentic engineering are getting closer than I'd like
#119Vibe Coding (and LLMs) did not create undisciplined engineering organizations or engineers. They exposed and accelerated them. Plenty of engineers have loose (or no!) standards and practices over how they write coee. Similarly, plenty of engineering teams have weak and loose standards over how code gets pushed to production. This concept isn't new, it's just a lot easier for individuals and teams who have never reall…
Bad engineers continue being bad, good engineers continue being good. I personally don’t know any colleagues who were good engineers just because they wrote code faster. The best engineers I know were ones who drew on experience and careful consideration and shared critical insights with their team that steered the direction of the system positively. > Claude, engineer a system for me, but do it good. Thanks!
Same, if anything, the opposite seems to be true, the ones that I'd call "good engineers" were slower, less panicked when production was down and could reason their way (slowly) through pretty much anything thrown at them.
Opposite experience, I've sit next to developers who are trying their fastest to restore production and then making more mistakes to make it even worse, or developers who rush through the first implementation idea they had for a feature, missing to consider so many things and so on.
Re: Vibe coding and agentic engineering are getting closer than I'd like
#120Vibe Coding (and LLMs) did not create undisciplined engineering organizations or engineers. They exposed and accelerated them. Plenty of engineers have loose (or no!) standards and practices over how they write coee. Similarly, plenty of engineering teams have weak and loose standards over how code gets pushed to production. This concept isn't new, it's just a lot easier for individuals and teams who have never reall…