nimonian

I see where you are coming from. But 6.1 Sol seems like a new frontier in pricing, not intelligence. I do think the deceleration stuff was mostly bluster, but I don't think this release in particular contradicts it too much.

You have an extra reset that you can trigger any time before Oct 22

I recommend reading the web page. It is quite short.

I am freaking out. This is a huge moment.

I don't want to drag the discourse away from this achievement, but I hate how this is announced with blatant corporate advertising (our internal model, here are the benchmarks, gpt astra TM yours now for the low low price of £200pcm). I just didn't think Navier-Stokes falling would be sponsored by McDonald's.

Still. I am crying right now. Navier-Stokes is solved.

Climate change, most likely.

Agreed. Opus 5 is doing just fine, slightly better than 4.8. It's personality is insufferable, but I find myself catching fewer problems at code review. It generally understands my conventions and isn't so eager to accrue tech debt.

Both. Command the author to use the style, then command a reviewer to check it. Write one skill called review-prose with your rules, and another called write prose which tells the author they will be judged by review-prose, so you only write the rules once.

What I have found is that getting a model to rewrite a badly written passage is hard, because it seems to key off what it reads. It might swap some vocabulary around ok, but it doesn't fix structures very well. So getting it close to the preferred style in the first place is better.

To take this further, if you must fix existing bad prose, write a clean-prose skill which extracts the bare structure of the prose with none of the style, hands it to an author subagent who isn't poisoned with the original bad prose, then hands the output to a reviewer subagent.

Opus 5 writing is horrendous, so I have been experimenting with improving the output!

_Exactly_.

Both the article and the parent comment treat "happens to have Kik account" as an independent discovery that affects our Bayesian inference.

No. The innocent was identified exactly _because_ they have a Kik account, so the conditional probability they have a Kik account is 1.

What you're describing is very close to what education theory calls "assimilation" and "accommodation". When we assimilate knowledge, it just fits into our schema of understanding. When we accommodate knowledge, we need to change our schema, and that is where the feeling of being challenged (and often the feeling of profundity) comes from.

For example, a child learns that "foreigner" means someone from outside their country. Then, when they're 11, they go on their first holiday abroad and realise "Wait! _I_ am a foreigner here!"

So, maybe one way to frame what you're saying, is that LLM output tends towards being easily assimilable.

The article presents hypothesis as fact with insufficient science. I have no problem discussing speculation, but if the author wants to promote their claims to any more than that I would want to see more journalism.

I completely agree with this you. The article is NOT about product ideas. Your parent has misunderstood the article.

This is pretty unfair. If the author didn't establish some context there would be someone else here saying "Check out this dilettante telling me what to think."

I have a degree in mathematics followed by twenty years in software development (pillory me, if you like). My conclusions after 6 months of using LLMs every day are remarkably similar to the author's. I increasingly think in shapes, architectures, data structures and ideas; less and less in lines of code.

And I fully understand his point that, once the architecture of an idea is settled, reading LLM code does not feel worse than reading human generated code. Especially if you have a strong style and conventions guide.

The idea is the hard part, and it's the right place to focus your effort.

Neat! I think agents making Word docs and PowerPoints is going to go away. I think something like small docs is the future.

Online chess is taken seriously as an e-sport, especially at the top levels, and is played for cash prizes. Imagine if the best cs:go or competitive programmers were found to be cheating. They would be ostracized.

Very close to this at my company. We have docs each of which having its description in the yaml. An MCP tool lists the doc sections, a full section with its descriptions, or the entire contents of a doc. A kind of progressive disclosure. Works really well. We even write "skills" this way so they can be used in all our chat environments.

Fable is really good at front end (Opus 4.8 is decent too) but it really needs a verification loop - it can't always infer the output from the code alone. Give it Playwright to check its work, and it'll generally do a good job. Also if you're using a framework, add to your CLAUDE.md to always rtfm before making changes!

I do quite a lot of what this post describes in a reasonably large project. Here's what works for me:

- write gherkin features for new features; update them for enhancements; don't touch them for refactors. Label your PRs with these nouns.

- use pre-push hooks for type checks, linting, unit tests, and other quick, scriptable validations.

- make a viteperess subsite in your repo, have the agents maintain it - document important principles, architecture, etc.

