Vilson Vieira

I'm starting something new! 🚀 I've been using and creating AI agents and tools to generate code daily in the last months, and meeting other coders and non-coders doing the same. I'm putting together everything I've been learning in an AI Code Guide.

@mitsuhiko Same here

I understand it, but it makes me sad. I really like Opus in pi, but paying for API token prices is just not a reasonable option today. x.com/bcherny/status…

Mac Mini + eGPU. Both NVIDIA and AMD supported.

@thorstenball Ah I have that too, specially with cables, braided ones, everything usb-c... and the weird thing: at same time I just hate seeing cables everywhere, so I do my best to have just one cable getting out of my laptop to the usb-c monitor to power+data, use bt, etc 😅

I guess my unconscious self came here and got what it wanted

One vice I have that I can't even explain to myself: I love good cables, power adapters, and could (and have!) essentially buy new Anker stuff every two weeks. Something in me tells me that I need this. Look at that display. That knob. I don't need it, it's expensive, ... BUT.

@jpschroeder Great take! So, in summary: memory is still a major bottleneck for LLMs and bash is king, like we already know; always running agents is still hot 😃

Important takeaways from Claude’s source code: 1. Much of Claude Code’s system prompting is in the source code. This is actually surprising. Prompts are important IP, and I would have thought a sophisticated organization like Anthropic would have performed much or all of their prompt assembly in the server-side harness. 2. Claude Code uses axios, which was also just hacked. Reminder: supply chain attacks are part of closed-source distribution too, and you won’t even know what version of an affected package is being used. 3. The source has a lot of really good comments. These are obviously not for human consumption but for LLMs to understand the purpose of various chunks of code. In the code autocomplete era, most of us engineers hated how many comments were left by LLMs, but perhaps we’ve overcorrected. This looks like a great way to provide context to code outside of the AGENTS.md/CLAUDE.md files. 4. Most folks already know this, but less tools == better results. CC has < 20 tools in normal coding: AgentTool, BashTool, FileReadTool, FileEditTool, FileWriteTool, NotebookEditTool, WebFetchTool, WebSearchTool, TodoWriteTool, TaskStopTool, TaskOutputTool, AskUserQuestionTool, SkillTool, EnterPlanModeTool, ExitPlanModeV2Tool, SendMessageTool, BriefTool, ListMcpResourcesTool, and ReadMcpResourceTool. 5. The “Bash” tool is the crown jewel of Claude Code. A significant amount of deterministic parsing and processing occurs to determine the “type” of commands being run. 6. For better or worse, Claude Code is *all* TypeScript/React with rather explicit Bun bindings. 7. Just because the source is now “available” *DOES NOT MEAN IT IS OPEN SOURCE*. You are violating a license if you copy or redistribute the source code, or use their prompts in your next project! Don’t do that! My overall takeaway: it’s a really well laid-out codebase that is carefully organized to let agents work on it effectively. Direct human intervention here is minimal, but, like with all good projects, the human engineering is still apparent. I’m a bit surprised by some of the shortcuts Claude Code makes, like its prompt assembly being rather messy. Perhaps they have tooling on their side that helps with this introspection, but as it stands, it seems LLMs would struggle to iterate on the prompting because it’s not evident how a given set of parameters assembles a prompt without actually running it. It’s also surprising that the prompts are even in this source code. Keep in mind that even though this is the first time we’ve gotten a proper full-source dump, it has never been impossible to read Claude Code’s prompting since it was part of the actual distributed package — that’s surprising. There might still be a lot of prompting on the server that also gets added (unclear at this point), but there is certainly more than I would have expected in the CLI tool itself.

3D particle life running on browser using WebGPU/WGSL - najarro.science/pl

@davidcrawshaw Agreed! Give people a good agentic coding environment and grown/learn with them. That’s why I opened suuper.dev already on its pretty primitive state, so people can build using whatever tools and workflows I use myself.

No-one has figured out how an eng team should work with agents yet. Be wary of anyone telling you they know how to do it. Keep exploring. blog.exe.dev/bones-of-the-s…

This will be interesting! Break a leg!

@badlogicgames I would contribute mine traces, I believe it’s also a great way to learn prompting and coding best practices!

