A decent nvme ssd can read ~35GB of data in 5 seconds for reference.
Or you can download 66MB of data on a 100mbit/s internet connection in 5 seconds.
Say you need to load 1gb from disk and need to download 1MB of data from internet. It should take ~75 milliseconds to do that.
It is incredibly slow, considering Valve is a billion dollar company. This level of optimization is closer to what you would expect from a person who is programming as a hobby.
Yes, exactly why I'm making that (potentially harsh) statement.
It really shouldn't take much more than that, most of what you see there is already pre-loaded on disk (I'd hope) like your most recent plays etc, much of it can be cached and rendered directly from that cache, even progressive loading of store images should make it a very, very tiny download from the web.
They can fill random document as well, it’s their expertise which template to use that fills your scenario and additionally once it gets to subtle nuances, you don’t want to do those yourself either.
I don’t think it’s about telling agent what to do with skills for most part anymore as well.
Problem is not having to remember to run agents in exact sequence and not having to repeat the processes.
That’s why I’ve created ctx traits and using them everyday, biggest wins for me are: sync across repos using git-based dependency manager and validator, which ensures version of the process / knowledge I’m using has been approved by me and hasn’t moved without my approval (similar to dependency managers lockfile approach).
This has allowed me to use same traits (it’s extension of skills with typed schemas and procedures, you can use skills with it as well as usual) across different repos without any copy pasting etc.
There are additional cool things like type-driven procedures with specific harness/agent associations and many more cool things coming soon.
I believe that “it’s about the harness” captures an important idea, but I also think it’s helpful to consider the harness and the procedure separately.
The harness provides the model with its tools, context, and environment for execution.
However, I prefer not to have the model within that harness also bear the responsibility for remembering the process steps—like plan, implement, review, fix, and verify—deciding when to move from one to the next, and keeping track of the loop's state.
For tasks that need to be repeated, I’ve been moving that part into a reliable, deterministic runtime. Inside it, Claude, Codex etc simply take on interchangeable roles.
This setup makes changing models much simpler: the overall process remains consistent, and each role can be optimized independently.
Truly something to be proud of..
reply