I wrote Monte-Carlo simulations to calculate the thermodynamics of oxygen ordering in a high temperature superconductor way back in 1993.
Calculating thermodynamic fluctuations on a 256x256 lattice took all night. And that, even though it ran on an HP 9000/750 with a 66 MHz PA-7000 (PA-RISC 1.1) 32-bit CPU.
While waiting, I used to look at weather satellite images downloaded from CERN using NCSA Mosaic. It was impressive. All the information available at your fingertips by using arrow keys and pressing return on underlined text to navigate to the next page! Emmm, link.
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.
The idea is to reduce the number of moving parts and simplify processing architecture when building apps that need to be transactionally rigorous and scalable.
It stems from the patterns we used to successfully apply in banks, which worked really well. I believe it's an effective way to get shit done in a broad class of systems. You just need to first get your head around it.
I wrote Monte-Carlo simulations to calculate the thermodynamics of oxygen ordering in a high temperature superconductor way back in 1993.
Calculating thermodynamic fluctuations on a 256x256 lattice took all night. And that, even though it ran on an HP 9000/750 with a 66 MHz PA-7000 (PA-RISC 1.1) 32-bit CPU.
While waiting, I used to look at weather satellite images downloaded from CERN using NCSA Mosaic. It was impressive. All the information available at your fingertips by using arrow keys and pressing return on underlined text to navigate to the next page! Emmm, link.