Well it’s not up to me what you do 
I just find that this topic is so big now I can’t even scroll to the top and the links are likely to get dated pretty quickly.
JMO
Actually, I look forward to the Richard feed and find some interesting stuff in them. I don’t click on all of them, but I browse through them and appreciate seeing them there.
First I found out about this.
With the speed differential being reduced with SSD’s and NVMe SSD’s, I dont think it will be long before we see more LLM’s running models direct from disk appear, albeit with very low token fractions per second, instead of being pruned and optimised for local use.
The engine is correct: every layer is validated against a PyTorch reference, the final logits agree to 3.6e-06, and the vision tower matches its own oracle to 2.3e-06. It is also slow — half a token per second, thirty seconds for the sentence above.
We are not aware of another published demonstration of a model this size streaming from disk on a consumer machine: we found none for trillion-scale NVMe streaming, and the best-documented 671B-class recipes assume a server with a terabyte of DDR5. That is a report of what our search turned up rather than a survey
What that opens up, concretely: a frontier-scale model that answers with no network, no per-token invoice, and nothing leaving the machine — which is the difference between “you may not send that data to an API” and “run it here”. The format and the engine are not K3-specific in any deep way; K3 is simply the hardest case that exists today, and a model that streams at 2.78T streams comfortably at 48B.
Memory got expensive. So I gave a 26-billion-parameter model a ~2 GB budget.
TurboFieldfare runs the instruction-tuned Gemma 4 26B-A4B without loading the entire 14.3 GB model into memory. It keeps the shared 1.35 GB core and FP16 KV cache in memory, then streams only the experts needed for each token from SSD. This is what lets the model run on Macs with 8 GB of RAM.
The models are available in five distinct sizes: E2B, E4B, 12B, 26B A4B, and 31B. Their diverse sizes make them deployable in environments ranging from high-end phones to laptops and servers, democratizing access to state-of-the-art AI.
Gemma 4 models are designed to deliver frontier-level performance at each size, targeting deployment scenarios from mobile and edge devices (E2B, E4B) to consumer GPUs and workstations (12B, 26B A4B, 31B). They are well-suited for reasoning, agentic workflows, coding, and multimodal understanding.
The “E” in E2B and E4B stands for “effective” parameters. The smaller models incorporate Per-Layer Embeddings (PLE) to maximize parameter efficiency in on-device deployments. Rather than adding more layers or parameters to the model, PLE gives each decoder layer its own small embedding for every token. These embedding tables are large but are only used for quick lookups, which is why the effective parameter count is much smaller than the total.
The “Unified” in Gemma 4 12B Unified refers to its encoder-free architecture. Other Gemma 4 models use dedicated encoders to process multimodal data before passing it to the LLM. Gemma 4 12B eliminates these encoders entirely, projecting raw image patches and audio waveforms directly into the LLM’s embedding space through lightweight linear layers. This unified approach means all modalities flow straight into a single decoder-only transformer, reducing multimodal latency and allowing the entire model to be fine-tuned in one pass.
The “A” in 26B A4B stands for “active parameters” in contrast to the total number of parameters the model contains. By only activating a 4B subset of parameters during inference, the Mixture-of-Experts model runs much faster than its 26B total might suggest. This makes it an excellent choice for fast inference compared to the dense 31B model since it runs almost as fast as a 4B-parameter model.
Kuna, an experimental decompiler I’ve been developing over the summer while working as a visiting faculty researcher at the Air Force Research Lab (AFRL) and a research fellow at Metalware. However, when I say that I have been developing, I should clarify that an LLM has written nearly every line of code in this project.
Yet, as it stands now, this decompiler rivals the industry standard, IDA Pro (9.2), in control flow structuring on C programs: in recent benchmark results, Kuna achieves perfect structuring on 44.4% of functions, compared with IDA’s 45.7%. This was largely achieved through autonomous refinement: the LLM studies examples where it performs worse than IDA Pro on fundamental metrics, which have only emerged over the last few years. Using this strategy, it can effectively learn how another decompiler solves a hard problem through trial and error.
Yann LeCun, Turing Award winner and former Chief AI Scientist at Meta, joins Jacob Effron
0:00 Intro
01:45 Why LLMs Aren’t the Path to Intelligence
07:51 AMI and World Models
12:07 The JEPA Architecture Explained
15:55 Problems with Robotics Models Today
20:37 Silicon Valley Herd Behavior
28:18 Tapestry: Sovereign AI for the Rest of the World
35:49 OpenAI Is the Next Sun Microsystems
40:51 Why Yann’s Views Diverged from Hinton & Bengio
44:32 LLMs Are Intrinsically Unsafe
58:00 Why Yann Left Meta
1:00:26 Reflections on FAIR
1:12:11 Advice for PhD Students
I like this piece, its also got an interesting lesson, but you may not spot it. 
A 2025 Veracode report found that approximately 45% of AI-generated code samples failed security tests and contained critical vulnerabilities from the OWASP Top 10, and a multi-language, multi-model academic study that evaluated outputs from Claude, Gemini, Codestral, GPT-4o and Llama-3 across Python, Java, C++ and C, found that a substantial fraction of generated snippets were either non-compliant with basic secure coding standards or actively triggered classified weaknesses (buffer overflows, hard-coded credentials, SQL injection, cryptographic misuse, path traversal, you name it).
Richard, I think one of the more interesting lessons in that article is hiding inside one of the studies it cites.
The scary result was that after several rounds of AI modifying AI-generated code, serious vulnerabilities increased substantially.
But the researchers had deliberately taken the experienced programmer out of the loop.
In other words, the experiment that appears to demonstrate the danger of AI programming may actually demonstrate something slightly different:
The danger is not AI writing code. The danger is removing the programmer.
That distinction matters.
A competent programmer using AI can get an enormous amount of work done without personally typing every line. But somebody still has to understand the problem, recognize bad decisions, question the architecture, test the result, and know when the AI is confidently heading in the wrong direction.
I’ve been seeing exactly that in some fairly substantial AI-assisted development work lately.
Individual AI sessions can make perfectly reasonable local decisions that, over time, don’t necessarily add up to the best system globally. At that point the important programming job isn’t typing code at all. It’s recognizing the pattern, stopping the work, examining the architecture, and deciding what should happen next.
So I don’t think AI makes programmers obsolete.
If anything, as AI gets better at doing the implementation work, it may make the distinction between writing code and being the programmer in charge considerably more important.
Try telling that to all the non-programmers who have proudly published apps to the app stores, or who were Excel warriors who have suddenly found something even more powerful and dangerous.
My worry is that AI is going to be insidious and all the plugins that are now being written by AI will potentially have hidden little vulnerabilities. Most users have developed some common sense about installing unknown software and most of these users who are now “programming” with AI have suddenly no idea what they might be letting themselves in for?
As an aside, I don’t know if this little incident made news outside of OZ, but it caused a good deal of laughter down here…
I actually think we’re mostly agreeing, we’re just using the word programmer a little differently.
Yes, AI now allows a non-programmer to produce something that looks like software, put it in an app store, write an Excel replacement, create a plugin, or otherwise distribute code without ever really understanding what is underneath it.
And that is precisely why I don’t think the programmer has become obsolete.
The ability to produce code and the ability to engineer software responsibly are two different things.
For most of the history of computing, the difficulty of writing the code itself acted as a fairly substantial barrier to entry. You normally had to learn quite a bit before you could create and distribute anything very complicated.
AI is rapidly removing that barrier.
That is wonderful in one respect, but it also means we’re handing extraordinarily powerful tools to people who may have no idea what questions they should be asking about security, data integrity, failure modes, architecture, dependencies, permissions, or a hundred other things experienced programmers have learned to worry about.
And there is another wrinkle that becomes especially important once we move from AI assistants to autonomous agents.
The agent doesn’t necessarily have to write the dangerous code.
It can go looking for a package, library, repository, tool, or agent skill that appears to solve the problem and incorporate that into the project. That creates an obvious opportunity for bad actors: make something malicious look like a useful problem solver and hope that an AI agent decides it is exactly what it needs.
We are already seeing security research around exactly this class of software supply-chain attack – including techniques intended to steer coding agents toward attacker-controlled dependencies.
And an inexperienced human supervising the process may be particularly ill-equipped to notice what just happened. The application works. The AI says the problem is solved. Everybody is happy.
Except somebody just invited the burglar into the house.
That’s why your plugin example concerns me too. A plugin can look perfectly innocent and work perfectly well while containing a vulnerability its creator doesn’t even know exists – because the creator never understood the code in the first place.
And I thought the gym story was fascinating for a related reason. That’s another step beyond AI-generated code. Now we’re giving an AI agency and telling it what result we want, while allowing it to decide how to get there.
That makes the old programmer’s question “What exactly can this thing do, what does it depend upon, and what happens when it does something I didn’t anticipate?” considerably more important, not less.
So perhaps the distinction I would make is:
AI may make it possible for almost anyone to create software.
That doesn’t necessarily make almost everyone a programmer.
I definitely believe that as we give AI more autonomy, having somebody who understands what is actually happening may become more important than ever.
Could argue Firewalls are abit useless as well.
Out of the box they block stuff coming in, but once some malicious code is in the computer running, its carte blanche come and go whenever you like.
Game Over.
Govt and Industry wont care about this much because they see it as more job creation.
I spent some time a few years back with a red team manager who was working for a large US company in the UK, he had some connection to GCHQ, so I got to see how their development process worked.
Besides doing Teams meetings in a busy Wetherspoons pub in the afternoon once the US had woken up, it was quite an eye opener.
The programmers literally dont care what code they turn out. Its got to meet their metrics, which is does it do the job? Yes? Does it work with their existing code? Yes? Job completed. Dont care about anything else until told to.
Then the Red Team would apply their knowledge to hacking the updates. They got told what to test and if they couldnt find a problem it was signed off and the code went public.
However if problems were found, report made, code went back to Dev to solve. This kept the workload up for the developers, but as long as management saw this Dev-Red Team cycle taking place, they didnt care about code quality.
It defied logic, but I guess the costs were low and thats all the management cared about. I guess the fact the management were using a permanent Red Team to do their code testing must have made management look and feel genius.
The company was a large online US company with a big UK presence, think like Shopify, but not Shopify.
Richard, I think that development story actually illustrates the same problem from another direction.
There is nothing inherently wrong with having a Red Team attack software before release. In fact, I would consider that good practice.
What seems crazy is the attitude that security therefore isn’t the developer’s problem.
If the developer’s definition of success is simply:
Does it do what the ticket says? Yes. Ship it to the Red Team.
then you’ve divided responsibility into little boxes where everybody can truthfully say, “I did my job,” while nobody is actually responsible for the quality of the finished system.
I think AI can make that substantially worse.
Previously there was at least some friction involved in adding 5,000 lines of code, pulling in three new libraries, or creating a completely new subsystem. Somebody had to spend time doing it.
An AI agent can now do all of that before lunch.
So if the metric remains simply “does it work?”, we can produce insecure technical debt at a speed that would have been impossible a few years ago.
That’s another reason I keep coming back to the idea of somebody being in charge of the software, rather than merely somebody or somethingwriting the code.
And I wouldn’t quite write the firewall off either. Once malicious code is executing locally you’ve certainly lost an important battle, but good security should still be trying to limit what that process can access, where it can connect, what credentials it can obtain, and how far it can spread.
To me the dangerous assumption is the old one:
“It’s inside the firewall, therefore we can trust it.”
With autonomous agents downloading packages, invoking tools and talking to outside services on their own, that assumption becomes even less defensible.
Your Red Team story also contains another lesson that may become important with AI: testing quality into a product at the end is a lot harder than engineering quality into it from the beginning.
AI doesn’t change that rule.
It just lets us violate it much faster.
I think you give programmers, and with respect Clarion programmers too much credit here.
What I mean is that the programmer might be really good, but still put things like security very low on their priority list.
Yes, the clarion language makes some common security flaws go away (SQL access via file driver) but prop:sql (in really common use, and actively recommended by most experienced SQL users) is a SQL Injection hack waiting to happen.
Or the number of people happily using old versions of Nettalk for their server (because "if it aint broke dont fix it).
Most programmers, Clarion or not, do not have security as a priority and never have. And me prattling on about OpenSSL versions or how prop:Sql should be removed and replaced by a safer alternative is a nothing burger.
Because safety is not a priority, the AI wont be prompted to make things safe.
Of course most programmers are bad at creating secure code. The AI can actually help a lot here. It just needs to be used correctly. I like what John is doing. He has 5 agents examine the code, using multiple models, after the AI has written it. Those 5 agents all have a specific goal in mind, and one of them is security.
John isn’t a security guru, but its a priority for him. So he tasks an agent to check that.
But for most programmers old and new, trained or excel-warrior, security simply isn’t on their radar at all. And so whether they are hand-coding, or app developing or AI prompting makes no difference. The stuff they are producing is insecure by omission.
I disagree. Firewalls are incredibly important and not to be using one on your internet connection would be terrible.
I agree, they are not a silver bullet. They dont prevent every possible kind of attack. And yes, getting the user to execute code inside the Lan is the holy grail, and firewalls do nothing to stop it.
Its kinda like cancer. Not smoking is good advice, and reduces the risk of some cancers (lung, throat etc) by roughly 90%. That makes it good advice. But it has no effect on your chance of dying in a road accident. (For that, no alcohol, has a similar beneficial effect.)
Likewise a firewall is an important tool that is necessary to prevent a multitude of attacks. It equally does nothing for Viruses, Trojan Horses, Social attacks etc. Despite that, It is a long way from useless.
Bruce, you keep talking about the “new SQL driver” and how it is more secure than using prop:sql and yet the “new SQL driver” is a Capesoft tool, not an intrinsic part of Clarion, which makes it an excellent example of your argument!
Rich, this is exactly the process on which AI is trained as many have learned. Some AI tools are improving and we (humans) are training ourselves to be more explicit in our requests to AI, but it can still be incredibly frustrating trying to get ChatGPT to give a straight answer to even simple questions. 
Some coding tools are making great progress- Claude for example. I consider this the early phase of AI and it’s only a matter of time before security is a given. Unless of course it’s in “someone’s” 
vested interest to have security holes in these tools.
Bruce, I think that is a very good correction to what I said.
You’re right that I’m giving the word programmer too much credit if it implies that an experienced programmer automatically thinks about security.
Clearly they don’t.
I think the distinction I should have made is not simply:
“Keep a programmer in the loop.”
It is:
“Keep somebody responsible for the entire software system in the loop.”
And I think there is a particularly interesting Clarion angle to this.
Historically, a lot of us Clarion developers lived inside a comparatively bounded ecosystem.
That didn’t mean security didn’t matter, of course, but the boundaries were fairly understandable. We worried about things like authentication, permissions, SQL injection, protecting data, keeping NetTalk current, and securing whatever outward-facing surfaces our applications exposed.
We generally weren’t assembling applications out of dozens of unfamiliar components pulled from arbitrary repositories all over the Internet.
AI is changing that.
A Clarion developer can now ask an AI to solve a problem, and the solution may involve bringing in a DLL, a JavaScript library, a Rust crate, a Python component, some C code from GitHub, a command-line utility, or practically anything else that Clarion can ultimately call or communicate with.
That’s enormously powerful.
But the moment we start doing that, the old boundaries around the Clarion ecosystem become much more porous.
Now we inherit the security assumptions, dependencies, vulnerabilities and potentially even malicious behavior of software that did not originate anywhere near the Clarion ecosystem.
It also connects directly to what we were discussing earlier about malicious packages and repositories. If an autonomous coding agent goes looking for a solution and finds something that appears to do exactly what it needs, we cannot assume that because the AI found it, evaluated it and integrated it, therefore it is safe.
Somebody still has to ask:
Where did this come from?
What does it actually do?
What does it depend on?
What permissions does it need?
Do I trust it enough to put it inside my application?
That is going to become a much bigger responsibility for Clarion developers who choose to play in this broader ecosystem.
Also I really like your example of John using multiple agents to review the work, because I think that points toward part of the answer.
John doesn’t personally have to be a security expert.
He does however have to recognize that security matters enough to make it an explicit part of the process.
He can absolutely task an AI agent specifically with reviewing security. In fact, that may give an individual developer access to a level of specialized review that would previously have required another person with expertise they didn’t have.
But there is an important catch:
You have to remember to ask for that review.
And after the agent says, “Everything looks good,” somebody still needs enough skepticism to look over its shoulder and make sure it actually examined what it claims to have examined.
That is very close to the development model I’ve been evolving toward myself.
For increasingly complex work, I no longer think one AI session should be expected to simultaneously be programmer, architect, database expert, security expert, tester and reviewer.
I’m increasingly using a Conductor + Worker approach, where one agent maintains the larger project state and commissions bounded workers to implement or independently examine specific areas. Sometimes I deliberately have separate agents audit the same architectural question from different directions before deciding what to do.
Above all of them, I’m still responsible for deciding what matters and whether the result is acceptable.
So perhaps the better formulation of my original point is:
The danger isn’t merely removing the programmer.
The danger is removing accountable engineering judgment.
AI can actually give an individual Clarion developer access to more specialized expertise than we have ever had before.
But it can also connect our applications to a much larger and less trustworthy world than the one we grew up developing in.
We have to take responsibility for both sides of that equation.
I’m not 100% sure of your point here Geoff, so forgive me if I missed it.
Yes, the driver kit is an external offering, not part of Clarion itself. One of the reasons for it’s development was specifically to provide a secure approach to prop:Sql for our own code. It is shipped as source code though, so once installed it becomes “part of Clarion”.
Again, not sure how the better security is related to whether it’s 3rd party or not, or indeed how it affects programmers general approach to security but I hope I covered it above.
I agree, and this is the approach John has taken.
However this requires a fairly advanced skill set, and I’d argue very few people (and likely none of the “look I made my first app” folks) are approaching this level of skill, or indeed understanding of why this skill is even ncessary.
While current tooling exists to support this model, it far from the norm. And till it becomes the norm I think most AI generated code should be considered as insecure at best, and malicious at worst.
Bruce, I agree with that, with one qualification.
I do think it takes a different skill set to work this way. John has obviously developed one version of it, and I’ve been developing my own through a lot of practical experimentation.
Where I differ slightly is that I don’t think it necessarily has to remain a special skill set possessed by a handful of people who happened to figure it out.
I think it can be taught.
There are patterns to this.
You learn not to give one AI responsibility for an entire large project indefinitely. You learn how to separate planning from implementation, how to give workers bounded jobs, how to preserve project authority outside the individual AI conversation, how to rotate agents before context deterioration becomes a problem, how to commission independent reviews for things like architecture and security, and how to require evidence instead of simply accepting “I checked it” as proof that something was actually checked.
And interestingly, those principles apply whether you’re doing relatively traditional session-based AI coding, working back and forth with an AI in individual conversations, or moving toward much more agentic development, where AI agents are given tools and enough autonomy to carry out substantial jobs themselves.
The mechanics change, but the discipline really doesn’t.
If anything, the more autonomy you give the AI, the more important the boundaries, checkpoints, independent reviews and evidence become.
None of those ideas requires somebody to be an AI researcher.
But they do require learning a different way of being a programmer.
In fact, that is one of the major things I’m working through in an upcoming book I’m writing, Real Programmers Use AI.
The premise isn’t really “here are some good prompts.” It is much more about how an ordinary experienced programmer can develop a disciplined working relationship with AI where the AI can do an enormous amount of the actual work without quietly becoming the person in charge of the project.
Also I think that’s important because the tools themselves are going to keep changing. Today’s chat sessions will become tomorrow’s agents, and those agents will undoubtedly become more capable and autonomous.
The methodology has to survive the tools.
I think that distinction is going to become increasingly important.
We shouldn’t have to say, “John can do this because John has developed a very specialized AI skill set.”
We ought to be able to say:
“Here is the method. Here is why it works. Here are the failure modes. Now learn how to do it yourself.”
That, to me, is where this gets really interesting.
Sorry Bruce, my point is that SV are selling a product with a known, solvable security risk and that either the (your) “new diver” should be part of the supplied product, or they should fix the problem themselves.
JMO
ALL of the major AI models have improved dramatically in the last six months, and even in the last three months.
As someone who uses both Claude and ChatGPT 8-10 hours a day, I can definitely say that neither of them is even remotely close to what it was six months ago. They are far more capable now.
When you watch Claude and ChatGPT work, they are actually using fairly similar methods of reasoning and work delegation, even when you are just using them in normal “chat” mode.
The code I see coming out of ChatGPT today is pretty much on par with what I see from Claude, and Gemini is getting very close as well.
Grok and DeepSeek are advancing too, although in the coding-related tests we run against them, they are still not quite at the same level. Both do fairly well for general information, although Grok can sometimes seem a little scatterbrained. Perhaps that comes with the territory. 
Right now I have five fairly high-level projects that are intertwined and in the later stages of development and testing.
I use multiple sessions of both Claude and ChatGPT, sometimes deliberately from different accounts so they do not share the same conversational history or develop the same code bias, to check the work of the others.
I can move sections of a project from Claude to ChatGPT and back again and, for the most part, the transition is seamless.
One of the things I’ve written about recently is that the way you need to interact with these systems has changed dramatically, particularly over the last 90 days.
The giant prompts that helped in the beginning can actually hurt you now.
These days it is much more about context, balance, and clear instructions that define not only what work needs to be done, but also what constitutes success and failure.
Likewise, where a giant file containing every rule and guideline might once have worked well, I now get better results by maintaining a short, definitive guide that points to smaller focused documents. The AI can then retrieve the information it actually needs for the task at hand instead of dragging the entire project’s history into every decision.
It is also important to understand that just because today’s models have much larger context windows and you CAN run a conversation much longer, that does not mean you SHOULD.
I use a two-level process.
One AI session acts as the project conductor, and we spawn separate threads as workers to perform specific jobs.
The worker gets exactly what it needs to do that job, and the handoff to the worker is normally written by the AI project conductor itself.
When the worker finishes, it writes a handoff back to the conductor explaining what it did, what changed, what was tested, and anything the conductor needs to know. Then that worker thread is finished.
The conductor evaluates its own health every three or four worker iterations and decides when it is time to hand its own job to a fresh conductor.
I also keep discussions about new ideas, bugs, architecture changes, or major feature changes in completely separate conversations. I don’t want those exploratory discussions polluting the project conductor’s context.
When one of those discussions produces something we want to implement, the result gets turned into a handoff document and passed to the project conductor. The conductor can then assign it to a worker when it fits into the project plan.
Interestingly, both Claude and ChatGPT have accumulated enough broad knowledge of what I am working on that they understand how the different projects fit together and where they diverge.
But they also understand that my rules of engagement require them to “stay in their lane” and not allow work on one project to start influencing the conductor of another.
The newer high-powered models are slower because they spend more time reasoning. That really doesn’t bother me.
Working this way, I simply assign one conductor/worker pair a task and move to another project.
I do whatever testing or evaluation is needed there, have that worker write its handoff when the job is complete, close the worker thread, and then the conductor and I determine the next task and create a handoff for a new worker.
Then I move on to another pair.
So in practice, I am almost never sitting around waiting for an AI to finish something.
I use Firefox, and its colored tab groups make it easy to keep the conductor and worker threads for each project together.
About once a day I also shut down the entire PC and the VMs where I run AI coding agents. The agents NEVER run directly on my host PC.
When everything comes back up, Firefox restores the tabs and groups exactly where I left them, and I continue working on each project.
It is actually quite efficient. Once you apply a little organization to the process, it becomes surprisingly easy to manage.
It feels a lot like being the lead programmer overseeing several development teams.
I don’t have to personally type every line of code, but I remain 100% in control of what is being built. More importantly, I don’t waste huge amounts of time or tokens, and the projects don’t “drift” because an agent wandered off and decided to redesign something on its own.
“Plan the work and work the plan” still applies when programming with AI.
It works a lot better than saying, “Build me one of these,” and hoping for the best.
My advice to everyone would be not to get too comfortable with any one AI vendor, or with what you think you already know about how to use AI.
At least once a month, step back and revisit the other major systems. Also keep up with what the companies themselves are saying about how their models are changing and how they recommend using them.
Anthropic and OpenAI both publish regular information about changes in their models and tooling, and there are plenty of people writing good articles every week about what they are discovering in actual use.
Whatever you concluded about AI as a programming tool a year ago, or even six months ago, is almost certainly out of date today.
And the same will probably be true six months from now.
As they say in some circles:
“Hang onto your hat. You ain’t seen nothing yet!”
Charles