over the last month or so i’ve been digging into how coding agent harnesses actually work. looking at tools like claude code, codex, opencode, and especially pi from @badlogicgames, it’s been interesting to peel back the layers and see the patterns underneath them 👀 i learnt a lot in particular from looking at how pi has been architected. as a result, i ended up building my own coding agent harness in python and documenting the rings that build around a minimal agent loop to create the kinds of systems we’re starting to see more of: - providers - tools permissions - sessions state - context strategy compaction - prompts skills - plugins extensions - delivery the post walks through those layers piece by piece, along with the accompanying code and diagrams. if you’re curious about how these systems are structured under the hood, hopefully this is useful. post: eddmann.com/posts/around-the… code: github.com/eddmann/my-own-co…

Anthropic onboarding day: Michael Scott introducing Karpathy like he just signed Wemby in free agency.

have really enjoyed using this tool recently! initial analysis and breakdown of semantic features within a system to then go on and review in parallel is very useful. thanks @steipete

I setup MCP server for Garmin so I asked Claude to analyze my bike training and give me recommendations It did and suggested 5 workouts I can start doing It then created them in my account Super cool Thanks for the MCP @edd_mann 👏

we've been increasingly using agents for production operations on Deno Deploy Open sourcing what we built to sleep easier while these things run 24/7 I wrote about our motivation here deno.com/blog/clawpatrol

been spending some time going through PRs across my OSS projects recently. just released garmin connect mcp server v1.0.1 🎉 it’s now published on PyPI, so you can run it directly with: uvx garmin-connect-mcp repo: github.com/eddmann/garmin-co… #opensource #mcp #claudeai #garmin #python

Cloudflare's security team spent the last few weeks testing Anthropic's Mythos against fifty of our own repositories. What we learned about offensive AI, why faster patching is the wrong reaction, and what the architecture around vulnerabilities has to look like next. cfl.re/49BRUqW

love the new pi website design! @badlogicgames @mitsuhiko 🖌️🎨

my new favourite thing recently has been exploring codebases through mermaid diagrams. being able to generate up-to-date architectural overviews - then zoom into the specific parts of the system i care about at that moment - has been incredibly useful 👌

it's too easy to get distracted, i've been using @jsonresume as the source for multiple themes of my cv, letting the frontend design skill run wild! haha

til about `await using` in ts for auto. async cleanup thanks to @mattpocockuk’s sandcastle project 🙏 developer.mozilla.org/en-US/…

for your enjoyment: github.com/badlogic/gpt-2-ts GPT-2's architecture is really really simple to understand mechanically. Modern arch's are obviously more complex, but the basic principles are largely the same still. study it! openai.com/index/better-lang…

you can outsource your thinking but you cannot outsource your understanding

you can outsource your thinking, but you can’t outsource your understanding

codex casually whipping out perl. every tool in the belt.

highly recommend this 2-part lisp, scheme, racket history overview: youtu.be/dxBIB17mz-M youtu.be/nU8tYF1Uqbc

since watching the clojure doc i’ve been thinking a lot about lisp again, going back and reading the orig. mccarthy paper and grahams roots of lisp - i’ve been having fun building out a minimal impl based on this work in wasm wat, s-expressions all the way! 🤘

llama.cpp at 100k stars now that 90% of the code worldwide is being written by AI agents, I predict that within 3-6 months, 90% of all AI agents will be running locally with llama.cpp 😄 Jokes aside, I am going to use this small milestone as an opportunity to reflect a bit on the project and the state of AI from the perspective of local applications. There is a lot to say and discuss and yet it feels less and less important to try to make a point. Opinions about viability of local LLMs are strongly polarized, details are overlooked, the scientific approach is lacking. Arguments are predominantly based on vibes and hype waves. One thing is clear though - local LLMs are used more and more. I expect this trend to continue and likely 2026 will end up being one of the most important years for the local AI movement. I admit that I didn't expect the agentic era to come so quickly to the local LLM space. One year ago, the available models were too computationally expensive for doing long-context tasks. There wasn't an obvious path towards meaningful agentic applications. The memory and compute requirements were huge. Last summer, with the release of gpt-oss, things started to change. It was the first time we saw a glimpse of tool calling that actually works well within the resource constraints of our daily devices. Later in the year, even better models were released and by now, useful local agentic workflows are a reality. Comparing local vs hosted capabilities at a given moment of time is pointless. To try put things into perspective: - We don't need frontier intelligence to automate searches and sending emails - We don't need trillion parameter models to be able to summarize articles or technical documents - We don't need massive GPU data centers to control our home appliances or turn the lights off in the garage I believe that there is a certain level of intelligence we as humans can comprehend and meaningfully utilize to improve our working process. Beyond that level, access to more intelligence becomes unnecessary at best and counterproductive at worst. I also believe that that level of useful artificial intelligence is completely within reach locally and it has always been just a matter of implementing the right software stack to bring it to the end user. With llama.cpp, I am confident that we continue to be on the right track of building that software stack! The llama.cpp project is going stronger than ever. With more than 1500 contributors, the project keeps growing steadily. From technical point of view, I think that llama.cpp ggml is the only solution that actually makes sense. That is, the software stack must run efficiently on every possible device, hardware and operating system. The technology is too important to be vendor-locked. It has to be developed in the open, by the community, together with the independent hardware vendors. This is the only right way to build something that will truly make a difference in the long run. I won't try to convince you about what is currently and will be possible with local AI. We will just continue to build as usual. I am confident that after the smoke clears and we look objectively at what we have built together, the benefits will be obvious to everyone. Big shoutout to all llama.cpp maintainers. I feel extremely lucky to be able to work together with so many talented contributors. Every day I learn something new and I feel there is so much more cool stuff that we are going to build. Also, I am really thankful that the project continues to have reliable partners to support it! Cheers!

rewrote VoiceScribe to use tca/swiftui, now focusing soley on local transcription/llm cleanup. it now provides local whisper and parakeet (thanks to @fluidinference, coreml) transcription, coupled with optional local llm cleanup (mlx). there are a lot of wrappers around these great transcription models, but i wanted to learn how to package and distribute local model inference for this use-case myself. it's been a lot of fun. eddmann.com/VoiceScribe/ github.com/eddmann/VoiceScri…

recommended reading.