My verdict after last night trying what was suggested here:
yes, with CLAUDE_CODE_EFFORT_LEVEL=max (or at least high, for this you don't need to set an env var, it will remember) and CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 you can get Claude to perform as before.
I have been using Claude on /effort high since Opus 4.6 rolled out as medium would never get me good enough results (Rust, computer-graphics-related code).
I, too, noticed the drop in quality a month or so ago. With CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 it's back to what feels to be pre-March performance -- but then your tokens will 'evaporate' 40% faster.
And that was not the case then; I had similar/same performance before but wasn't running out of tokens ever on a Max subscription.
So a it's a rug-pull, as before/last late summer, from whatever angle you look at it.
Just now I had a bug where a 90 degree image rotation in a crate I wrote was implemented wrong.
I told Claude to find & fix and it found the broken function but then went on to fix all of its call sites (inserting two atomic operations there, i.e. the opposite of DRY). Instead of fixing the root cause, the wrong function.
And yes, that would not have happened a few months ago.
This was on Opus 4.6 with effort high on a pretty fresh context. Go figure.
These are just syntax differences, which not only are easy to learn but I believe aren't the primary goal of the language, which is to bring the benefits of Rust's type system to Go.
As for int and float64, this comes from Go's number type names. There's int, int64, and float64, but no float. It's similar to how Rust has isize but no fsize.
I switch between languages a lot and I'm currently learning PHP. I've found that syntax similarities can be a hazard. I see "function" and I think I'm writing JavaScript, but then I try to concatenate strings with "+" and I realize I'm actually writing PHP and need to use ".". These challenges are especially noticeable in the early days of learning.
I think "Because (the dev) prefers it that way" is a satisfactory answer. Often, these small languages don't aim to be used in production and become the next big thing. They're made for fun and exploration's sake.
Writing actual Rust for any GC language (including Golang) would ultimately be quite weird. You'd have to entirely change the way memory is modeled, to account for the restrictions GC introduces. It's similar to the restrictions introduced by having multiple address spaces, except even weirder because every object is its own tiny address space and a reference is just an address space descriptor.
> Turns out those functions were basically a verbatim copy of Inigo Quilez's work.
Are they? A lot of these were used by people >20 years before Inigo wrote his blog posts. I wrote RenderMan shaders for VFX in the 90's professionally; you think about the problem, you "discover" (?) the math.
So they were known because they were known (a lot of them are also trivial).
Inio's main credit is for cataloging them, especially the 3D ones, and making this knowledge available in one place, excellently presented.
And of course, Shadertoy and the community and giving this knowledge a stage to play out in that way. I would say no one deserves more credit for getting people hooked on shader writing and proceduralism in rendering than this man.
But I would not feel bad about the math being regurgiated by an LLM.
There were very few people writing shaders (mostly for VFX, in RenderMan SL) in the 90's and after.
So apart from the "Texturing and Modeling -- A Procedural Approach" book, the "The RenderMan Companion" and "Advanced RenderMan", there was no literature. The GPU Gems series closed some gaps in later years.
The RenderMan Repository website was what had shader source and all pattern stuff was implict (what we call 2D SDFs today) beause of the REYES architecture of the renderers.
But knowledge about using SDFs in shaders mostly lived in people's heads. Whoever would write about it online would thus get quoted by an LLM.
I opened the article and read the first paragraph. Then skimmed the rest.
As others pointed out: the fact you can do this in CSS tells you everything you need to know if you consider what CSS is for. Even w/o ever looking at the spec or understanding how it came to be.
i don't see what you mean? it's a rendering technology
i guess if you're someone still stuck on the "web browsers are for displaying static documents" and "css is for prettifying markup" thing, then sure, I bet what you said sounds real witty
Crazy that the future of software development now looks like we'll all be making UIs with specs that just a few years ago didn't allow you to trivially center a widget in a container.
SolveSpace is a PITA in that regard. You also need to re-learn most terms that are common in other CAD software. It's a typical OSS thing.
Why care about professional users that have years of learning invested into an ecosystem of professional CAD software (including terminology)? Because these people will get you the most valuable feedback if you can get them to even play with your OSS CAD thingy.
AI has now balanced the scores here. Someone with decent CAD experience can now instruct a model to build something useful.
Based on lots of good libs out there that solve the basics. I.e. concentrate on UI/UX to build something better.
It's like Lego, hands-free. You have all the blocks and you have someone who knows how/helps you combine them.
If you have good taste, you can get nice results without understanding how the Legos where made or how to even combine them.
I agree that it is very different from other CAD software, but that is also something I like. When I started using SolveSpace for some easy models, I was a bit lost. But then it clicked, and I really enjoyed the different approach. It is not my main CAD software (build123d is), but I really appreciate the workflow.
I don't think that every oss should try the copy what already exists. The best is when new approaches are tried. The same happened to me when I started using tilling window managers. "Professional" Operating systems don't have that, but I am sure that if more people would try them, many would realize that the workflow fits them better. So, my point is that there is no single best solution in terms of user interface or interaction with a program, and the fact that many people explore and share different approaches with their open source software is something I really appreciate.
You could ask Gemini (Deep Research) to create a jargon file with mappings.
That's the equivalent of LMGTF, in 2026. ;)
I mean all this is documented publicly online (docs/help for CAD software), market leaders are known and the LLMs have ingested this data during training.
woah, thanks! seeing the scenes in the blog-post i realize i've ran into it before, but must not have observed the lineage, committed the project to memory, or realized it was so mature
there's even a parametric split-keyboard project (what i'm doing too)! the clearances and cutouts in julianschuler/concavum-customizer/.../keyboard/mod.rs[1] are so much like my static, single-file, build123d-based version in antlers/keyboard/.../main.rs[2] >u< (though i made the walls out of more layers, photo in README[3]). thx again for pointing me that way!
I love how all these 'brand' fonts look indistinguishable to an untrained eye and still brain-frying-bordedom-inducingly close to each other to someone like me who actually studied & worked in typography.
It's just the design team running in place. And at a certain scale, it's cheaper to pay a type foundry $100k once, rather than paying Monotype continuous fees for a legacy family.
But as someone who has made multiple neutral sans families, I agree. The launch rhetoric about creating a differentiated visual identity is comical when you look at all the interchangeable corporate sans together.
Pretty sure it's just the pendulum swinging. Today its all about serious and clean and minimal. Then it will be whimsical and maximalist again. Skinny jeans, baggy jeans. Skeumorphic, flat.
The purpose of the brand font is to avoid paying licensing fees. Because the typefaces aren’t protected by copyright it’s usually enough to just have someone go and essentially clone an existing font. The whole thing is an artifact of peculiarities of IP law
> The purpose of the brand font is to avoid paying licensing fees.
There are more than enough good fonts under OFL that it surprises me people want to commission a custom font primarily for licensing reasons rather than using a standard one.
I think modern fonts include hinting software and stuff like that.
If you produced a bunch of screenshots of the output at various sizes, and then asked an LLM to convert to ttf or whatever, I’m guessing that’d be OK. I’m not an expert in this stuff though.
Brand fonts are typically a specific license by the original creator of the font, often together with some adjustments (e.g. big companies often need additions for global markets that were not in the smaller original font)
Corporate branding is nothing but an exercise in playing psychological tricks on people. None of it is actually distinct or important. But the silver tongued guys say it is, so people believe it even though it isn't true.
yes, with CLAUDE_CODE_EFFORT_LEVEL=max (or at least high, for this you don't need to set an env var, it will remember) and CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 you can get Claude to perform as before.
I have been using Claude on /effort high since Opus 4.6 rolled out as medium would never get me good enough results (Rust, computer-graphics-related code).
I, too, noticed the drop in quality a month or so ago. With CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1 it's back to what feels to be pre-March performance -- but then your tokens will 'evaporate' 40% faster.
And that was not the case then; I had similar/same performance before but wasn't running out of tokens ever on a Max subscription.
So a it's a rug-pull, as before/last late summer, from whatever angle you look at it.
reply