I think your underlying point is correct, but "buy" is also "buy+maintain." There's a real cost to keeping up with dependency upgrades, especially for big frameworks that like to change their fundamental public-facing API every few years.
Agreed. The article is very sloppy, but that doesn’t mean the central thesis is wrong. I’m not conversant enough with financial theory to say one way or another. Anybody care to critique this?
Ramp is an expense reporting tool with minimal LLM functionality and reasonably decent ML for reading receipts and categorizing expenses. This is bog-standard content marketing, not some conspiracy to sell you AI.
Thank you, @dabluck, for sharing what failed. I think stories of failure are incredibly valuable, and more useful than stories of success, which are often post-hoc rationalizations.
I’m sorry all the airchair geniuses in this thread feel compelled to express how they’re so much smarter than you and would never fail… or at least, never admit it.
I think it’s incredibly poor form for somebody with the reach and clout of Jon Gruber to be naming and shaming an individual engineer like this. At the very least he could have tried to get the other guy’s side.
I think it’s more that they can’t recognize the downsides of AI. They work with AI and it’s so smart! And magical! They don’t have the expertise to recognize the problems in its output, and they’re confused by complaints. It looks like stubborn resistance to them, so they turn to evangelism to try to get people to “see the light.” They don’t engage with legitimate criticism because they don’t understand it.
(That and the normal herd of grifters who pile on to every fad.)
> Unfortunately I think we're entering (have entered?) a period of insanity.
It’s been true for a long time. One of the hardest things as a senior leader in software is dealing with people demanding “accountability” (by which they mean making long-term plans with impossibly precise forecasts) and focusing on costs, all while ignoring value and refusing to engage in prioritization. (I swear, if I hear “it’s all important” again…)
People are just… shallow. They operate on feelings and vibes. They follow the herd without thinking critically. Then they get angry when their dreams clash with reality, and they blame the messenger when those dreams turn out to be fantasies.
But you’re right. AI is bringing out the worst in these tendencies. I think it’s because it’s so convincing when you don’t dig deeply, or aren’t an expert in the subject being discussed. On the plus side, it raises the floor, but I think we’re in for some difficult times before the lessons are learned. I don’t think it will take long, though: I suspect that naive use of AI is going to massively speed up the technical debt curve, and where it used to take 5-9 years to destroy a codebase, it will now take closer to 1-2.
It starts off great, with a compelling story about responding to a roadside emergency, but then it veers off the interstate and meanders through the countryside. The paragraphs — they compound. The em-dashes — they multiply. Words upon words and I still don’t know what the author is trying to say. Something about a system for responding to corporate pseudo-emergencies. I guess.
I’m a writer. I get what a preface is for. And I get why an executive coach writes a book (and it ain’t the royalties). But please, please: hire a development editor. Preferably one not named Claude.
(PS: emdashes are supposed to be used—as a copyeditor once told me—without spaces on either side. It’s one of the ways you can tell the true lover of the emdash from an LLM.)
As VPEng, I didn’t use metrics to assess individuals. Too prone to metric gaming.
Instead, I had a career ladder with a detailed rubric describing the skills an engineer at each level was expected to have. (Including communication and peer-leadership skills.)
Managers performed qualitative assessment of employees, using the career ladder as a guide. They relied on tech leads and Staff engineers to help them understand people’s skills, and provided 1:1 feedback and coaching.
We did use impact-based metrics to assess the results of important initiatives. We solved the attribution and lagging indicator problems by estimating impact rather than measuring it, and using a series of proxy measurements (activation, usage, retention, etc.) as a feedback mechanism for revising those estimates.
I’m not really a fan of the ideas. They’re not wrong, exactly, but I think they’re overstated. Instead, here’s some alternatives:
For design, Evans’ Domain-Driven Design does a good job of representing classic object-oriented design, and Fowler’s Patterns of Enterprise Application Architecture is good for expanding past business logic to larger systems.
For coding habits, “The Pragmatic Programmer” is a classic for a reason.
I clicked the link hoping for a critique of the ideas in SOLID and Clean Code, but what I got was an ironically long-winded critique of Bob Martin’s speaking style.
Martin and I have our differences, but this article isn’t really useful. Martin has a brand and a style. A lot of people find it engaging and entertaining. If you don’t, that’s fine, there’s plenty of other ways to learn about the ideas that are more concise.
Republican states are mostly lower population than blue states, so they have disproportionate representation in the electoral college. This would give Democrats more power in presidential elections than they currently have, if I understand it correctly.
My experience with AI plans is that they’re a wall of text that’s very hard to extract meaning from. Combined with it not doing a good job to begin with, I don’t think plan+revise is a great use of time.
Carson’s experience matches mine: AI is good at analysis and boilerplate, but not good at the kind of critical thinking necessary for good designs. If it were human, I would say that it jumps to solutions to quickly, rather than stepping back to consider the big picture and how everything should fit together to make a cohesive whole.
It’s not human, of course, and I think this problem actually relates to the fact that LLMs don’t have a world model. They don’t study and think through a design in the way that humans do. They don’t form a mental model of how everything fits together and how that design can be tweaked to most elegantly support a change.
I suspect that this is a fundamental limitation of LLMs, and that design will remain a weak point until some sort of bespoke design AI is bolted onto the side. In the meantime, we’ve got a lot of people producing a lot of code very quickly, and I think the debt in that code is going to be a millstone around our necks for a long time to come.
Yeah, your experience is definitely different than mine. When I’m working with human teams, I don’t spend weeks giving them thousands of lines of precise instructions. We work incrementally, having fairly brief conversations to make sure we’re on the same page about the tasks we’re tackling, and then letting individual pairs work out the details of each task… which they do, because they’re experienced professionals.
For example, the project we were working on was to add support for reading a session cookie to a codebase that, up until now, had used a different kind of auth. Fairly straightforward, everybody knows what a session cookie is and how it works. In about 10 minutes, we decided on the big picture design elements (how it was going to fit into our existing system, what we needed to add/modify, etc.) and the corresponding tasks.
One of the things we wanted was an “UntrustedCookie” class to represent the cookie. It was meant to follow a pattern we had already established for other user-controlled input. Our HttpServerRequest object was going have a new getCookie() method that returned it.
This would have been about 30 min of work for a pair to implement, including tests. It’s pretty trivial. No further documentation is needed.
Anyway, I’m glad AI is working for you. My experience is that it often fails, and does so in ways that experienced humans don’t.
Book: The Art of Agile Development (now in 2nd edition): https://www.jamesshore.com/s/aoad2
Blog: https://www.jamesshore.com/v2/new
Other stuff: https://www.jamesshore.com/v2/best
Contact: jshore at jamesshore.
Mastodon: @[email protected]