Welcome to my Digital Home

I have a complicated relationship with project management tools. I need them — no team ships anything of size without one — but most of them have a way of quietly becoming the work instead of tracking it. You start with a simple board and six months later you're maintaining custom fields, automation rules, and three kinds of "status" that nobody fully understands. So when I came across Kaneo, an open-source project management tool whose entire pitch is "all you need, nothing you don't," it earned a closer look.

Here's my honest take on what Kaneo is, what it does well, and where it falls short.

Most of the "agentic AI" I've shipped so far has one uncomfortable dependency baked in: a network call to somebody else's cloud. Every tool call, every reasoning step, every retry — all of it round-trips to an API. So when Meta dropped Muse Glimmer this week, a 30-billion-parameter agentic model that runs locally on a single GPU under an Apache 2.0 license, it caught my attention for reasons that have nothing to do with benchmark charts.

Let me walk through what it is, how they pulled it off, and where I think it actually fits.

Every dApp I've ever worked on eventually hits the same wall: reading data back out of the blockchain. Writing to a contract is the easy, glamorous part. Then someone asks for a page that shows "all the user's past transactions, sorted by date, with token metadata," and you remember that the chain is a terrible database. You can't just SELECT * FROM transfers. You have to index — replay events, shape them into tables, and keep them in sync as new blocks arrive. For years the default answer to that was a subgraph on The Graph. Ponder is a bet that there's a much nicer way to do it, and after spending time with it, I think the bet mostly pays off.

If you use AI coding agents on a real repo, you've probably noticed they keep making the same avoidable mistakes — running the wrong test command, touching files they shouldn't, inventing a table name that doesn't exist. AGENTS.md is the fix, and it's quietly becoming a cross-tool standard. But there's a catch most people miss: a lazily written AGENTS.md can actually make your agent worse. So it's worth doing properly.

Here's a frustration anyone who works with AI agents knows well: every conversation starts from zero. The model doesn't remember how your team does code review, what your design system rules are, or the workflow you painstakingly explained yesterday. And the usual fix — stuffing all of that into one giant system prompt — makes things worse as it grows, because a bloated prompt dilutes the model's attention. SKILL.md is a genuinely clever answer to this, and I think it's one of the more important ideas in agent tooling right now.

A post by Günter Richter got me thinking: everyone's rushing to vibe code, but almost nobody talks about the skills that decide whether you succeed or just generate an expensive mess. He's right that the tools don't replace fundamentals — they raise the stakes on them. So here's my own version: the three skills I'd want anyone to have before they let an AI write their software.

Most AI coding tools still assume you're sitting in the driver's seat, hands on the keyboard, with the AI whispering suggestions. Google Antigravity starts from a different premise: what if the AI is the one doing the work, and your job is to direct and verify it? It's an agentic development platform, and the framing — the editor as mission control rather than a text buffer — is the interesting part.

The "which AI coding agent is best" debate never really ends, and honestly it shouldn't — the answer depends far too much on how you work. I've spent time with all three of the big ones lately: Anthropic's Claude Code, OpenAI's Codex, and Google's Gemini Code Assist. Rather than pretend one wins outright, here's how I actually think about the trade-offs.

Every week there's a new tool promising to turn a sentence into a working app. I've lost count. The problem with most "best vibe coding tools" lists is that they rank everything against each other as if they're the same product — they're not. A tool built for a non-technical founder shipping an MVP is solving a completely different problem than one built for an engineer refactoring a 50k-line codebase.

So instead of a leaderboard, here's how I'd actually choose, grouped by what you're trying to do.

I rolled my eyes the first time I heard the phrase "vibe coding." It sounded like something invented to sell a course. Then I actually spent a few weekends doing it — describing what I wanted in plain English, letting an LLM write the code, running it, fixing what broke — and I had to admit the eye-roll was premature. There's something real here. There's also a trap, and most of the hype skips right over it.

So here's my honest take, from someone who ships backend and blockchain code for a living.