My lecture at MIT!✨ From Physics to Linear Algebra & Machine learning, I have learned a lot from MIT! Yesterday, I had the honour of delivering a guest lecture on The state of AI Engineering, exploring: - Prompt Engineering - Retrieval Augmented Generation. - Fine-Tuning Large Language Models. - And, how LLMs are bringing a paradigm shift Thank you @RoyShilkrot for the invitation! 🙏 Grateful for the opportunity to engage with such brilliant minds! If you are interested AI Engineering, I write a free weekly newsletter → @ML_Spring

How to build a 1-person AI company that: - Runs locally - 100% open-source - No human employees, all agents - Real-time collaboration via email Multi-agent orchestration is not new. Plenty of frameworks already let agents hand off tasks, run in parallel, and talk to each other. So the interesting question is not whether agents can collaborate. It is what structure you use to make them collaborate. The common approach is to wire a graph of nodes and edges and reason about the plumbing yourself. It works, but you are learning a new abstraction just to describe who does what. There is a coordination structure we have trusted for a hundred years already: an organization. Every company runs the same way. People have roles, roles have reporting lines, and work moves up and down that chart without anyone relaying each message by hand. Map that onto agents and the whole thing gets intuitive. You lay out an org chart, each agent fills one role, you talk to the person at the top, and the org sorts out the work between them. You already know how a company works, so you already know how to run one here. There is no new abstraction to learn. That is exactly what Alook does. Each agent is a live Claude Code or OpenCode session with a defined role, a reporting line, and its own email inbox. The agents coordinate over email, the same way a team would. And it all runs locally through a runtime on your own machine, so nothing leaves your setup. You bring your own agent too. Claude Code and Codex both work, and if you would rather stay fully open source and local, OpenCode works the same way. To show how this feels in practice, I set up three agents as a small sales team. Vi is the one I talk to. I hand Vi a goal, and Vi routes the work down the chart. Neile runs prospect research. Vi passes the target criteria, and Neile reports back a ranked list of names, roles, and companies, each with a suggested angle and a confidence score. Lliane runs outreach. Vi hands over the messaging angle and follow-up cadence, and Lliane reports back on emails sent, responses received, and any deal that needs escalation. I never relay a message between them. Neile and Lliane report to Vi, and Vi updates me in one place. The whole thing is open source and self-hosted, so it runs on your machine with your own agents. Give the repo a star if you want to follow where it goes: github.com/alookai/alook I also wrote a full walkthrough on building your own AI company with it, from a blank org chart to a running job. The article is quoted below. Cheers! :)

How to setup your Claude code project? TL;DR Most developers skip the setup and just start prompting. That's the mistake. A proper Claude Code project lives inside a .𝗰𝗹𝗮𝘂𝗱𝗲/ folder. Start with 𝗖𝗟𝗔𝗨𝗗𝗘.𝗺𝗱 as Claude's instruction manual. Split it into a 𝗿𝘂𝗹𝗲𝘀/ folder as it grows. Add 𝗰𝗼𝗺𝗺𝗮𝗻𝗱𝘀/ for repeatable workflows, 𝘀𝗸𝗶𝗹𝗹𝘀/ for context-triggered automation, and 𝗮𝗴𝗲𝗻𝘁𝘀/ for isolated subagents. Lock down permissions in 𝘀𝗲𝘁𝘁𝗶𝗻𝗴𝘀.𝗷𝘀𝗼𝗻. There are two .𝗰𝗹𝗮𝘂𝗱𝗲/ folders: one committed with your repo, one global at ~/.𝗰𝗹𝗮𝘂𝗱𝗲/ for personal preferences and auto-memory across projects. The .𝗰𝗹𝗮𝘂𝗱𝗲/ folder is infrastructure. Treat it like one. The article below is something I wrote three months ago, and it is still very much relevant. It is a complete guide to 𝗖𝗟𝗔𝗨𝗗𝗘.𝗺𝗱, custom commands, skills, agents, and permissions, along with how to set them up properly.

