I've been cleaning up AI generated system/software design and architecture docs for an agentically engineered application, to translate that dense AI-speak into a clear human-readable form, cross checking it all against the actual codebase.
When I read the translated version, I felt a flush of relief, because I finally could confirm that it built the right thing and properly implemented the requirements.
I then asked in a fresh session which version was better for it as a reference for future work. It unequivocally voted for the human readable form, and gave it's reasoning with specific examples why.
So, I have a hunch that this "packing of lots of signals into fewer words" isn't really better. The incomprehensible prose just makes us think it knows what it's doing, like some mysterious magic that is only smoke and mirrors.
This just might save me. Claude has been driving me nuts with incomprehensible summaries after a long task, where it's actually really important to understand what was done (and what wasn't).
But I'd like that skill to only be used at the final step, when it finishes something.
agreed with "the final step". I worry adding commands like these might affect quality of responses at each step, which then stack up to result in an overall worse outcome.
You can create a research twin that can predict but as you say, it only works once you have a lot of data. Both the data relevant to the experiment it came from (which is rarely published) and the complete failure data (which is almost never published in any form).
Predictions are only one part of research. It's what theorists feed experimentalists with. Confirmation of predictions is by and large a very physical endeavour. Labs are not going away.
I do feel that it's exciting to see what AI will be able to do to help research and discover new things.
My gripe is with their messaging. Because a lot of people will misinterpret that, including politicians, possibly to the detriment of good science.
>a “good” workday, engineers spent 18 percent of their time “coding” (not including bug fixing, testing, etc.)
I must be a crap developer, because I probably spend twice as much time bugfixing and testing than "coding". (Both of which actually involve coding stuff, so I really don't like that distinction they make)
This is stuff AI can be really good at, so brushing that part under the table distorts the picture.
Having said that, I do agree with most of the myths they present.
LLMs are also quite good in writing unit tests and understanding bugs a lot faster than I do, now.
Just a few month back i looked at some yaml stuff for like 20 minutes, played around with it, looked at formatting etc. then i asked the LLM, it immediadly told me what was wrong. I was just blind to that particular wrong char.
Has anyone noticed a change in "attitude" when coding with Opus 5 vs 4.8?
claude has this maddening principle of wanting to minimize the "blast radius", do the least amount of coding changes to get something done, happy to pile up technical debt by "deferring" problems encountered as side notes somewhere. No amount of CLAUDE.md tweaking, and setting .claude/rules seems to get rid of this attitude.
To me it appears like something deeply ingrained in the model itself. Kind of makes sense, since the bulk of the training data is pre-AI, so that it retains an approach of the past, where these facets were driven by completely different cost and time factors.
The past months, I've been hoping that the next model that comes out properly reflects the new reality of agentic development, so that it takes on a more natural stance compatible with how things work today, and we don't have to constantly fight against its fear of change, its drive to minimize coding efforts, refusing to recognize a design flaw and trigger discussions rather than baking in workarounds.
It might be because it was going out of its way before and had too much of a blast radius, and now they could have changed the RLHF (or other tricks in their sleeve) to get what you're seeing now. The reason it swings is that they can't give it "common sense" the way we have.
I think the article is really good, until it starts to offer guidance and making suggestions for the future.
I can't pin it down precisely, but my feeling is that it doesn't fully recognize the fundamental shift taking place. In a sense it's not radical enough, trying more to keep a system afloat whose foundation is being dismantled.
The forces that gave rise to open source will find a new way, because they are based on the nature of the human spirit. We just don't know what it will look like yet.
The reason you need AV on windows is because you are a granny who gets an "FBI" warning on a dodgy webpage and clicks the "pwn my shiz" button.
If you don't install trojans, you don't need AV. If you do install trojans, switching OS won't help.
I'm not sure which is the trojan in TFA - the mooted malicious git binary, or the agent. I can't imagine any sane person letting an agent near anything they care about. All your keys are belong to us.
I guess you fell into a coma before Heartbleed, so here's what you missed: desktop OS security became irrelevant when otherwise-sane people started installing npm and buying smart TVs. And, latterly, giving shells to actors that have no ethics and no consequences.
When I read the translated version, I felt a flush of relief, because I finally could confirm that it built the right thing and properly implemented the requirements.
I then asked in a fresh session which version was better for it as a reference for future work. It unequivocally voted for the human readable form, and gave it's reasoning with specific examples why.
So, I have a hunch that this "packing of lots of signals into fewer words" isn't really better. The incomprehensible prose just makes us think it knows what it's doing, like some mysterious magic that is only smoke and mirrors.