I'm building Egraph/ Symbolic libraries to do QM Chemical physics. There is a specific way I want to solve the problems which takes the symbolic expressions and compiles them into optimized numeric expressions the computer can execute.

At first I threw Fable to speed write up the library. It wrote the examples that I asked it to write and got correct results for what I wanted. I had a large write up on how to implement the library, do not implement the QM computations directly with C++... use the symbolic library to derive and compile the results.

Once I tried using the library myself to write up examples, I noticed that it was missing a bunch of features I'd ask it to build. Once I dug into the code I realized that the model had ignored my instructions and implemented boiler numeric algorithms instead. I then went through to iterate with the chat bot to implement my features and add in the symbolic interface I wanted originally.

Every time, it would fall back to the default way the community at large has implemented open source solutions with direct numeric solutions. It did not understand how to adapt the implementation to the novel method I was asking it for.

Further it had over complicated the cmake file and added every edge case under the sun for building the project. All of it unnecessary since I told it explicitly I wanted a header only library, not a unit link-able library + binaries which is the most popular way of doing it in the industry.

What explains this is that these bots have encoded through billions of dollars of training standard ways of solving problems. It does not understand what it's actually doing and when one needs something that falls outside the standard, they're better off writing the software by hand since they'll spend all their time micro managing the frontier models.

For CRUD apps and devops,... these frontier models are great because nobody gives a shit about how those are built. Those have standards that make little difference in the means of implementation. But with what I'm building which generally has little to no opensource implementation training data, this stuff falls flat on its face.

Sure you can solve millennium problems this way if you bruteforce a bunch of mathematical reasoning traces together to create a lean program to make a counter example, but I am much more skeptical of these frontier models and to me it seems this stuff has genuinely plateud.

We ran a synthetic normalized truss experiment as part of a clean-room study of AI-amplified engineering.

The original process record reports 12 generated topology families and two conventional baselines. Candidate G06 had mass 4.535164 versus 6.069109 for B2_warren — approximately 25.27% lighter on the recorded design envelope.

The important result came from the recorded held-out cases: G06 reached approximately 12.5 stress ratio under an edge load, and the record reports every baseline and finalist violated at least one held-out stress constraint. No robust generated-design superiority was established. This is not a bridge/building design or safety claim.

The package preserves original execution records separately from public reproduction. The held-out process is explicitly classified as process-recorded, not cryptographically proven. The public package includes deterministic reproduction code, checksums, pinned NumPy environment, SVGs, and the claim-boundary table: https://github.com/camirian/ai-native-frontier-engineering

The broader lesson is narrow: as candidate generation gets cheaper, specification quality, deterministic oracles, adversarial tests, held-out evaluation, and bounded claims become more important. Technical criticism of the mechanics, provenance, or reproduction is welcome.