mohsen1

I have a philosophical problem with adaptive thinking. It’s a dumb guess for how much thinking budget to allocate ahead of thinking. At least in the context of LLMs there is probably no way of knowing how much thinking (token generation) is needed. The problem space is infinity vast, similarly of two prompts is not going to help any LLM decide how much thinning is needed. Models already stop thinking before hitting the thinking budget.

Why there is so much effort in making adaptive thinking happen and don’t we train models to produce the end of thinning token better?

Feels like a bandaid. We need models to be trained to do a reasonable amount of reasoning (no pub intended):

    reason

    estimate remaining uncertainty

    continue?

    reason more

    repeat

Computer Scientist Explains One Concept in 5 Levels of Difficult

https://www.youtube.com/watch?v=fOGdb1CTu5c

This video is very beautifully explains it

This seems to be a new trend. Noticed it with GPT "ultra" in their announcement[1]. I'm with you, a large language model and a system of many language models working together are not the same thing

[1] https://news.ycombinator.com/item?id=48689338

It seems like we forget that LLMs are next token prediction systems. Using raw models without instruction following and chat completion bells and whistles will give you a better feeling of what LLMs are.

The current interface to LLMs are heavily biased towards "predict the next token in the context of a user with a helpful assistant" but LLMs are capable of other modes of next token prediction too.

Before the ChatGPT release people often measured LLM performance by how well they could produce a coherent story or a poem. that's where Anthropic model names are originating from I am guessing.

Nice thing about the microvm is that you can snapshot it and restore it. Keeping the fs minimal is my goal. Snapshots restore much faster if they do not include 5GB of source code

I’ve been working with AgentCore that uses the same MicroVMs. They are capable in many ways but for coding agents that load a big got repo they get bloated quickly with the git repo.

I’m building this google3 style mounting to address this.

https://github.com/mohsen1/git-lazy-mount

Still work in progress but for now I am seeing promising results

Confusion is: ultracode is not a different model with its own benchmarks

NYT's The Daily covered this a few days ago. Has a few interesting details about what went on...

https://www.nytimes.com/2026/06/04/podcasts/the-daily/trump-...

> Additionally, we’re introducing a new `ultra` mode that goes beyond the capabilities of a single agent by leveraging subagents to accelerate complex work.

I'm curious about how does this work? Do the subagents also get to use the same tools? Will the client be flooded with tool calls? Why extra pricing for a new "model" when the same thing can happen in the client with more controls?

And if it's an army of subagents, why do they compare it to Fable and Mythos? Those models with similar harness would probably bench better I'm guessing

Jokes on them, I just used Safari's summary feature. Even the title was enough for me to get the point.

Thanks! Two thoughts:

- if this port is happening on a single machine, you are better off with work trees. You can reuse worktrees if creating a new one is expensive. https://github.com/satococoa/git-worktreeinclude can help you initing work trees smooth

- If you want the system scale on the cloud with many many VMs doing work on the repo and repo is large enough that lazy-mount gives you meaningful perf benefits, yes definitely. It can be useful. Note that if the repo is private, you will need to configure sgrep's code search backend to be reachable from the microVMs

Link to the discussion that gave me the idea: https://news.ycombinator.com/item?id=48631726#48634278

I took a stab at this here https://github.com/mohsen1/git-lazy-mount

It seems to be feasible and useful. I'm still ironing out some details but I thought I share early

I'm really curious to see how this unfolds. It's a defining moment for us I think

Yes, in my project I made so much more progress in 3 days of Fable that is not comparable to how Opus is working.

The lazy mount is very interesting. This is similar to how google3 works at Google that I have not seen any similar implementation in open source so far.

Git sparse checkout is helpful but checking files out as they are needed is much more flexible and intuitive.

Microsoft VFS for Git / GVFS is the closest that I can think of.

There is room for this lazy mount idea to be built on top of Git

