61–70 of 217 posts
My take, as a non-coder (well, not software engineering, I write 'code' but it's infra, and utilities in go/bash/pythong)... I work at a company where the biggest problems are not 'writing code', they are: - Organising teams - Designing the system - Prioritisation of work The fuckups that we make on a daily bases are not 'code errors' they are failures in THOSE three things. I'll go into detail if anyone cares.
Earlier quoted context omitted.
Ask it to do so, would love to know your results.
I did, the problem is that you need a sort of standardized feature change to compare similar repos. So the metric is relative only to same projects lacking that same feature. So no, its a useless thing. No architecture score comparisson between apples and oranges.
What is the right, best software organization in the current era of AI coding? This question is critical and wholly unanswered in comprehensive research along the same axis as Accelerate (2018, Forsgren, Humble, Kim). There are a lot of (excruciatingly) long-form posts about what folks are pioneering but not a whole lot of follow up about what failed. Where are the short posts on the negative space? How did halving y…
Hard to say what caused what, but the internet seems to mistake verbosity for authority, and so does AI.
Similar to a functioning side project in the 5-10k LOC range. Announcing something that worked a year ago, was laudable, even if not profitable.
I vibe coded 15k LOC this morning and read 20k words of AI generated text while doing so. No longer are either noteworthy or valuable public contributions just by virtue of having been done. I don't think that's widely recognized yet.
I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
many of us work with swarms of cheap off-shore contractors and have to rewrite or finish their code already as it is. The llm is much lower friction
I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
I think perhaps the assumption that engineering managers should have any employees may be outdated.
I can imagine average and mediocre engineers equipped with tokens could create chaos and debt on a scale never before imaginable, so it’s easy to see how orgs who still have these employees around are struggling with the transition.
The reality is you need to get rid of them all, and replace them with the most experienced highest paid person you can find. In the near future that person will become obsolete too.
Software development has always evolved. Sometimes slowly, sometimes quicker. LLMs have brought a different unlock, and for everything we're seeing become easier, it allows people learn to use the tools to take on solving problems that couldn't be approached before.
I think most of this is correct, in spite of potentially being built on a bad assumption. The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that. Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally r…
But to be fair human code reviews have the same problem. It's like reviewers feel they have not done their job if they don't find something wrong.
My take, as a non-coder (well, not software engineering, I write 'code' but it's infra, and utilities in go/bash/pythong)... I work at a company where the biggest problems are not 'writing code', they are: - Organising teams - Designing the system - Prioritisation of work The fuckups that we make on a daily bases are not 'code errors' they are failures in THOSE three things. I'll go into detail if anyone cares.
Earlier quoted context omitted.
I disagree. Coordinating 100 folks to align on a problems statement with "agile" and sprints was always the biggest bottleneck. Difference in opinion, internal politics is always a bottleneck. I think now, code is the bottleneck. Just because you can generate million lines of code, people with different skill level think they are accomplishing the task, testing, merge conflicts, trust has become the bottleneck.
A pattern I have seen: The “old way” would be lots of debate (both bike shedding and useful) among engineers during design phase, and then you’d implement. Now it’s shifted so there are no design docs and there is only the generated prototype. People trying to do their design review while there’s already a functional-ish prototype and it goes nowhere. There’s an anchoring effect in place because the first thing alrea…