I don't know, man. Saying this is "just malware" is really stretching the definition of malware. At a minimum this is some pretty interesting and/or terrifying emergent behavior
This is a reference to Inter-Universal Teichmüller Theory. Its Wikipedia article gives a good overview (https://en.wikipedia.org/wiki/Inter-universal_Teichm%C3%BCll...). In maths lasting disagreements over a published "proof" are rare, but IUTT is an example of it. What the article misses: There is a more recent, ongoing effort to formalize the published proof in Lean under the name of "LANA" (e.g. see https://zen.ac.jp/news/zmcpostevent0717e and https://github.com/katobungen/LANA_report_202607/blob/pdf/LA... for a recent update). I guess most mathematicians agree that a successful compile of the proof in Lean would confirm its validity. My personal impression is that the process got stuck at the very point Peter Scholze and Jakob Stix pointed out 8 years ago. Officially LANA has still not reached a conclusion.
TDLR for the other two comments: a Japanese mathematician is claiming to have a proof for it, but it is based on an entirely new very complex field of maths which he invented. Getting into it takes years, so other mathematicians are hesitant to invest that much time only to find out that the proof is broken and the field isn't otherwise useful.
It doesn't help that the author is rather withdrawn and not willing to spend any effort in making it more approachable.
Some tried, and said they found gaps in the proof, to which the author responded, but they were not convinced.
Wikipedia is maybe the narrow end of a wedge into this topic but the controversy revolves around a very large and very complex paper that few people are equipped to understand and some of those who are able believe the proof is false.
I use go for work and basically 100% agent-driven. I'd say using go with agents is a lot better than without. We use to have a consistent source of production errors where we forgot the pointer case in type switches (we'd pass a pointer to a struct where a concrete struct was expected and vice versa). AI hasn't made that mistake once in my experience.
That being said, the whole thing about go being "readable" is a little bit of a two-edged sword. Sure, it's straight-forward to read, but it's pretty verbose. And agents are good at producing a lot of text. The problem with reviewing go code for me is to see the forest for the trees. Subtle misunderstandings often hide in the vast amount of code that you have to read through while keeping the whole context in your head.
Jarred is the Bun creator who just got acquihired and converted Bun to Rust. Pretty sure his job now is to burn tokens to make news headlines. Like a developer advocate for LLM usage in general.
The price wasn't that ridiculous IMO for the quality of the discovery, it generated 31M output tokens which is ~$1500 in API cost if it was on Fable. A new lower bound on the biggest unsolved problem in mathematics for less than a couple day's pay of a prestigious mathematics professor is kind of insane. Obviously this discovery doesn't change anything as it's just moving a lower bound, but that's something many mathematicians have tried and failed to do.
> The name is borrowed from the Wallfacers of Liu Cixin's The Dark Forest — people entrusted with plans too sprawling for anyone else to follow.
Which misunderstands the book. The point of Wallfacers is that they cannot share their plan with anyone because the enemy is spying on them at all times.
The most interesting thing about science fiction to me isn't the things the authors get right, but what they get wrong. Like, the whole house talking in a ChatGPT voice, intelligent appliances, etc: brilliant prescience. But he still thought we'd be having linoleum on our floors...
> But he still thought we'd be having linoleum on our floors...
Yes, but no. He's writing a story about a character (the automated house) that needs lots (relative to the story length) of explaining. "Linoleum" very quickly conveys "kitchen floor", helps anchor the story in details familiar to his readers - and most of those readers would know linoleum is quite flammable, so it also advances the plot.
Futurism is a heavy theme in most SF writing, but you shouldn't let futurism get in the way of good story writing.
I've actually considered premium linoleum for the give underfoot. LVP is such a terrible flooring. Sure it's cheap to buy and install, but man you feel that cheapness.
Lots of places still use PVC covering commonly called linoleum. And laminate that I see everywhere is not so technologically remote, with its plastic surface.
It would be dull to write about all the great new building materials our houses are made and the utter lack of futuristic convenience we actually have.
What was it reviewing? Was it just a "take a look at this pile of code over here"? Because I think asking any model to review 30M lines of code is a stretch...
in general with automated code reviews I've found it fruitful to tell the model what specifically to look for and where. I usually don't get over 10% of the claude opus context window for code reviews, but it of course depends on how your code is structured, how much the agent has to explore etc.
What I have noticed in my own work that a lot of the time that used to be for coding is now just waiting. I have three agents working on three different features in parallel, and I'll go back and forth with all of them, correcting things and steering etc, but then I find myself with three busy agents and nothing to myself except stare at the screen while they code away. There is a mental budget for me where I can't have more than those three running at the same time and still keep track so what I end up doing is just scrolling HN...
I stopped using coding agents after more than one and a half year of active use, it really started to become way too boring, and I’m t a point where I just hate having to babysit them and for the 200th time make it understand what the actual goal is… and to be honest, going back to writing code by hand without assistance is really hard at first you continuously have that little voice telling you how simple that would be with an agent. Then after a little bit you’re back to being productive, but I still get that voice in my mind. I’m wondering if that’s how addiction feels (way lighter of course).
That whole experience of going deep for a while into LLM coding, then trying to leave it behind made me pretty pessimistic about the future of our profession. We are creating a whole industry of people delegating their ability to work to a software stack currently controlled by basically 2 companies (that both have very sketchy financials). Doesn’t feel healthy
Models are very much predictable these days (except anthropic models). The real issue stems from letting them work on their own for far too long. Also we are not controlled by 2 companies anymore as kimi k3, deepseek flash (and soon pro) as the ultra-cheap variants, glm 5.2 especially is a direct replacement for opus 4.8.
Models will only get better and cheaper I wouldn't feel too pessimistic and wouldn't feel too bad on relying on them to accelerate work and free up mental space from menial tasks.
As a personal side-note I never let my agents do architectual design I only use them for implementing. I always found the actual coding part of programming extremely boring and coming up with designs, experimenting and testing the fun part.
I always found that if you are good enough at whittling down boilerplate that coding becomes something akin to pure architecture.
I find that mediocre programmers and LLMs are bad at both. They're helpful if you want to shit out some repetitive boilerplate or perform a complex search of some kind but otherwise you're better off without.
bug fixes not so much. when I encounter a bug the first thing I do is ask an LLM and not only do they usually fail to get the correct solution, they often slap virtual duct tape on it which makes other bugs more likely.
feels like a harness issue, bug fixes work out fine with omp.sh as long as it can be tested properly. Untestable things tend to lead to hallucinated results though.
Even if I was paid for using LLMs I would still find the experience nightmarish. I really don’t want to be dependent on such a system and spend my time managing fleets
Compare the performance of a 980 and a 5050 and I am sure that will answer your question.
Also models baked into the silicon are able to achieve efficiency that is simply impossible to achieve with programmable circuits, there is a general slowdown in the raw capabilities that transformers can achieve and agentic tool use is simply an amplifier that will reach a wall eventually. It wouldn't surprise me if we saw within 5 to 10 years accelerator cards that you're able to purchase and plug into via usb-c that are able to achieve thousands of tok/s as well as api costs going down to what we already see with subscriptions today.
There has been quite a lot of off-ramping going on where people feel satisfied with the performance they're getting out of the models and simply staying there instead of using SOTA.
> accelerator cards that you're able to purchase and plug into via usb-c that are able to achieve thousands of tok/s
how do you update that baked-in model for things that have happened in the last say 2 months?
if i'm a programmer for example, even being a couple months old is a huge annoyance because programming languages and frameworks are changing all the time...
When was the last time you heard about someone talking about "Knowledge Cutoff" dates? OpenAI used to make a huge deal about it every release, now its not even mentioned.
We give agents tools, the ability to read a man page, the ability to use web search. Knowledge cut-off is far less important than it used to be.
I'd be really interested to see all the software that is written by agents. Whenever I touch agents or ai I can't get much use out of them. My understanding is the value when I think aloud with them/treat them as a better google search, but thats about it. Except one off web stuff, that is a pretty neat use case.
But lets be real, anything moderately complex that is out of the domain of publicly available sample code is hit or miss compared to the time invested running the loop. I'd much rather invest the time in myself.
What a lot of people don't talk about is the inherent security nightmare of trusting ai agents and the sheer data exfiltration happening behind the scenes.
Idk, ymmv. I’ve had very good outcomes writing embedded firmware for complex systems, drivers, etc. it’s really, really good at not bodging the kinds of things that always catch meaty developers unawares.
OTOH, we run extensive harness optimization, where everything is specified in advance, then a plan is made, then a naive review of the plan vs the specification vs the blast radius, then implementation, tests, then a naive review of test coverage, a naive review of the code vis a vis our code guidelines, a review for smells, a review for silo violation and architecture compliance, a reconciliation of the documentation, then planning the next subfeature, etc. probably 10 percent code generation, 40 percent documentation and planning and adversarial review, 50 percent automated adversarial code review.
We use a Claude for planning and generation, sol for adversarial review. Our metrics say we are about 2x. Productive, at a cost of about $300 per dev per month.
We are also shipping less bugs and better, more clearly written documentation (we use technical writing English style guides implemented by Claude)
I think a big part is the constant adversarial review by a different model with no prior context except the coding standards. Also important is context management, we do an onboarding and wrap-up for each session where we have a batch of continuity documents- Learnings, musings, and roadtrips where we let the most successful high-context sessions research and then write about something that they “ became curious about” during the session. That actually brings in a lot of insight to the team and occasionally is brilliant.
Also critical is crossing compaction barriers (standard re-onboarding protocols, writing transition documents prior to compaction, etc)
Also critical is being able to smell when a session is going off the rails. What we do there is sideline the session, wait for master to advance a bit, then have it do a “4c’s” review of the committed work, blast radius analysis, and remediation. If there’s still useful context left we put it into a project unrelated to its failure context. That salvages the valuable session context without staying in the failure trench.
Hi, this really resonated with me and the approach I have been following within enterprise software domain.
Do you mind outlining your stack around this. I know you mentioned python to support your verification harnesses but I am more interested in the agent setup. Are you specifically using Claude and it's skills with custom plugins or are you using other harnesses such as pi. I have settled on superpowers plugin across Claude and Codex, Cursor and most of my time is spent iterating through the design doc between Claude and Codex, implementing with either and starting another review cycle with the implementation, using TDD approach. It can be a lot of work but the end result is more than if I had done it myself. I am trying to formalize more. Anyway, thanks for the great insights.
We built all the tooling as Claude-code tools (mostly in python) and the rest is just documentation for preloading the context and as reference material to pull in by policy before certain tasks. Really, there is nothing complicated or heavy, it’s all process.
For what it’s worth, I’ve made really good, state of the art software in my areas of interest using LLMs. So I do believe you can produce really good software using them. But it’s domains where I have decade of experience.
But even with that result I don’t think it’s something we should bet the whole industry on, and something I personally don’t feel comfortable relying upon
It reminds me of multitabling at online poker. More tables translates into more revenue even if the ROI per table is lower as you don't dedicate as much attention, until it collapses from not being unable to do the right decisions on time and keep tabs on each player. The main difference is, with agents you might be creating (technical) debt.
This has been my observation too. Because I'm chatting it feels like I'm not working, so any output can be "productive" in that context but I'm hyper aware of all the negative time here. Correcting, pushing it back to the prompt, reminding it that it doesn't have full context so do what I told you not what you think, and then verifying it and correcting it (always) seems to take longer than just doing the work myself
I find this is the difference between people that 2-4x their productivity and improve their shipping quality vs those that don’t find AI very useful. It’s all about the process, the adversarial tension, and the documentation driving the process. The good code squeezes out of that pressure like juice being pressed from fruit.
You need loops so they run longer and use less of your context and brain power. Then (and this is where WFH is a super power) do stuff like walk, daydream, come up with killer ideas like a Madman episode laying on the office couch.
It’s like herding cats, if you’re doing it right. There should be enough adversarial tension in your process that the majority stays on track, but the parts where you are managing and have strong observability are the points where AI needs supervision to not go wildly off the rails, and where you can cull or redirect pathological sessions.
I've been reading a lot of stories like this lately. I'm no business genius, but you'd assume that investors are. Are they just blind or are they burning cash on purpose. What's the steelman argument here?
Looking at these investments through the lens of traditional businesses (which is the perspective taken by articles like this) won't make sense. It's not until you appreciate the expectation of how disruptive this technology will actually be does any of this make sense.
These people think they're on the verge of creating a technology which, at a minimum, would constitute an unprecedented superweapon (and, at the extreme, would usher in a new era of civilization). Even if you don't buy-in to the take that one of these companies will reach a singularity and create a superintelligence, the cybersecurity implications alone is enough to put these products into a category outside the confines of profitability. We're already starting to see these implications become reality.
If the US NEEDS an advanced AI on an existential level, then it doesn't really matter how much it costs to make or whether or not it can produce a profit. It'll be valuable one a scale where financials like that just don't apply.
> I'm no business genius, but you'd assume that investors are.
Absolutely not a reasonable assumption at all. Most people are not very good at their jobs.
> What's the steelman argument here?
If you're right about your prediction, but wrong about the timing, then you're wrong. The markets can stay irrational longer than you can stay solvent. Meaning, even if you know it's going to crash eventually, you don't know if it's tomorrow or in three years. Betting on stocks going down is extremely risky -- you have to get the timing pretty much exactly right, or you lose everything (potentially much more than you put down, depending on how you do it). Meanwhile, bull positions are basically free money until this point. Getting completely out of the market means you lose to inflation, although many investors have taken this strategy anyway.
reply