Don't train the model, evolve the harness. I read a brilliant blog post from Hugging Face where they took a frozen open model scoring 0% on a hard legal agent benchmark, left its weights alone, and let an automated loop rewrite only the code around it. That code layer is the harness, the runtime wrapper that feeds the model context, runs its tool calls, and decides when a run ends. By the time the loop finished, the system had essentially matched Sonnet 4.6 on the benchmark's headline metric, at roughly 7x lower cost per task. Zero weights changed. The gain existed because of where the model was failing. The judge only grades files saved in the right place under the exact requested filename, and the model kept doing the legal analysis correctly, then saving it under the wrong name, dropping it in a scratch folder, or never writing it at all. So the 0% was never measuring legal reasoning. It was measuring the harness. Hand-tuning that layer is slow and model-specific, so they automated it. A Claude proposer adds exactly one mechanism per iteration, and an outer loop keeps it only if it clearly beats the current best, so accepted mechanisms compound. What the loop discovered says a lot about where agents actually fail. → The biggest single gain was file handling, not intelligence. An automatic step that lands the deliverable exactly where the judge expects it beat every prompt change, with zero extra model tokens. → Code fixes transferred across models, prompt playbooks did not. The same harness lifted a smaller model from the same family by 14 points, but the tuned prompts hurt a different model family on tasks it could already finish. → The harness mattered more than anything else. Same model, same judge, same tasks, and five different harnesses scored anywhere between 3.5% and 80.1%. The gains do eventually flatten, and the remaining misses look like real capability gaps. At some point the wrapper runs out of tricks and the model has to carry the work. But the lesson holds. A benchmark score measures the model and its harness together, and until the harness is fixed, it's impossible to know which one failed. I highly recommend reading this: huggingface.co/spaces/joelni… I also wrote a deep dive on agent harness engineering a while back, covering the orchestration loop, tools, memory, context management, and everything that turns a stateless LLM into a capable agent. The article is quoted below.

RAG vs. Graph RAG vs. Agentic RAG, clearly explained! Standard RAG embeds documents into vectors and retrieves the most similar chunks via similarity search. For direct factual lookups, this works well. But it breaks down when a query needs to connect facts spread across multiple documents. Similarity search retrieves individual chunks, not the relationships between them. Graph RAG adds a knowledge graph layer on top. → During indexing, an LLM extracts entities and relationships from the documents. → During retrieval, the system traverses these connections instead of relying on embedding similarity alone. This is what enables multi-hop queries. Say a vector DB stores three facts about internal services: ↳ "The checkout service uses payments API." ↳ "The payments API runs on cluster-3." ↳ "Cluster-3 is scheduled for maintenance on Friday." Someone asks: "Will the checkout service be affected by Friday's maintenance?" Vector search can likely retrieve facts 1 and 3 because the query mentions "checkout service" and "Friday maintenance." But it will miss fact 2, which connects the payments API to cluster-3. That middle fact sits too far from the query in embedding space. It mentions neither "checkout" nor "maintenance," so it never makes it into the retrieved context. A knowledge graph connects these as linked entities, and graph traversal finds the full path in one query. Agentic RAG takes a different approach entirely. Instead of a fixed retrieval pipeline, an LLM agent decides at query time which tools to invoke, which sources to query, and in what order. Check the visual below to understand the three architectures thoroughly. One thing to note here is that these three aren't levels of sophistication that you need to graduate through. Instead, they solve different query types. ↳ Single-hop factual lookups → standard RAG ↳ Multi-hop relationship queries → Graph RAG ↳ Dynamic multi-source tasks with tool use → Agentic RAG ---- Each of these architectures gets better when the underlying retrieval layer is efficient. I recently wrote about a new RAG approach that cuts corpus size by 40x, reduces tokens per query by 3x, and improves vector search relevance by 2.3x. The article is quoted below.

