Hard mathematics problems used to take years if not decades to tackle manually. But now with enough compute and a hint that a certain approach might work, it just takes a few days. This could be the last year that humans could still make more substantial contribution to major match problems than machines.
I like the "Dark Integers" series of stories written by Greg Egan. They might even have inspired Liu Cixin to write in Death's End that somewhere deep in the universe, some powerful civilizations would weaponize physics laws, and some other even more powerful civilizations could even weaponize mathematics laws.
I've been trying this Gemini 3.8 Flash for a day. Looks not much different than Gemini 3.7 Flash in my use case: I have Codex (gpt-5.6 sol) write up a design plan to implement a feature or refactor a portion of a system I am building, and have Claude (Opus-5) and Gemini (3.8 Flash) review and critique the plan, until all problems are addressed by Codex and approved by the reviewers; then have a cheaper model of Codex (gpt-5.6 luna) implement the plan, and still have Claude (Opus-5) and Gemini (3.8 Flash) review and critique the implementation, until all problems are addressed by Codex and approved by the reviewers.
The result is the same as the previous Gemini 3.6/3.7 Flash days: Claude could always note much more problems in Codex's plan and implementation than Gemini could - the ratio is like 10:1.
I occasionally switch the roles between Codex and Claude, and result is the same, Codex could always catch much more problems in Claude's plan and implementation, than Gemini could.
So I am guessing in a relatedly complex codebase, Gemini is much less effective in acting as a guardrail (or a senior engineer/team lead) than the other SOTA models.
I find this very interesting, I wonder if there is a public benchmark that reflects this “red team coding critique” aspect of the current SOTA model that reflects what you have observed.
It would be really useful to observe this in a benchmark vs. the more common “go implement this, or fix this bug” type benchmarks that seem to be prevalent.
Yeah, my tool to automate these review loops is https://github.com/wwind123/coding-review-agent-loop . It's basically a script calling Claude, Codex and Antigravity CLI's. The benefit of using CLI's is, the tool uses quota in your subscription plan of these AI providers, which is much cheaper than using extra tokens from the same providers to do the same thing.
A couple of months ago (before opus-5 and gpt-5.6 sol), The ratio of problems caught by codex/claude vs gemini was more like 2:1 to 3:1. But now it seems codex and claude have made huge leaps and gemini is more or less staying put.
Amazingly, these few days the Gemini 3.8 Flash (High) has been catching much more problems in code reviews than before. I think it started from the second day since I posted the observation above. Maybe somebody from Google saw my posts and tuned some knobs in the model to allow more critical thinking?
Another observation, Gemini's review on code is more critical now, but its review on design plans is still quite agreeable - it tends to approve Codex's design plan immediately, while Claude could often pick out a bunch of problems in the design plan in the first round of reviews.
Taxing resource consumption, would likely encourage companies to optimize for less and less resource consumption. That by itself might be a good thing. But what if some day companies achieved the ultimate savings, using very little resource to produce the max amount of things. You'd get very little tax revenue to feed the society.
Of course, if those max amounts of things have few consumers because most people are just too poor to afford them, that'd make companies (or the agents that run companies) think twice too. At some point these AI agents might work together to come up with an economic system to make it possible for society to afford their products so they could further grow.
I think a resource consumption based tax model extends very neatly to a UBI model. One could think of as: "this is the basic resource consumption we allow each person" and it automatically generates demand for basic services everyone should be able to afford with their share of resources, while keeping a free market and allowing an economy on top with extra resources. Standard money could still be the means for value exchange, just taxing works differently.
I understand the approach to wait until the same pattern shows up across multiple different problem domains, to build a good solution for all of them.
But sometimes it's a chicken-and-egg problem.
Teams most often don't have the patience to wait for your proper solution. If you don't have a ready solution to easily address their problem, they just build their own work-arounds, or give up the task if it's too hard. And those teams all have their own priorities to tackle on their plate for the quarter, so even if you eventually build a proper solution later, it's unlikely they'd migrate to your solution or restart their task.
So even if you have accumulated a lot of old use cases, when you build a proper solution you'd need new use cases to justify your effort, the ones where the owner teams are willing to build along with the iterations of your solution. That kind of new use cases may or may not come up when you have the bandwidth and resource to actually do this. And if you miss one opportunity, the constant shifts of organization priorities would likely mean there would not be another chance for you to do it. The end result is, every team either builds their workarounds, or just give up if it's too hard, without a proper solution.
Nowadays I mostly listen to e-books when I am doing house chores or driving or doing some other things that require the eyes but not the entire brain. Not sure if it counts as reading. If it does, then I read about 10-15 books a year. I haven't read a long-form book completely with my eyes for a long time.
I learned BASIC in 1985 on an Apple II, and 6502 machine language in 1987, while in high school. I was able to publish a 6502 machine language program on a national computer magazine that year. Back then we printed the hex code of the program on paper, along with some explanation, then mailed it to the magazine. The magazine stuff manually typed in those hex code on the computer, and if they thought it worked well, they'd just publish hex code of the program and the explanation. Interested readers would then just typed the hex code into their computer to try it out.
The publication validated that programming was something I liked and was good at, which became the main factor I chose computer major in college.
A lot of old mission-critical banking or commercial software systems have been running on those machines for decades. Before the AI age, it'd seem impossible to migrate those programs off. Now with the AI help, there might be a glimpse of hope.
Honestly, a lot of it was not that hard to port if you really wanted, it's just that the ROI of replacing the entire stack including physical machines was not necessarily good. The parts where ROI was good got replaced already.
I guess you could line-for-line duplicate functionality, but that's just like running the binary in an emulator with extra steps.
Part of the value of a migration would be the opportunity to to unwind some of the details that are contradictory, mis- or non-documented, or wrong-but-unfixable.
The logic changes can be done without destroying investment in the current ecosystem though. So they are really handled separately in terms of planning/budgeting.
Also, a lot of the problematic issues are related not to fixing the local code, but dealing with stuff like external systems or pre-existing legacy data that you need to be able to read back after 30 years from cold storage.
Yeah. Bug-for-bug migration is a real thing in large code-bases in the industry. You want to replicate all behavior of the code regardless whether the behavior is a feature or a bug.
reply