171–180 of 192 posts
Overstating things of course. But paying off technical debt never felt so good. And the expected decrease in forward friction has never been so achievable so quickly.
This is the "lines of code per week" metric from the 90s, repackaged. "I'm doing more PRs" is not evidence that AI is working, it's evidence that you are merging more. Whether thats good depends entirely on what you are merging. I use AI every day too. But treating throughput of code going to production as a success metric, without any mention of quality, bugs, or maintenance burden is exactly the kind of thinking de…
This one's interesting to me. For a lot of my career, the act of writing the PR is the last sanity check that surfaces any weirdness or my own misgivings about my choices. Sometimes there would be code that felt natural when I was writing it and getting the feature working, and maybe that code survived my own personal round of code review... but having to write about it in plain english for the benefit of someone doing review with less context was a useful spot to do some self-reflection.
Earlier quoted context omitted.
On the one side I reject that product and engineering concerns are separated: Sometimes you want to avoid a feature due to the way it will limit you in the future, even if the AI can churn it in 2 minutes today. On the other side perhaps your company, like most, does not know how to measure overengineering, cognitive complexity, lack of understanding, balancing speed/quality, morale, etc. but they surely suffer the e…
> On the one side I reject that product and engineering concerns are separated: Sometimes you want to avoid a feature due to the way it will limit you in the future, even if the AI can churn it in 2 minutes today. That is exactly not what I meant, I'm sorry if it wasn't clear but your assumption about how my job works is absolutely wrong. I even mention that the product discussion is separate only on "how to wrangle…
Reading your comment, it looks like you work for a pretty nice company that takes those things seriously. I envy you!
My concern was that for companies unlike yours that don't have well established engineering practices, it _feels_ that with AI you can go much faster and in fact it's a great excuse to dismantle any remaining practices. But, in reality they either doing busywork or building the wrong thing. My guess is that those are going to learn that this is a bad idea in the future, when they already have a mess to deal with.
To put what I mean into perspective... if you browse OP's profile you can find absolutely gigantic PRs like https://github.com/leynos/weaver/pull/76. I can not review any PR like that in good faith, period.
Is Anthropic raising funds again? I'm so sick of these thinly veiled advertisements.
Now it's just becoming blatant
Is Anthropic raising funds again? I'm so sick of these thinly veiled advertisements.
This. I couldn't have been the only one noticing this uncanny frequency in fluff specifically praising Claude instead of AI coding in general. Now it's just becoming blatant
Earlier quoted context omitted.
No one has any idea how to estimate software value, so the idea that some courts in the US have used a wildly inaccurate system that considers LOC is so far away from evidence that LOC is useful for anything that I can’t believe you bothered including that. LOC is essentially only useful to give a ballpark estimate it complexity and even then only if you compare orders of magnitude and only between similar program la…
They gave a widely accepted way to estimate value, and your counter argument is that that is inaccurate. Fine but how can you be confident about that? I see only one way which is for you to come up with a better way and then show that by your better estimation, COCOMO is bad. Until you do that, all your argument goes down to is vibes. Your example about OpenClaw works exactly against your own argument by the way: Ope…
“A very high MMRE (1.00) indicates that, on average, the COCOMO model misses about 100% of the actual project effort. This means that the estimate generated by the model can be double or even greater than the actual effort. This shows that the COCOMO model is not able to provide estimates that are close to the actual value.”
No one in the industry has taken COCOMO seriously for nearly 2 decades.
>OpenClaw
1. OpenAI bought the vibes and the creator. Why would they buy the code? It’s open source.
2. You don’t seriously think OpenClaw needs half a million lines of code to provide the functionality it does do you?
Seriously just go look at the code. No one is defending that as being an efficient use of code.
https://journal.fkpt.org/index.php/BIT/article/download/2027...
Earlier quoted context omitted.
They gave a widely accepted way to estimate value, and your counter argument is that that is inaccurate. Fine but how can you be confident about that? I see only one way which is for you to come up with a better way and then show that by your better estimation, COCOMO is bad. Until you do that, all your argument goes down to is vibes. Your example about OpenClaw works exactly against your own argument by the way: Ope…
COCOMO has been shown to be inaccurate numerous times. Google it. Here’s one result. “A very high MMRE (1.00) indicates that, on average, the COCOMO model misses about 100% of the actual project effort. This means that the estimate generated by the model can be double or even greater than the actual effort. This shows that the COCOMO model is not able to provide estimates that are close to the actual value.” No one i…
The funny thing is that we've just discussed how people do take it seriously. It's just that you don't like that. And what do you offer as an alternative?
Like I said, vibes. You think that the value of some software is something you can only "feel". That's not how an engineer thinks. If you're engineer you should know that if you can't measure it, you can't say anything at all about it. Which means you cannot discount any alternative method until you've got a better way. But clearly you can't think like an engineer.
Earlier quoted context omitted.
COCOMO has been shown to be inaccurate numerous times. Google it. Here’s one result. “A very high MMRE (1.00) indicates that, on average, the COCOMO model misses about 100% of the actual project effort. This means that the estimate generated by the model can be double or even greater than the actual effort. This shows that the COCOMO model is not able to provide estimates that are close to the actual value.” No one i…
> No one in the industry has taken COCOMO seriously for nearly 2 decades. The funny thing is that we've just discussed how people do take it seriously. It's just that you don't like that. And what do you offer as an alternative? Like I said, vibes. You think that the value of some software is something you can only "feel". That's not how an engineer thinks. If you're engineer you should know that if you can't measure…
As an engineer, you are not required to come up with a better way of predicting the future before you can dismiss tarot. You need only show that it doesn't work.