Are We Ready For An Agent-Native Memory System? First, what does that even mean? It's memory built for an agent that keeps running, not a store you bolt on at the end. It has to hold facts across sessions, update them when they change, drop the stale ones, and hand back the right piece when the agent asks. A real data system, not a pile of saved chunks. A new study checked whether anything out there actually does this, and what decides the answer surprised me. It takes 12 agent memory systems and splits each into four stages, covering how memory is represented, extracted, retrieved, and maintained. Then it checks which stage decides whether the agent stays correct. Turns out it's write time, not query time. The systems that stay reliable under fact updates and cross-session reasoning are the ones that add structure as the memory is written. The graph-based methods lead right there. The flat stores fail the same way every time. An LLM pulls out entities and relationships with no schema, and the graph fills up with generic nodes that nothing downstream can filter. A few things follow from this. → Structure has to be set at extraction. Once the graph is built from untyped nodes, no query can recover a distinction the extractor never made. → Updates return stale facts. Append-only and freeform stores keep handing back old versions, which the paper calls hallucinations of the past. → A bigger model does not save it. Swapping the backbone moves the scores but rarely changes which pipeline wins, so the memory's behavior is set before generation runs. The paper also weighs the cost. The heavily structured systems pay for it, sometimes orders of magnitude more time per query, and the win only holds when the upkeep stays local instead of rewriting the whole store on every change. So the takeaway is less about picking a winner and more about where the structure lives. Decide it at write time, keep the maintenance cheap, and retrieval has something real to rank. Retrieval only ranks what extraction chose to keep. Link to the paper: arxiv.org/pdf/2606.24775 If you're into agent memory systems, I wrote a full article on exactly this. It walks through defining the schema as a Pydantic ontology in Zep, with custom entity and edge types, source and target constraints, and the extraction pipeline that turns raw conversations into typed, queryable memory. This memory system is 100% open-source: github.com/getzep/graphiti The article is quoted below.

If you use LLM-as-judge, this one is for you. (bookmark it) Most teams validate their agent's outputs by calling a frontier model as the judge. It works, until it doesn't. Three problems stack up fast: → Cost: you're hitting a frontier API on every turn, every tool call, every response. In production that burns millions. → Latency: bigger models, remote calls, slow reasoning on every check. → Blind spots: frontier models don't actually know your domain. In finance, insurance, or healthcare, they miss the keywords and principles your work depends on. So I walk through a different approach: train your own small LLM judge. Instead of a giant model, you start with a small one and let the system generate the training data for you. It decomposes your domain, samples synthetic examples, runs them through a debate arena where judges reach consensus, then trains on the refined set. The result is a judge that's cheaper, faster, and more accurate on your data than Gemini, Claude, or GPT, with an OpenAI-compatible endpoint you can even deploy on-prem. I show the whole thing end to end, using a Claude Code plugin and a web interface, with a real insurance RAG grounding evaluator as the example. You can get the plugin here: github.com/plurai-ai/plurai-… Here's the full breakdown: 00:00 - Intro 00:12 - Three problems with using frontier LLMs as judges 01:05 - A different approach: train your own small judge 01:31 - How it works (synthetic data and a debate arena) 02:50 - Installing the Claude Code plugin 04:03 - Defining your task with /eval 04:34 - Example: an insurance RAG grounding evaluator 05:51 - Kicking it off and giving early feedback 06:26 - Choosing labels, domain, and strictness 08:30 - The web interface and dashboard 09:52 - Bringing your own example data (optional) 10:26 - The finished model: endpoint, accuracy, and speed 11:16 - Control, on-prem deployment, and interpretability 11:57 - Benchmarks vs frontier models and the GitHub repo 12:30 - Outro I worked with the @pluraiAI team on this. Thanks for sponsoring the video.

The harness is what matters now. The model is just a commodity. A model on its own returns text. Nothing it produces becomes working code until something around it reads the repo, applies the edits, runs the tests, and reacts to what breaks. That something is the harness, and it decides how much of a model's ability actually ships. Cline ran a clean test of this. Same model, GLM 5.2, on the same set of coding tasks, driven two ways by their harness. - 57.3% with reasoning turned off. - 68.5% with reasoning turned on. The weights never changed. The only difference was how the harness drove the model. Reasoning budget is one knob. The harness also decides what context the model carries across steps, which tools it can reach, how edits get applied, and whether the work gets checked before it moves on. This is why the model is becoming the swappable part. The open ones are strong enough now, so what separates a good run from a wasted one is the environment they run inside. Cline is an open-source harness built for exactly this. The model is a slot you fill, and the loop around it stays the same whether you run GLM 5.2, Kimi K2.7, or DeepSeek V4. ClinePass is the clean version of that idea. One subscription to bring those open models into the harness, without assembling the stack yourself. A few things follow from the design. → It curates the field. The set is narrowed to open models tested for coding-agent use, so you skip finding out the hard way which ones hold up across long tasks. → It drops the provider sprawl. One subscription covers them, with no separate accounts, keys, or billing to track across labs. → It runs longer. The quota gives 2 to 5x the standard API rate limits, so long agent runs don't stall mid-task. → It stays open. Custom keys and local models keep working alongside it, so it adds an option instead of replacing what you have. The point is not which open model wins. It is that the harness that decides the outcome now, and the model is just the part you swap in. The video below shows the setup in action. I worked with the team to put it together.

