> To solve this you can regular refactor, but it’s not a nice experienc.
Really? I always thought that was the best part of programming. And now that I can direct an LLM to identify a specific pattern and rework it in a certain way, or to extract a function for a specific purpose and then use it where possible (with my review, of course), so much the better.
I agree with you about the joy of writing things directly, overall. But being able to get a few hundred lines of new approximately-what-I-wanted-to-type code (which I generally can read and fix much faster than I would have written it from scratch) definitely improves the experience, when my brain is racing ahead of my fingers. Certainly it gets me more motivated to actually start on a new feature. Similarly for all the not-exactly-exact find-and-replace tasks.
(I'm not a slow typist, but I slow myself down when I write the code, by thinking too much about details that won't be important until after the tests run.)
> But it doesn’t know exactly what you want. This is a way to tell it.
What ever happened to communicating through code?
Agents can follow examples and infer patterns, and they can read commit history and diffs. Real-world commit logs for human-only projects are dominated by short commits (well, at least the ones where the humans are skilled, appreciate version control, care about the project, etc.) with thoughtful commit messages.
> My list is like 200 items now. Know what? Agents don’t care that they just got a wall of generic feedback, they happily look into all the bullet points.
Yes, yes, there has been a library of information on HN by now about how to use agents effectively. (And I'm grateful for that, because I can keep current and in the loop without feeling enslaved to the new style of development.)
None of that is a reason not to do what the title of TFA says. If your review process is doing the right thing, you should observe that it results in your agent moving the code in the "human-maintainable" direction. If you, for whatever reason, actually directly make commits yourself any more (read this ironically; I genuinely can't understand why anyone would want to give up on that, no matter how good the generated code gets, because "the LLM could do better" is not the point), then of course you should write it to be human-maintainable.
The reason humans find "human-maintainable" code to be maintainable is because maintainability is one of the precious few worthwhile at-least-vaguely-objective metrics of code quality we have.
Every time I see someone try to make a point about the fact that some code actually is just better than other code, only to be met with more of this sort of advice, I start to wonder whether I was alone in ever actually enjoying programming.
I've never heard of the argument you're describing. People simply don't assert that animals lack consciousness; beyond a certain level at least, their consciousness is obvious. (Sapience, for example, is another matter.)
But this is exactly why we should not anthropomorphize the models: they are very obviously not conscious, because they are not alive, any more than conventional computer programs are. And proposing otherwise leads to absurd moral arguments, while not really serving any other purpose.
If you don't like the fact that some people disagree with you about what the word "intelligence" actually means, fine. But I am not about to entertain a world in which humans face moral retribution for "enslaving" a literal inanimate tool created by humanity.
> Avoid generic brevity instructions: GPT-5.6 is more sensitive than GPT-5.5 to instructions such as “Be concise,” “Keep it short,” or “Use minimal text.”
I don't follow. Isn't "the model actually cares and will do what you say" a reason to use those kinds of instructions more liberally?
Neat. Deno is packaged on PyPI now, so installation isn't a real issue; but it's nice to be able to invoke the runtime directly rather than by shelling out. Maybe yt-dlp could make use of it?
Would the Luddites have been a useful source to understand how the machines of the time actually worked? Should I expect my local Green party representative to explain nuclear fission coherently? Is Ed Zitron the guy to explain how to implement and train a neural network?
Critique of things is irrelevant to understanding how they work.
My expectation is that you'd hear a lot more about "gated communities", "gatekeeping" etc. than any of the uses of gates that give warm fuzzies. (As a suffix, it's also associated with scandals; but that probably isn't relevant here.)
FWIW, I've been finding that ChatGPT doesn't use emoji at all when I engage with it like a pair programmer and bounce off design ideas, ask for implementation code, propose refactorings etc.
But when I ask it to do data analysis or modeling, the emoji are all over the place, yes.
(And judging by what I've seen on GitHub over the last year or so, I would never in a million years consider asking an LLM to write a project README or documentation unsupervised.)
Then why are so many others in the thread reporting being swamped with requests to review coworkers' slop? If it's genuinely "cognition" at trivial cost, surely this review would be completely unnecessary?
> While the post discusses that the suspended developer didn't even do that, calling them "not backed by empirical evidence" is simply false.
Before even getting to that, we have to address the fact that these aren't the terms used by the people pointing out the phenomenon; not to mention figure what what it should mean for a "concept" to be "backed" by evidence. Of course these phenomena exist, and that existence is evidenced; but to expect "evidence" to support grouping those things together, or choosing a term for that group, etc., is a category error.
Really? I always thought that was the best part of programming. And now that I can direct an LLM to identify a specific pattern and rework it in a certain way, or to extract a function for a specific purpose and then use it where possible (with my review, of course), so much the better.
I agree with you about the joy of writing things directly, overall. But being able to get a few hundred lines of new approximately-what-I-wanted-to-type code (which I generally can read and fix much faster than I would have written it from scratch) definitely improves the experience, when my brain is racing ahead of my fingers. Certainly it gets me more motivated to actually start on a new feature. Similarly for all the not-exactly-exact find-and-replace tasks.
(I'm not a slow typist, but I slow myself down when I write the code, by thinking too much about details that won't be important until after the tests run.)