In practice it's much harder to maintain a native app. I am noticing this with ChatGPT Mac app vs. Codex Mac app. ChatGPT on Mac is constantly behind compared the web ChatGPT while Codex is shipping features at a much higher velocity.

Also ChatGPT hangs and has more weird bugs compared to Codex.

there was some attempts to make this happen back in the days. see text-kashida-space. if drop letters are something CSS can own, why not kashida?

It's 2026 and things like kashida in CSS is not possible. Long way to go to support the Arabic script properly on the web.

And as the article says, since most of the writing is happening on computers, stuff like kashida are going to be forgotten soon.

I personally think at some complexity level almost nobody who wrote the code can tell you what's going on. E.g. TypeScript's `checker.ts`

In the world of compilers there is a lot of wasted compute. In my project I'm also getting good results (for now on single files)

https://tsz.dev/benchmarks/micro

It's fascinating to read the comments here. The attitude is very strange to me. Writing software is not a sport that if you "cheat" using tools then your results are worthless. Results are speaking for themselves. Unless you can provide a failing test case that the software presented here fails at then your arguments for "how" it was made is moot.

Fully agentic coding is working well for projects like this since no matter how you write the code, the only way to truly know "it's working" is if it passes the test.

With the right skills you can make well designed software with agentic coding too. It's not as easy as a simple "convert this to rust" prompt, at least today.

This is the right take. I wouldn't dare to write a TypeScript compiler a year ago but now I'm trying it and I have to say this has taught me so much about compilers, Rust and performance overall that wouldn't be possible before. It's a lot of fun to embrace the new technology and do bigger things.

Doing this sort of project is giving me a glimpse of what it is going to be like managing software projects. As software engineers we have to learn how to manage much bigger changes and in a much higher level of abstraction. I personally don't think models are good enough for this level of automation yet but in a weekend that I had access to Fable I could see how things are going to change soon. Most of criticism towards LLM coding was not applicable to Fable. I'm not hyping anything, just an observation.

The DJ analogy is useful actually. I live in Berlin and essentially everyone is a DJ but only a few get to make money from it. The difference is of course taste but also grit and how well those people leverage available tools to them. A good DJ knows how to use the tools and has a good understanding of the market. Different skill that a musician but nevertheless a valuable skill

https://github.com/tsz-org/tsz

Codex with Browser Use (Codex 5.3 Spark) was able to solve this with a simple prompt

https://github.com/user-attachments/assets/0b80b07b-d88f-414...

I hate leetcode type questions. It's like "math Olympia" questions I had to deal with as a kid. Either you have seen the problem (or a variation of it) or there is no way of coming up with a solution under pressure.

Oh man, making a 7-segment display was my favorite question to ask frontend developers. Eventually turning it into a real clock if they were fast enough. Captures lots of basic CSS positioning, JS timers behavior and general ideas like breaking things into components etc

I'm making a TypeScript type checker in Rust.

tsz is my main side project. Trying to learn from this for how to make software in fully automated fashion. tsz's goal is to match tsc (tsgo) but perform better. I am not passing all tsc's own test cases and working towards making it work on complex type packages.

https://github.com/tsz-org/tsz

The army of AI agents opening PRs and issues in my open source projects has made me close PR and issue access in my active repos. It sucks because there might be someone wants to constitute legitimately but I don't want to do the labor of figuring out if it's a human or an agent opening the PR.

I'm not against using LLMs in any ways. https://tsz.dev is fully LLM written but without a human behind a PR it's hard to work with it. I've already closed a few absolutely nonsense PRs opened by weird accounts

If you think about it, a piano has all the possible songs in it too!

I mentioned elsewhere too. This was a one-shot thing that made me wow so I thought I share. You're kind with your comments but others are just hating it, even so I said 1. I don't know this motor technology and 2. It was a one shot experiment

If I had time and making a polished web page was my goal I could probably do better but this was not the point!