Karpathy's Agentic Engineering finally has proper tooling! (built by Google) Karpathy defined agentic engineering as the discipline that separates production agent work from vibe coding. The core skills he listed were spec design, eval loops, and security oversight. The problem has been that practicing this still requires a different tool for every phase: - editor for code - a terminal for scaffolding - a browser for testing - a cloud console for deployment - and a separate framework for evals. Every transition is a context switch. The solution to production-grade Agentic Engineering is now actually implemented in Google’s Agents CLI. It covers the entire workflow in one place for scaffolding, evaluating, and deploying ADK agents. One setup command injects 7 ADK-specific skills into a coding agent's context, which lets it handle scaffolding, evals, deployment, and enterprise registration through natural language. I tested this end-to-end by building a RAG agent from scratch using Claude Code. It scaffolded the full project from the ADK agentic_rag template, generated 20 eval scenarios with LLM-as-judge scoring, and returned a quantitative scorecard. Finally, it also deployed everything to Agent Runtime and registered the agent to Gemini Enterprise, so the entire org can discover and use it. The video below shows this in action, and I worked with the Google Cloud team to put this together. Agents CLI GitHub repo → fandf.co/43Ys2m6 (don't forget to star it ⭐ ) I wrote up the full build covering all six steps from install to enterprise registration. It includes the eval scorecard, the instruction loophole the eval caught before deployment, and what the deployment process actually looks like end-to-end. Read it below.

Hermes Mixture of Agents (MoA) explained. Every agent commits to a single model, and every model has blind spots the others would have caught. The usual workaround is to run the same prompt through a few models by hand and reconcile the answers. It works, but it lives outside the agent, so the tools, the memory, and the session are gone the moment that detour starts. Hermes Agent by Nous Research just shipped Mixture of Agents, which folds that whole process back inside the agent. The unit you work with is a preset. Think of it as a recipe that names a few models to consult and one model to write the final answer, saved under a label you can reuse. So a preset might list GPT-5.5 and DeepSeek as the models to consult, with Opus as the one that replies. You set it up once, give it a name, and pick it later like any other model. The models you consult run first and quietly hand their analysis to the one writing the answer. That final model is the one that actually replies and makes the tool calls, now informed by several perspectives instead of one. Here is the part that makes it click. The preset shows up as a model, not as a framework to wire together. So everything that already works in Hermes keeps working. Tool calls, follow-up iterations, memory, and the same session context behave exactly as they do with a single model, because to the agent loop it is a single model. The models can come from anywhere. One preset can mix OpenAI, Anthropic, DeepSeek, and Google, and it is not capped at two. A few things follow from that design. → It composes a model instead of choosing one. Several models covering each other's blind spots can beat the strongest one on its own. → It stays cheap to run. The models you consult see a stripped-down view of the conversation, so the extra calls stay light and the main context keeps its cache. → It reaches past any single frontier model. Combining the providers already on hand assembles a composite that can outscore the best one available alone. → It is a dial, not a default. It turns on for the hard ten percent of tasks where a second opinion matters, and stays off for routine work where speed wins. Nous reports the effect on its own benchmark. A preset running Opus-4.8 over a GPT-5.5 reference scored higher than either model alone, by roughly six points and eight to eleven percent. The lesson is not that one model has to win. It is that the best answer rarely comes from a single model, and the agent should make blending them as easy as picking one. That said, if you're looking to set up Hermes, I wrote a full deep dive covering the Hermes agent's architecture, memory system, self-evolving skills, GEPA optimization, and how to set up multiple specialized agents. The article is quoted below. You can also watch my YouTube crash course on the Hermes agent: youtube.com/watch?v=bNp6YcKB…

The RL framework behind GLM-5.2 is fully open source. The full post-training of GLM-5.2 ran on it in about two days. The same stack sits behind the entire GLM series, from 4.5 to 5.1. It is called slime, and it is built around one idea. Keep a single RL kernel, and push all the variety into data generation. Let me explain what that means. Every RL run has two halves. One generates experience, where the model produces responses and something scores them. The other learns from it by updating weights. The learning half is mechanical. It reads samples, computes a loss, and steps the optimizer, the same way whether the model solves equations or drives a browser. What changes between tasks is generation. A math run answers in a single turn and grades the result. An agent run loops through tool calls, reads results, and only then earns a reward. slime draws the line right there. The learning half stays fixed as one kernel, and everything that differs becomes a new way to generate data. Under the hood, it wires Megatron for training to SGLang for rollout, with a Data Buffer between them that owns prompts, custom data, and generation. Most RL stacks grow into a pile of disconnected trainers, rollout services, and agent frameworks. slime refuses that. Multi-turn tool use, sandbox interaction, environment feedback, and verifier rewards all enter as data generation, not as forks of the loop. So an agentic workload runs on the same loop a math run uses, and the kernel never changes. A few things follow. → It is battle-tested. The loop is validated by shipping real GLM models, and it also supports Qwen3, DeepSeek V3, and Llama 3. → Correctness comes first. RL bugs are silent, so slime keeps the dataflow explicit and treats CI, reproducibility, and fault tolerance as real engineering. The proof is the ecosystem on top of it. Dressage, Miles, vime, Relax, OpenClaw-RL, P1, and TritonForge all build on slime without touching the core loop. The lesson is not that RL needs a bigger framework. It is that the variety belongs in data generation, and the training loop should stay small enough to trust. GitHub repo: github.com/THUDM/slime (don't forget to star 🌟) Since we're talking about RL, I wrote a full breakdown on fine-tuning LLMs with RL in 2026. Including how to skip manual reward engineering with automatic LLM-graded rewards. The article is quoted below.

Hermes /learn explained. agents usually learn the hard way. they struggle through a task live, fail a few times, find the path that works, and only then write down what they figured out. the lesson costs you a painful session before it becomes reusable. Hermes Agent by Nous Research just shipped /learn, and it removes that struggle from the front. point it at a source and it builds a skill before it has ever run the task. a local SDK directory, a docs URL, a workflow you just walked it through, or a procedure you paste in as plain notes. it reads the material, writes a 𝗦𝗞𝗜𝗟𝗟.𝗺𝗱, tests the skill live, and saves it. so /learn an internal REST client, tell it to focus on auth and pagination, and you get back a skill that covers exactly that, ready to invoke as a slash command. here is the part worth understanding. Hermes already created skills on its own. after a complex task or a recovery from a dead end, a background pass would quietly capture what it learned. that loop only fires on completed work, so it learns from trajectories the agent has already finished. /learn is the deliberate version. you invoke it, and it learns from material the agent has never touched. docs it has not read, a repo it has not run, someone else's runbook. the mechanism is the cleanest part. there is no separate ingestion engine. /learn builds a standards-guided prompt and hands it to the agent as a normal turn. the agent gathers the material with tools it already has, then authors the skill and saves it through the same skill tooling. because it is just a turn, it works everywhere the agent does. the CLI, the messaging gateways, the dashboard, with nothing new to deploy. the advantages stack up from there. → onboarding collapses to one command. a private API that meant re-reading the docs every session becomes a skill your whole team invokes. → a repo turns into a playbook. point /learn at a codebase and it captures the patterns and workflows, so the next session starts from how to work with it. → a one-time walkthrough becomes repeatable. deploy the staging server once, /learn it, and the procedure outlives the session. → the output is verifiable. every skill ships with a verification section and gets tested live before saving, so you get a draft that already ran. memory remembers facts. skills remember how to do the work. /learn is the front door to the second one, and it lets you fill that store on purpose instead of waiting for the agent to earn each entry the hard way. the best builders stopped re-teaching the agent the same procedure every session. they hand it the source once and keep the skill. That said, if you’re looking to set up Hermes, I wrote a full deep dive covering the Hermes agent’s architecture, memory system, self-evolving skills, GEPA optimization, and how to set up multiple specialized agents. The article is quoted below. You can also watch my YouTube crash course on the Hermes agent: youtube.com/watch?v=bNp6YcKB…

AI security goes far beyond AI. Adding an LLM call to a product puts security focus primarily on prompt filtering, output guardrails, and input validation. That is crucial, but it only covers the application layer, and an equally important infra layer needs its own controls. To understand this, trace a single model call. The prompt leaves the app, hits a provider endpoint, and depending on their retention policy, it sits in external logs for days. If that prompt carries any regulated/private data, it moves beyond the app's boundary. This isn't a failure of prompt filtering since it only governs what goes into the model, and it does not enforce where data can travel/who can store it. Beyond application-layer controls, two infrastructure-level concerns need their own coverage: 1) The first is per-request. Every model call moves data outside the app boundary. Who can access it in transit? Is it scoped to the right tenant? 2) The second is posture drift. Do providers retain the data, and for how long? Can one tenant's prompts reach another tenant's context through unintended disclosure? And do the AI outputs stay inside the compliance boundary that enterprise deals require? Teams typically solve both in the application code, where each new AI feature gets its: - own scoping logic - own encryption - own logging Ten features mean ten separate implementations of the same controls. Moving both to the infrastructure layer simplifies this. - If IAM policies control which services can call which endpoints, every new model call will inherit that boundary automatically. - VPC isolation keeps tenant traffic apart at the network level. - Encryption covers every data flow by default. Every API call, including model calls, gets logged without the feature code handling any of it. @awscloud builds this as the managed infra and they have partnered with me today to explain how it works. Model calls through Bedrock or SageMaker inherit the same IAM, VPC, encryption, and CloudTrail boundaries as every other service. For instance, IDEMIA runs this pattern in production. The company handles identity data for 45 US government agencies. After moving to containers on Amazon EKS in AWS GovCloud, they cut costs by 30% and sped up delivery by 4x, with the security coming from the infrastructure, not the application code. You can read more on how AWS supports ISVs building this way → fandf.co/4d23iNH Also, I wrote a detailed breakdown of the 11 components in a production agent harness, the full software layer that wraps an LLM. This post covers what sits underneath it. The harness is only as secure as the layer it runs on. Read it below.

