It is also worth mentioning that the openpilot AI model is a world model. The way a world model understands physical reality and geometry makes it inherently safer for driving than an LLM, which is essentially a text-based statistical machine with no concept of the physical world.

LLMs are really good at discovering patterns on huge dataset. Google also had similair breakthrough discoveries they stopped marketing them

yes and no; you cant dump DNA in the context window and call it a day, in the blog post it was a common tool calling session. you do can have actual ml models for that, that the llm could use as a tool.

I don't think you quite understand the loops here.

At Google/OpenAI/Anthropic level you have clusters of LLM agents working with clusters of ML agents doing all kinds of tasks. A lot of this falls into proto-RSI where the LLM can improve the ML agents output based on analysis of said ML.

This isn't much different from how people work, you can't dump even part of DNA context in a human mind and get anything useful out. We has humans have to use and build tools to find answers because of scaling efficiencies of different computation types.

I am using Pi with anthropic models for plan & execution, openai models for code review and fallback in case I run out of tokens. Also have custom hooks to automatically compact, switch models based on the type of tasks, change effort and custom statusline. Also have custom setup in Pi to calls tools and CLIs instead of relying on mcps. The level of customization I can reach with pi is not really feasiable with codex or claudeCode. By the way anthropic changed it's ToS regarding custom harness: you can`t use their model unless you got extra usage enabled or paying through APi billing, you cant use your subscription anymore. We all guessed what the reason might be. Also codex is open source, I havent really looked at that project yet because Pi fulfill my desires for now.

Sounds wildly overcomplicated.

I am not an SWE, rather a hardware guy with light software experience, and the next home project on my docket is getting AI to write the code for my own ESP32 thermostat (with a nice e-paper display too).

We have a mix of splits, central air, and gas baseboard, so being able to customize all that to fit our utility pricing time slots is a dream.

The problem here is there is almost always incentive to make that software shit.

I have mixed feelings about this. Going all-in on Model Context Protocol (MCP) is definitely a bad idea because I noticed the Jira and GitLab MCPs were consuming an excessive amount of tokens. To solve this, I decided to install their respective CLIs instead so we could find a balance and get the best of both worlds. For example, certain MCPs bring too much overhead, especially when they only handle a single task. Instead of letting the coding agent constantly waste resources re-discovering how to fetch a specific work item field, I had Claude recursively run --help on the CLIs and save all possible actions into separate Markdown files. This approach allowed me to build two lightweight plugins that do exactly what an MCP is supposed to do but with significantly less token consumption. If anyone wants to check out the code or use them, I have open-sourced both repositories on my profile:

* * acli-skills: An Atlassian CLI agent skill that maps out Jira commands cleanly. * glab-skills: A GitLab CLI companion built directly for efficient agent workflows. *

To maintain visibility with this setup, we also developed a custom [Claude Code](https://code.claude.com/docs/en/plugins) plugin that streams live updates regarding our background operations directly into the console. That said, MCPs are still extremely useful for rapid prototyping and when we build custom internal tools to speed up development. We found them particularly valuable for:

* * Sampling: Asking the LLM directly to detect entities and summarize log files. * Notifications: Handling long-running tasks that require fetching data from multiple sources. By logging each step and aggregating them via sampling, a single update is sent back to the coding agent, preventing it from spinning up multiple redundant processes. *

I kinda find it funny when I use the advisor on claude code and it agrees with the ideas that the previous model did.

For info: the advisor(s) available are higher end models. For example: you use sonnet, the available advisors are opus and fable. If you use Haiku, the advisor are sonnet, opus and fable.

same spec, same chip. I tought Apple would at least bump the RAM

You thought they'd bump the base RAM in the middle of the biggest RAM crisis in history?

Yea, that wasn’t going to happen.

yep why not ? "Unified Memory" was always their favourite selling argument

Because they would be throwing away margin for no real reason

Keep in mind also that LLMs are currenctly heavily subsidized. Once VCs money are gonna run out, you will see the real price, and your 200K per year dev is probably nothing.

A $1200 GPU is all a reasonably capable engineer needs for each work stream. The cloud prices are a scam.

hmm that's a bit low right now, since you need at least 48Gb of VRAM to be confortable. 32Gb might do it (on quantitized models + optimized) but it would be very slow.

That may have been true a few months ago, but shit changes fast in this space!

I run Qwen 3.8 27b on each of my six AMD AI PRO r9700 GPUs at 80tps decode each and they cranks for days with 256k context, doing complex kernel, compiler, debugging, enclave, bootstrapping, pentesting, hardening, and systems work full time.

~$1200-1500/ea on ebay.

Also ~40tps on my strix halo now but with room for several sessions at once.

What is your config for getting 80tps decode?

Qwen 3.8 27b Q4_K_M w/ matching dflash drafter, 256k context, llama.cpp+dflash2, draft-n-max=5

Also using with Charmbracelet Crush with Froggerinc fixed chat templates.

Thank you! Have to look into it.

same playbook than Huawei