IMO
I’m getting a lot of small stuff done that I wouldn’t have touched previously. It’s a little bit nicer for users but I would say the difference is marginal
This article itself is AI slop, of course this is not surprising coming from a website called "ai-updates.net" which I get the impression that might be entirely vibe coded too.
I feel that maybe in the future HN will have to implement a "low quality AI" flag or something(if it has aleady I'm not aware).
I bloody hate the linkedin speak that is used in this article. I am sort of glad that a lot of AI articles use such language, since I was repulsed by it before AI was a proper thing, I don't have to update my filters :))
Software developers are famous for lamenting the high time preferences of business forcing them to make poor engineering decisions. The dynamic is common.
Therefore one should not expect higher quality out of many businesses using AI, but you should certainly expect such businesses to highly value AI. The arguments in favor of quality didn't seem to work before, I don't think they will now.
Yep. If your bosses don't care about the quality of the product then there's no reason for you to care either. Make the AI vibe code slop and ship it. That is what the people signing your paychecks actually want you to do.
Article is light on details but the premise is something I’ve seen playing out for series A and B companies. Head-counts that were growing as some pretty stable function of revenue growth having a sharp trend change starting about 6-9 months ago.
> The company has used the amount of code shipped as a major indicator of engineering output.
> That metric is controversial.
An important point that’s buried quite a bit down the article. Grindr seems to be measuring AI success not on features shipped or business value created, but on number of lines of code generated which seems a fairly flaky justification for such a large AI spend personally.
Charles Simonyi Has that story about how a PM began publicly calling out engineering productivity by having them report weekly lines of code, and Simony one week put a negative number in for his line count. The PM stopped doing that afterward.
Alternatively, since Simonyi was at PARC, just up the road from Apple, he may have known the story and shared it, which got re-attributed, as happens in the game of telephone.
The story was from the time he was working on Microsoft Office, so after Parc in the early or mid 80s. I was actually just surprised someone who worked at Microsoft back then was still at Microsoft (I heard the story in 2009).
I'm having a tough time making the few pieces I know fit together.
When Simonyi started at Microsoft there were only 40 employees. He was the head of the then-new applications group, which I normally don't think of as being a programming job, nor one where LoC is all that relevant.
(That's not to say he wouldn't have written any code. The book "Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" mentions that Cutler, the head of the NT project, wrote some of the code, but not much. And Simonyi, like Cutler, was an expert software developer.)
Wouldn't any PM for Word and Multiplan/Excel be under Simonyi? As the head, he could surely say "no" to the request, and even tell the PM to stop gathering that information, right?
Lastly, and perhaps most importantly, Simonyi developed the "meta-programming" software production method in his PhD, which he brought to Microsoft. The meta-programmer does all the design work and architectural decisions, which the programmers then code up. If they get stuck, they take the problem back to the meta-programmer.
The meta-programmer doesn't actually write lines of code, or at least those LoC are much less than what the underlying programmers write, making that measurement even less relevant for someone like Simonyi who, of course, would be a meta-programmer.
He may well be right, but 'more work' is rarely the answer. The key is doing 'the right work'.
In my experience of AI so far, it's really easy to just 'do more', but there's also very little value in the things people are doing. They don't make you more revenue or improve the product in a meaningful way, or even make the product better to work on. Price's Law[1] or the Pareto Principle[2], or whatever similar axiom you like, suggest that most people aren't actually contributing all that much.
If you apply AI to 'more work' you just end up with the same distribution of good to bad things - and it's highly likely that will lead to more outages, maintenance, and people burning out from the downsides. You have to make sure that the work is actually useful. That's hard, and something AI is terrible at.
Oh, another situation where a CEO makes an assertion that quantity is a more important metric than quality? I suppose the high level humor in this is considering the nature of the app itself. Not part of the target market but still rather side eye concerned this could end poorly for the users if the CEO isn’t very concerned with, em, protection.
shric | 16 days ago
amelius | 16 days ago
icantevenhold | 16 days ago
roryirvine | 16 days ago
lp4v4n | 16 days ago
I feel that maybe in the future HN will have to implement a "low quality AI" flag or something(if it has aleady I'm not aware).
icantevenhold | 16 days ago
xarwex | 16 days ago
mw888 | 16 days ago
Therefore one should not expect higher quality out of many businesses using AI, but you should certainly expect such businesses to highly value AI. The arguments in favor of quality didn't seem to work before, I don't think they will now.
jormp_ | 16 days ago
fhub | 16 days ago
baloki | 16 days ago
An important point that’s buried quite a bit down the article. Grindr seems to be measuring AI success not on features shipped or business value created, but on number of lines of code generated which seems a fairly flaky justification for such a large AI spend personally.
lousken | 16 days ago
seanmcdirmid | 16 days ago
eesmith | 16 days ago
It's certainly likely that it happened more than once, but I've not heard a similar one for Simonyi.
seanmcdirmid | 16 days ago
eesmith | 16 days ago
seanmcdirmid | 16 days ago
eesmith | 15 days ago
When Simonyi started at Microsoft there were only 40 employees. He was the head of the then-new applications group, which I normally don't think of as being a programming job, nor one where LoC is all that relevant.
(That's not to say he wouldn't have written any code. The book "Showstopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" mentions that Cutler, the head of the NT project, wrote some of the code, but not much. And Simonyi, like Cutler, was an expert software developer.)
Wouldn't any PM for Word and Multiplan/Excel be under Simonyi? As the head, he could surely say "no" to the request, and even tell the PM to stop gathering that information, right?
Lastly, and perhaps most importantly, Simonyi developed the "meta-programming" software production method in his PhD, which he brought to Microsoft. The meta-programmer does all the design work and architectural decisions, which the programmers then code up. If they get stuck, they take the problem back to the meta-programmer.
The meta-programmer doesn't actually write lines of code, or at least those LoC are much less than what the underlying programmers write, making that measurement even less relevant for someone like Simonyi who, of course, would be a meta-programmer.
Krei-se | 16 days ago
kbar13 | 16 days ago
onion2k | 16 days ago
In my experience of AI so far, it's really easy to just 'do more', but there's also very little value in the things people are doing. They don't make you more revenue or improve the product in a meaningful way, or even make the product better to work on. Price's Law[1] or the Pareto Principle[2], or whatever similar axiom you like, suggest that most people aren't actually contributing all that much.
If you apply AI to 'more work' you just end up with the same distribution of good to bad things - and it's highly likely that will lead to more outages, maintenance, and people burning out from the downsides. You have to make sure that the work is actually useful. That's hard, and something AI is terrible at.
[1] https://en.wikipedia.org/wiki/Price%27s_law [2] https://en.wikipedia.org/wiki/Pareto_principle
6stringmerc | 16 days ago
cryo32 | 16 days ago
cosmotic | 16 days ago
surgical_fire | 16 days ago
glimshe | 16 days ago
grebc | 16 days ago
ChiperSoft | 16 days ago
[OP] ashurandi | 15 days ago