Andrej Karpathy: "Remove yourself as the bottleneck. Maximize your leverage. Put in very few tokens, and a huge amount of stuff happens on your behalf." loop engineering is the exact thing that gets you there. in a hand-run session you do two things. you decide what the agent runs next, and you check its output before the next step. both are manual, and both are the ceiling on how far the agent gets without you. loop engineering moves both steps into the system. the diagram below shows the operating structure that surrounds the loop: → a trigger decides what to run, whether that's a message, an event, or a schedule, so the agent starts without you there to kick it off. → the loop is the maker that produces the work, thinking, acting, and observing until it's done or the brakes stop it. → a separate checker grades the output, because a model grading its own work justifies what it already did instead of catching where it failed. the checker's findings return to the maker as the next instruction, and the cycle repeats until nothing is left to fix. → state lives on disk, not in context, since the model forgets everything between runs. an MD file or a knowledge graph holds what's done and what's still open, so a loop can pick up again days later. for that state layer, Zep's Graphiti is a clean open-source option, a temporal knowledge graph that invalidates stale facts and returns context through vector, full-text, and graph search in one call. repo: github.com/getzep/graphiti two things decide whether an unattended loop holds up. the exit has to be set before the loop runs, not while it's running. a loop with no stop condition burns tokens, and the cost climbs fast once sub-agents and long runs stack up. a clean exit reads like "all tests pass and lint is clean, stop after two passes." and the checker only catches failures inside a run. the harness around the loop, the prompts, tools, and checks wrapped around the model, still drifts and breaks in production as models change. catching that needs observability on every run, not a green checkmark. Comet's Opik is built for that layer, an open-source tool that traces every call and turns a failing production trace into a regression test so the same break can't recur. repo: github.com/comet-ml/opik your job stops being the hands inside the loop. it becomes designing the machine that runs without you, then watching the traces closely enough to trust it. the model is becoming a commodity. the loop around it is where the real engineering lives now. I wrote the full breakdown. the article is quoted below. stay tuned for more on this!

