101–110 of 179 posts
Earlier quoted context omitted.
>A modern LLM will hallucinate like a nineties raver on ecstasy but if you listen carefully and phrase your prompts carefully and ignore the chomping teeth and keep them hydrated, you may get something remarkable out of the creature 8) Like what - the world's most advanced blowjob?
Perhaps I should have gone for Sherlock Holmes doing morphine as an analogy. Mind you the '90s raver fits for some models or is it the prompter ...
AI allows executives to spend R&D to create a flywheel which builds more, faster, without hiring more. It makes every individual employee able to deliver more. ICs dislike this because it raises expectations and puts the spotlight on delivery velocity. In a manufacturing analogy, it’s the same as adding robots that enables workers to pack twice as many pallets per day. You work the same hours, but you’re more tired,…
It isn't this. This is the executive's misinterpretation.
I’m neither a developer nor an executive, but from my vantage point the software crisis has to do with the fact that software development presents an existential risk to any organization that engages in it. It seems to be utterly resilient to estimation, and projects can run late by months or even years with no good explanation except “it’s management’s fault.” This has been discussed at length. If I had a good answer, “I wouldn’t still be working here” as the saying goes. But half a century after The Mythical Man Month, it still reads like it was written yesterday, and “no silver bullets” seems to ring true.
In my view, the software crisis will be resilient. Throwing more code, or more code per day, at a late project will make it later. There will be a grace period while the pace of coding seems exciting, but then the reality will set in: “We haven’t shipped a product.” And it will be management’s fault.
AI allows executives to spend R&D to create a flywheel which builds more, faster, without hiring more. It makes every individual employee able to deliver more. ICs dislike this because it raises expectations and puts the spotlight on delivery velocity. In a manufacturing analogy, it’s the same as adding robots that enables workers to pack twice as many pallets per day. You work the same hours, but you’re more tired,…
The more appropriate tools for ICs are torches and pitchforks.
AI allows executives to spend R&D to create a flywheel which builds more, faster, without hiring more. It makes every individual employee able to deliver more. ICs dislike this because it raises expectations and puts the spotlight on delivery velocity. In a manufacturing analogy, it’s the same as adding robots that enables workers to pack twice as many pallets per day. You work the same hours, but you’re more tired,…
ICs dislike this because executives haven't been shy that their goal in increasing productivity with LLMs is to reduce headcount. Additionally, we have 50 years of data showing that increased productivity only marginally increases pay, if at all - all the gains are captured by the executives. The more appropriate tools for ICs are torches and pitchforks.
No, they are captured disproportionately by the haut bourgeois capitalists. The two groups overlap to an extent (when major capitalist are nominally employed by a firm they invest in, it is usually as an executive), but executives qua executives (that is, in their role as top level managerial employees) are not the main beneficiaries of increased productivity.
Earlier quoted context omitted.
And one executive talks to other executives not to their engineers. I think this is more peer pressure than anything else.
I lead a team of Data Engineers, DevOps Engineers, and Data Scientists. I write code and have done so literally for my entire life. AI-assisted codegen is incredible; especially over the last 3-4m. I understand that developers feel their code is an art form and are pissed off that their life’s work is now a commodity; but, it’s time to either accept it and move on with what has happened, specialize as an actual artis…
Spec driven dev is good software engineering practice. It’s been cast aside in the name of “agile” (which has nothing to do with not doing docs - but that’s another discussion).
My problem is writing good specs takes time. Reviewing code and coaxing the codegen to use specific methods (async, critical sections, rwlocks, etc) is based on previous dev experience. The general perception with c suite is that neither is important now since “vibing” is what’s in.
As someone who's both an IC and leads other developers I disagree with the explanation. As a technical lead, with people I can much better predict the quality of the outcome than with LLMs, and the "failure modes" are much more manageable. As a programmer, I am actually more impressed with AI agents but in an informed and qualified way. Their debugging ability wows me; their coding ability disappoints and frustrates…
pass a certain LOC number, the utility become negative (unless they were pure tests).
And with LLMs also more context and token usage and cost.
Earlier quoted context omitted.
pass a certain LOC number, the utility become negative (unless they were pure tests).
Even the utility of too many tests is negative. More upkeep and harder to change the code. And with LLMs also more context and token usage and cost.
It's too easy to add bloat and complexity that can never go away, and with the tooling we now have a significant portion of engineers are now active risk to the projects they are working on.
Earlier quoted context omitted.
I hope that’s exaggeration because being unable to operate without it means you’re going to do a terrible job of reviewing the code it’s producing.
Since the November/December Opus and Claude Code, I found I don't need to read the code any more. Architecture overview sure, and testing yes, but not reading the code directly any more. Me (and my friends similarly) inspect code indirectly now - telling agents to write reports about certain aspects of the code and architecture etc.
Another 25% of the time the tests are wrong in some other way. Usually mocking something in a way that doesn't match reality.
And maybe 5% of the time Claude does some testing that requires a database, it will find some other database lying around and try to use that instead of what it's supposed to be doing.
And even if Claude writes a correct test, it will general have it skip the test if a dependency isn't there--no matter how fervently I tell it not to.
If you're not looking the code at all, you're building a house of cards. If you not reading the tests you're not even building you're just covering the floor in a big sloppy pile of runny shit.