- make a cli command which lists all pages along with the yaml frontmatter description so agents can choose what to read without blowing up the context window.

- use ddd and monorepo - write your logic in headless layers, and compose layers into apps. agents navigate layers very successfully.

- use zod (or your language equivalent) and contract-first API development; this is my favourite bit tbh, I use orpc

- make a single skill called "code" which describes the lifecycle: open a worktree, setup .env to guarantee no conflict with other agents (choose unused ports etc - docker is good here), write or update feature file (this is where you negotiate the spec), implement, validate (e.g. using playwright mcp), pre-push checks, push and wait for review, tear down and fast forward main

- testcontainers is great for ensuring multiple agents can run tests that don't conflict

Seriously I only have one skill that's it. Everything else is in the docs. I'm feeling very productive like this, in a "making good software" sense not a LoC sense.

Ghostty with Claude Code. That's pretty much it.

For each new feature, I open a worktree, spar with Claude to work up a gherkin spec with @todo on each story. Each agent pushes commits to a WIP PR in GitHub where I review and leave comments or questions. Once the spec is done we mainly interact on the PR. @todo becomes @wip and @done as the agent progresses. I really like gherkin for agentic engineering, it's very clarifying.

I have about 2-4 agents running at a time. Large test suite, linters and formatters enforced on push.

This is a tangent but I'd also mention sli.dev -- slideshow-as-website is really great and fun to make with llms

I read a lot of AI prose three days and this bears none of the hallmarks. If this is AI, if really live to see the prompt.

I'm confident this is human.

It's a delightful counterintuition that your gut feeling is mostly wrong: https://webhomes.maths.ed.ac.uk/~v1ranick/papers/wigner.pdf

Far from being motivated by some applications, the most useful discoveries in mathematics are usually discovered "for their own sake" and their application is only discovered later. Sometimes centuries later!

If you think of it as being an accumulator function it can feel a bit more natural - the _definition_ of this accumulator is that, F(x) is the area from 0 to x

The fact that the derivative of this accumulator function is equal to the original function, this is the fundamental theorem of calculus, and I violently agree with you that this part is shockingly, unexpectedly beautiful

I'm with you on this (I think). Digitising my org is much easier if I can assume my colleagues' agents will be acting on their behalf. Even if I can't convince most humans to cooperate with solutions, I can usually trust their agents to do so. MCP hides the wiring somewhat, which I enjoy.

I am building _exactly_ this for my org for the past month, using Nuxt Content.

A "draft" is a row in a database with live preview. Users can click a button to make a checkpoint (git commit, by GitHub API, but they don't know that). When they click "publish", the PR for their draft is merged.

Writers in my team can use a nice Tiptap editor with custom components. I get the change management of git.

The API for reading content and editing drafts is also exposed over MCP meaning AI can collaborate in the authoring process from anywhere that can connect to MCP.

Loving it so far.

Writing to the board is not customary. When you do so, it is customary to do it through the secretary.

I still believe looking up the answer in the back of the book is completely fine. It creates a moment of tension. It invites you to justify in your own head that the answer is right before checking. The cognitive dissonance when you see your answer is wrong and really have to challenge yourself, or ask your neighbour, to see why - is all really valuable.

I just don't think "instant feedback" is as important as we think in mathematics education, and might even rob us of moments to practice mathematical behaviours like justifying, communicating and accommodating. Slow feedback does have benefits.

I am a tech enthusiast to put it mildly. I also taught maths in schools from roughly 2010 to 2020 so saw the iPad/app revolution in my classrooms. Anecdotally, I think it made my lessons and my students worse. Books, paper and each other are the best tools (in my very personal opinion).

Sorry for the late reply. When I was studying my A Level physics me and my teacher read Angels and Demons at the same time. It is a silly story really but just scratched that sci-fi bit of my brain in the right way at the right time. It is pulp fiction but sometimes that's just what you want.

I have a vitepress package in most of my repos. It is a knowledge graph that also just happens to produce heat looking docs for humans when served over http. Agents are very happy to read the raw .md.

The mention Dan Brown in the article! This book occupies a special place in my heart and I was glad to see it mentioned.

I consider this a form of performance art. To really expose the absurdity of the system, you can't just point at the cracks; you need to actually stick your fingers in.