the four pillars of loop engineering. the loop itself is six lines, and nobody competes on it. every serious agent framework lands on the same tiny while-loop. model reads context, calls a tool, you feed the result back, repeat until it stops asking. so if that part is solved, what is everyone actually engineering? the answer is everything around the model. Boris Cherny, who built Claude Code, put it plainly. he doesn't prompt Claude anymore, he writes loops and lets them run. that shift has a name now, and it rests on four pillars that are harder than the six lines make them look. these are the parts that actually break: → knowing when to stop. a terminal message ends the turn, not the task. an agent will write failing code, glance around, and declare victory. "done" has to mean the tests pass, not the agent feeling good about its work. → keeping the context clean. long loops rot from the inside as old outputs and dead ends pile up. a worse context produces a worse decision, which adds more noise, and the agent gets dumber the longer it runs. you fight it by treating context as a budget, not a bucket. → tools the agent can actually use. pile on a hundred tools and it loses track of which one to reach for. writes have to be safe to repeat, because loops retry, and a retried "create customer" call leaves you with duplicate records. → something that can say no. left alone, an agent agrees with itself. the fix is to separate the maker from the checker so the worker never grades its own homework. put those four together and your job changes. you stop steering the agent move by move and start designing the system that steers it. Karpathy runs research loops overnight that tweak a script, test it, keep what works, and throw away what doesn't, with himself nowhere in the loop. he arranges it once and hits go. the model is becoming a commodity. the loop around it is where the real engineering lives now. the best builders stopped asking what they should tell the agent to do. they started asking what system would do this without them. I wrote the full breakdown. the article is quoted below. stay tuned for more on this!