we as software engineers are becoming beholden to a handful of well funded corportations. while they are our "friends" now, that may change due to incentives. i'm very uncomfortable with that. i believe we need to band together as a community and create a public, free to use repository of real-world (coding) agent sessions/traces. I want small labs, startups, and tinkerers to have access to the same data the big folks currently gobble up from all of us. So we, as a community, can do what e.g. Cursor does below, and take back a little bit of control again. Who's with me? cursor.com/blog/real-time…

@giffmana I really love the era we’re in. That will take so many weekends a few months ago. Last time I tried to do CUDA in pure C it was really painful. Can’t wait to check it once you release!

I just achieved the holy grail as a weekend project! Wrote a multimodal training codebase in pure C and CUDA+NCCL with minimal dependencies (no torch!) that achieves 45 MFU with FSDP on four 8xH100 nodes. I might feel cute and open-source it later. Screenshot for proof:

Agreed! The world will be more and more made of software. We’ll need *much* more coders, not less. The bar will be much higher though, so we need to learn and educate how to create and use existing AI tools to avoid slop and output really good pieces of software.

Tmux is awesome! I just rescaled my remote dev server for more vcpu/mem/storage, restarted it, reconnected, ran tmux a and I got all my windows, panes, vi, etc, exactly the way I left. Thanks to the magic of github.com/tmux-plugins/t… and github.com/tmux-plugins/t…

Wait wait, so you guys can generate images 4x faster and costing $0.001 per image?! And I just noticed MAX supports Kimi K2.5 now?! OK I really need to go back to Mojo land! I was experimenting with building a coding agent in Mojo a few days ago and I think it’s possible…

Updated a bit the aicode.guide. There are lots of good references and guidelines to add still, which I'll be doing more frequently now, but at least it's more aligned with today's state of affairs.

Kimi K2.5 can run in 8xH100 GPUs, self-hosted in providers like @spheron and costing $16/h, which is totally worth it if you have constant workload. Looks like a match made in heaven for multi-agent code factories generating code 24/7.

Bash is all you need.

@rauchg Agreed! That’s why I’m building hackable.space

Not knowing how to code giving you an advantage is absolute nonsense. The more you understand, the better your prompts, the better the feedback you give, the better product you ship. What will change is that the intricacies of syntax, compilers, module systems, the finer details of type systems, won’t matter as much to everyone. But you should absolutely understand how the pieces fit together. From syscall to pixels. Learn how data flows, because you’ll be able to secure your systems. Learn about performance, because you’ll be able to push your agent further. Learn about APIs, because they determine how to integrate systems. Learn about how systems fail, because you’ll be able to make reliable programs.

Crazy that now, instead of "here are the instructions to install this app" we have "give this spec.md to your agent and let it build it in your favourite language": #option-1-make-your-own" target="_blank" rel="nofollow noopener">github.com/openai/symphon…

@swyx @karpathy Exactly my question as well!

@karpathy (sorry if i missed this) is the agent handrolled? a Pi fork?something else? ive been digging into the "future of git for agents". think this metasetup (where code gets discarded often bc its cheap) is something like what we may want (but yours still looks far too git based)

nanochat now trains GPT-2 capability model in just 2 hours on a single 8XH100 node (down from ~3 hours 1 month ago). Getting a lot closer to ~interactive! A bunch of tuning and features (fp8) went in but the biggest difference was a switch of the dataset from FineWeb-edu to NVIDIA ClimbMix (nice work NVIDIA!). I had tried Olmo, FineWeb, DCLM which all led to regressions, ClimbMix worked really well out of the box (to the point that I am slightly suspicious about about goodharting, though reading the paper it seems ~ok). In other news, after trying a few approaches for how to set things up, I now have AI Agents iterating on nanochat automatically, so I'll just leave this running for a while, go relax a bit and enjoy the feeling of post-agi :). Visualized here as an example: 110 changes made over the last ~12 hours, bringing the validation loss so far from 0.862415 down to 0.858039 for a d12 model, at no cost to wall clock time. The agent works on a feature branch, tries out ideas, merges them when they work and iterates. Amusingly, over the last ~2 weeks I almost feel like I've iterated more on the "meta-setup" where I optimize and tune the agent flows even more than the nanochat repo directly.

I feel that we're more and more replacing RTFM with ATFL [1] Ask The F* LLM