131–140 of 234 posts
Well, that's a loaded statement. I'am yet to see a Claude session where Claude would tell me to hold off and make my prompts more disciplined.
So it does not demand more discipline.
It can, otoh, build better from disciplined prompts but people too, build better software from better specs.
Earlier quoted context omitted.
I think they expect you to also use an LLM to review, and I bet they are doing exactly that when asked to review someone else's code.
Theres really no diff between a rubber stamp and an llm review, they both do the same thing.
Earlier quoted context omitted.
Talking to an LLM is often still a lower quality result than asking the lead engineer themselves or the collaborators they left behind. You're making a tradeoff between time taken and result quality. Even the most AI-positive teams prefer human discussion when things get that tough. Given enough time, things will "click" for humans. LLMs don't work that way. Even a team of all-new unfamiliar devs forced to study an o…
Agreed and I think the author agrees with this too. One of the ideas is that the devs should be discussing and documenting their intent outside of the code then letting AI tools generate the code as specified. "Engineering" should occupy the time that was previously occupied by "coding" and the context and writing should exist as intentional written context, not just poorly documented code.
It's from this perspective that a lot of engineers feel strong negative sentiment towards AI.
There are always going to be some critical sections of code that one must consider carefully. These tend to be at the extreme ends of choice. Either there's only one way to do it and it probably sucks, or there are many ways to do it and staying optimal is very slippery for maintainers. Identifying and describing these critical sections is also the most important part of the documentation. This is precisely where LLMs fail to do a good job and where people curse the original devs for not writing docs.
But as well, the overall architecture is just as important. The code for this tends to look like the "boring" boilerplate. This is the skeleton of the codebase and LLMs can be bad at this too, haphazardly jamming together design patterns that clash. We're in luck that, usually, a framework or library will provide this code along with documentation to be copypasted verbatim. The rub is when the developers are having to shoehorn it onto existing code they will have to carefully craft some custom interfaces and document them very well.
So in the end, what's left for the LLM to do? When it does a good job, it's usually cribbing so heavily from existing solutions by humans you could have copied it yourself if you knew where it got it from. The LLM is automating copypasta, not deliberate coding. When it's bad, it's making a mess only suitable for a rough proof of concept, if it even works.
From the perspective of a diligent engineer trying to avoid technical debt and other incidents down the road, burning an extra couple of days to get it done right by hand isn't that big of a deal. LLMs become about as useful as a google search. Assuming one does not work at a coding sweatshop, why not just use the google AI summary 90% of the time? The agentic workflow doesn't look promising for a significant chunk of experienced engineers working on maintenance more often than new projects.
Earlier quoted context omitted.
> The most effective contributors at your job remove more code than they add Perhaps they tackle non-code-editing tasks like architecture, design, mentoring and code review (think staff and principal tasks) > Every line of code removed is a line that was previously added Yes. This os not a failure. Code has a surprisingly short half-life.
It’s not a failure that resources were spent writing code that was not needed?
Earlier quoted context omitted.
Turning inefficient, unreadable code into efficient, readable code often results in an overall reduction in LoC. High-quality code and high-volume code are highly anti-correlated. Incidentally, low-quality code that is excessively long just so happens to be common complaint with AI-generated code.
Rewriting code to be more compact is orthogonal to productivity.
How is that not efficient?
Earlier quoted context omitted.
> The most effective contributors at your job remove more code than they add Perhaps they tackle non-code-editing tasks like architecture, design, mentoring and code review (think staff and principal tasks) > Every line of code removed is a line that was previously added Yes. This os not a failure. Code has a surprisingly short half-life.
It’s not a failure that resources were spent writing code that was not needed?
I liked the article overall but found it a little wishy-washy in some of the conclusions. > People do not want to wake up every day and log in to Slack and find the buttons and menus all subtly moved around. People do not want financial transactions that complete most of the time. Determinism is not going anywhere, my friends. Well, I can't reconcile people not wanting things moving around and determinism with the pr…
Earlier quoted context omitted.
Talking to an LLM is often still a lower quality result than asking the lead engineer themselves or the collaborators they left behind. You're making a tradeoff between time taken and result quality. Even the most AI-positive teams prefer human discussion when things get that tough. Given enough time, things will "click" for humans. LLMs don't work that way. Even a team of all-new unfamiliar devs forced to study an o…
Agreed and I think the author agrees with this too. One of the ideas is that the devs should be discussing and documenting their intent outside of the code then letting AI tools generate the code as specified. "Engineering" should occupy the time that was previously occupied by "coding" and the context and writing should exist as intentional written context, not just poorly documented code.
At least in my experience, that ideal has never existed. "Engineering" (and "re-engineering" and "re-re-engineering" in the agile worlds) was always what I was spending the majority of my time on. Coding was a medium for the engineering. By the time I finished the engineering the code was either already finished, being discovered in the written code and then documented, or the code was "the fun part" reward for all the hard engineering work that lead to it (and all the ugly specs documents it took to get there).
Earlier quoted context omitted.
I'm sure this is gated by where you work (especially by how technically savvy your manager is), but the most effective contributors at my job tend to be the ones with near-zero (or sub-zero!) net LoC. LLMs are prolific and they love to add shit. Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts.
The most effective contributors at your job remove more code than they add? That doesn't sound effective that sounds like digging ditches to fill them. Every line of code removed is a line that was previously added.
I don't think that's true. We treated code as permanent because we considered code to be the source of truth. Computers don't run documents, computers run code. If the requirements document contradicted the code, then the default was to assume that the requirements document was wrong.
You can't separate code from spec because the code is the spec.