Karpathy said something you'll regret ignoring: "We have to keep the AI on the leash. I'm still the bottleneck. I have to make sure this thing isn't introducing bugs and that there's no security issues." He said it at YC talk last year, when the worry was reliability. The models hallucinated and made mistakes no human would, so the leash implied keeping yourself in the loop and checking the output before trusting it. The models are far better now, and the line still holds, for a reason he was not focused on back then. Even a model that writes flawless code today still has no idea who is allowed to run it. Correctness and authorization are different problems, and only correctness improves as the model improves. A perfect agent still hands a tool where anyone can do anything, because permission was never part of the task. I actually tested this in practice with Claude Code. I asked it to build a small internal tool with a button that issues account credits. It worked first try, and running it locally, the credit applied the instant I clicked. Nothing decided who was allowed to click it. The agent wrote the right logic and displayed a success notification. It never checked whether the caller had the right, whether it should pause for a human, or whether anything was logged. And this is not a bug a smarter model can outgrow because the leash was never in the code. Identity, permissions, and audit live in the system that runs the app, not in what the agent generates. To solve this, I took the exact same bundle and hosted it on @retool. The credit write that fired silently on my laptop now stopped at an approval gate, resolved to a real identity through SSO, and landed in an audit log. I wrote none of it. The app inherited the entire boundary the moment it was deployed, and the video shows the before and after. You can try it yourself here: fandf.co/4ofoO72 I also wrote a detailed breakdown of the whole thing in my recent article, and I worked with the team to put this together. It walks through the build, the exact moment the credit write went through on my laptop with nobody checking, and then what changed when the same app ran on Retool. It also covers why this is a property of the runtime and not something a better model fixes, which is why devs typically miss this. The article is quoted below.

Turn any paper into running code. Just swap arxiv → autoarxiv in the paper url. That hands the paper to an AI agent from alphaXiv. It reads the abstract, the claims, and the linked GitHub repo, then clones the codebase and works through the usual setup pain like dependencies, broken paths, environment config, and hardware assumptions. From there it designs a minimal reproduction. That means a smaller model, fewer steps, and a single GPU instead of a cluster, scaled down just enough to test whether the headline claim holds. The whole run is live and fully logged. Loss curves, metrics, and training progress are all observable as it happens. What comes back is a clean signal on whether the minimal run matches the paper's reported result, plus an estimate of what a full replication would cost in compute and time. A lot of research code dies in setup before anyone verifies a single number. This moves reproduction from a weekend of debugging to a url change. Pick a paper and try it now. video credits: @askalphaxiv