I, for one, look forward to the contracting gigs fixing garbage code. :)
The pull back on this will be brutal.
571–580 of 897 posts
I, for one, look forward to the contracting gigs fixing garbage code. :)
The pull back on this will be brutal.
Earlier quoted context omitted.
> AI has help me refactor things where I normally couldn’t. Reading "couldn't" as, you would technically not be able to do it because of the complexity or intricacy of the problem, how did you guarantee that the change offered by the AI made proper sense and didn't leave out critical patterns that were too complex for you to detect ? Your comment makes it sound like you're now dependent on AI to refactor again if dir…
Before I started using advanced IDEs that could navigate project structures very quickly, it was normal to have a relatively poor visibility -- call it "fog of war/code". In a 500,000 line C++ project (I have seen a few in my career), as a junior dev, I might only understand a few thousand lines from a few files I have studied. And, I had very little idea of the overall architecture. I see LLMs here as a big opportun…
Earlier quoted context omitted.
Also, you know who did measure every angle to make sure it was correct? The engineers who put together the initial design. They sure as hell took their time getting every detail of the design right before it ever made it to the assembly line. Who's filling that role in this brave new world?
This also seems, to me, like composer/npm issues. An entire generation of devs, who grew up using unaudited, unverified, unknown license code. And which at a moments notice, can be sold to a threat actor. And I've seen devs try to add packages to the project without even considering the source. Using forks of forks of forks, without considering the root project. Or examing if it's just a private fork, or what is most…
After a month, I can say that the inmates run that whole ecosystem, from the language spec, to the interpreter, to packaging. And worse, the tools for everyone else have to cater to them.
I can see why someone who has never had a stable foundation to build a project on would view vibe coding as a good idea. When you're working in an ecosystem where any project can break at any time because some dependency pushed a breaking minor version bundled with a security fix for a catastrophic exploit, rolling the LLM gacha to see if it can get it working isn't the worst idea.
> [Harper Reed] cautioned against being overly precious about the value of deeply understanding one’s code, which is no longer necessary to ensure that it works. That just strikes me as an odd thing to say. I’m convinced that this is the dividing line between today’s software engineers and tomorrow’s AI engineers (in whatever form that takes - prompt, vibe, etc.) Reed’s statement feels very much like a justification…
Any manufacturing process is subject to quality controls. Machines are maintained. Machine parts are swapped out long before they lead to out-of-tolerance work. Process outputs are statistically characterised, measured and monitored. Measurement equipment is recalibrated on a schedule. 3d printed parts are routinely X-rayed to check for internal residue. If something can go wrong, it sure as hell is checked.
Maybe things that can't possibly fail are not checked, but the class of software that can't possibly fail is currently very small, no matter who or what generates it.
Earlier quoted context omitted.
In a world of vibe coders, those who can still debug on their own, will have quite a valuable skill.
I already imagine future devs wide-eyed saying things like: "He/She can _debug_!!"
> [Harper Reed] cautioned against being overly precious about the value of deeply understanding one’s code, which is no longer necessary to ensure that it works. That just strikes me as an odd thing to say. I’m convinced that this is the dividing line between today’s software engineers and tomorrow’s AI engineers (in whatever form that takes - prompt, vibe, etc.) Reed’s statement feels very much like a justification…
The correct analogy is that software engineers design and build the _factory_. The software performs the repeatable process as defined by code, and no person sits and watches if each machine instruction is executed correctly. Do you really want your auto tool makers to not ensure the angle of the tools are correct _before_ you go and build 10,000 (misshaped) cars? I’m not saying we don’t embrace tooling and automatio…
This is, I think very important especially for non-technical managers to grasp (lol, good luck with that).
Earlier quoted context omitted.
I already imagine future devs wide-eyed saying things like: "He/She can _debug_!!"
I mean I already heard comments about myself when I went and RTFM'd "You read manuals?!?" "... Yeah? (pause) Wait, you don't ?!?!?"
Earlier quoted context omitted.
Of course it is true. The thing was 90% of Amazon engineers made far more money at their job while essentially doing typical enterprise software work. This money led them believe it is some creative work. And now those task management and time monitoring tools are catching up to Amazon IT workers so they are realizing it is similar to another low end IT job/ factory work.
The pay and benefits at Amazon always seemed to offset the shit work/life balance and on-call rotation. What a gauntlet that was. The only engineers that got recognition were those that fixed high profile bugs, preferably after hours. Shipping a feature was always just "business as usual"
Earlier quoted context omitted.
In a world of vibe coders, those who can still debug on their own, will have quite a valuable skill.
I already imagine future devs wide-eyed saying things like: "He/She can _debug_!!"
Earlier quoted context omitted.
Something I've been thinking about is that most claims of AI productivity apply just as well (and more concretely and reliably) to just... better tooling and abstractions Code already lets us automate work away! I can stamp out ten instances of a component or call a function ten times and cut my manual labor by 90% I'm not saying AI has nothing to add, but the "assembly line" analogies - where we precisely factor out…
Exactly that. Software development isn't about writing code, never was, it's about what code to write. Doesn't matter if I type in the code or tell an AI what code it should type. I'll admit that assuming it's correct, an AI can type faster than me. But time spent typing represents only a fraction of the software development cycle. But, it'll take another year or two on the hype cycle for the gullible managers being…
I spent quite a bit of time as a CTO, and at some point there's a conversation about the business value of refactoring. That's a great conversation to have I think, it should ultimately be about business value, but good code vs bad code is a bit hard to quantify. What I usually reached for is that refactoring brings down lead time of changes, i.e. makes them faster. Tougher story these days I guess :D