I wanted to check whether a skill actually did its job. The skill ran a goal prompt through OpenCode, called a handful of tools, and left a session behind. Then I read the final message, and the final message told me exactly what I wanted to hear. That is the problem with grading an agent from its output alone. The reply is the last thing that happened, not the thing you were measuring. ...
Also available on Archit’s Newsletter on Substack. You ask a coding agent to fix a failing test. Somewhere, a model generates tokens. But tokens do not open files, decide which shell command is permitted, preserve a session after a crash, or establish that the test now passes. The execution system has to make those things happen. That system is the harness. Its decisions determine how reasoning becomes action, what the model sees next, and which failures remain recoverable. To understand an agent’s reliability, we need to follow those boundaries in code. ...
I want my public writing to make it easier for people to understand the engineering work I care about: AI agents, security, and reliable systems. That means explaining decisions, showing what broke, and leaving enough evidence for someone else to check the result. The difficult part is producing something worth explaining. A publishing system should make room for that work. This is the approach I want to build around my website, GitHub, LinkedIn, and Substack. It starts with a technical question and ends with something another engineer can use. Automation helps with the work between those points. Publication remains my decision. ...
As of October 18, 2026, the core idea has been built by multiple research groups, including Microsoft, Google and independent open-source developers. Some systems already do almost exactly what you described: take a Kaggle-style ML problem, generate modeling approaches, train models, evaluate performance, improve their code through repeated experiments and produce solutions. The opportunity isn’t inventing this category. It’s finding where the existing systems remain inefficient, unreliable, expensive or difficult to operate. ...
Designed for an Indian household in Bengaluru · Married · Age 30 · Software engineer · October 2026 The goal is to automate the repetitive coordination in your life with a small, durable layer of infrastructure — without turning personal productivity into another engineering project. You don’t need 30 agents, 30 MCP servers or a custom application for every problem. You need one command interface, a few reliable integrations, a memory system, recurring workflows and strict security boundaries. ...
The browser looks like the safest place on a computer because it looks like a window. A tab is a page. A page is an app. The operating system is somewhere underneath, doing serious things with files and processes while the browser shows us email, a spreadsheet, and a shopping cart. That picture is old enough to be dangerous. I do not mean that a website has become macOS or Linux. A site cannot schedule arbitrary processes, read your disk, or open a socket whenever it wants. The web has spent decades putting useful friction between a page and the machine. The point is narrower, and worse: the browser has become the layer through which we hand out much of the authority that used to sit clearly in the operating system. ...
Self-Improving AI Agents: A Recursive Taxonomy An agent that gets better on its own isn’t one idea. It’s at least six, and they differ by how much of the agent is allowed to change. This post sorts the 2023 to 2026 work into six families, names 109 methods across them, and ranks them all. It’s the map. Two questions separate every method here. What does the agent change about itself? Its prompt, its stored experience, its tools, its own design, its source code, or the world it trains in. ...
Most writing about the technical leadership path is noise shaped like signal: clickbait ladders, ten-point checklists, motivational platitudes sold as frameworks. This post is the opposite. It distills the field’s harder-won lessons into one working model for the stretch from Senior Software Engineer to Tech Lead to Staff or Principal, with no fluff and no name-dropping. It answers one question: what actually changes as you move up the technical track, and what do you do differently on Monday? ...
Most AI PR bots do the same thing. They read a diff, emit soft prose, and vanish. No memory of the last review on that repo. No package you can open later and see which tools the model ran. No honest score when the code is wrong. I built Luffy for the opposite job: a comment-triggered review control plane. You type @luffy review this pr. GitHub Actions runs Hermes Agent through OpenRouter. The agent can shell into the workspace, repro failures, and post a structured Markdown review. Then it stores a redacted trace and grows hub memory so the next run on that repo is not starting from zero. ...
Memori: The Recursive Design of Agent Memory Memori is not primarily a database for notes. It is an attempt to turn agent memory into an engineered retrieval system. The thesis is simple. An agent fails across sessions because state is lost. Lost state only matters if previously learned information cannot be recovered when needed. So “memory” is really three problems: Capture useful state. Preserve it cheaply and portably. Retrieve the right item at the right moment. Everything in the code follows from that split. This post is about the concepts underneath the system – what each design decision reduces to, and why the project is recursive at its core. ...