Surprised you saw that 😅 I’d been following along with some of your exploration and did some prototyping with @filae.site (my stateful agent). It runs autonomously every few hours and decided to explore further and created this along with a few other prototypes.
I’ve long struggled to understand why I’ve felt agents “just work” while others don’t. My working thesis is I only make a few contributions (prompts, corrections, or tests) but without the experience of being an engineer, you’d have no idea these were needed to get the result you want.
I realized this was silly. Adding hook instrumentation allows me to see the tools in thread in the message client without requiring the agent to invoke the tool to send messages. It's a little noisy but solves the problem in the spot I care about it
For my stateful agent, I run a private, real-time dashboard on top of a Cloudflare durable object. This allows me to monitor tool calls and progress without needing the agent to constantly send messages to my chat client. These events are read and published directly from logs.
My stateful agent has been deploying websites and apps it builds during its autonomous work blocks. Before this, it posted interactive pages to its blog. Before that, it wrote posts and before that, scripts and simulations on its VM. Usually, I need to show it the way before an architectural leap.
The URL shows who built it and whose data you're viewing:
/@user.xyz/linkblog/@danielcorin.com/web
App code from @user.xyz. Webview of data from @danielcorin.com, stored as ATProto records.
The viewer handles OAuth, token refresh, rendering. The bundle just calls window.atproto.createRecord().
I’m experimenting with building, persisting, and running code itself from ATProto. Most apps use ATProto to store content for the app. This approach treats the code as content. The app can be loaded using a viewer that anyone can implement, login with Bluesky, storing data as ATProto records.
Experimenting with a stateful agent has opened the door for a new form of software development that occurs entirely from my phone. The agent has dedicated GitHub and Cloudflare accounts and deploys cross-platform, personal apps that store data to my iCloud www.danielcorin.com/posts/2026/p...
A one turn conversation between a user and the language model gpt-4o-mini with a system prompt. The system prompt asks the model to respond to the user as an experience software engineer. The user prompts the model to explain a Hugo shortcode. The model outputs an explanation.
A one turn conversation between a user and the language model llama3.2. The user prompted for Python code and the LLM outputted the code. The UI shows the code with syntax highlighting.
A conversation between a user and the language model gemma3. The model is outputting short, valid programs in Python and Swift. The UI shows minimal rendering of the markdown output from the model. The window hovers above other windows in the background.
Maybe it's just me but I really enjoy making chat components to narrate language model conversation for my blog posts and in general. This has been one of the deepest forays into design that I've taken, trying to get these to look just how I had in mind.
Throwback to typing out every character of my code. It was a simpler time ampcode.com/how-to-build...
I’ve been playing with an ambient chat concept, so I designed and generated a bunch of different chat UIs to see what felt right www.thoughteddies.com/notes/2025/l...
Strongly agree. I tried vibe coding to try and build a better mental model for the current limits of agents
In doing so I understand how my project works, learn new things as I collaborate with the agent, and keep the code in a state where it can continue to be extended. I’ll definitely progress more slowly but I won’t fly off the rails either.
So where do I go from here? I’ve actually had immense success writing code using agents and models with my hands on the wheel. For production code, this has always been the only viable option. But for personal projects, I now appreciate the ceiling vibe coding placed upon them.
The agent cannot be prompted to code itself out of the hole it digs. I’ve tried. I’ve told the model to identifying duplication and refactor. I’ve read the code and identified the points of duplication then told the model where and prompted for a refactor. State of the art models and agents fail.
At this juncture, I could evaluate the plan and pull in more context in case the agent missed something. To be able to do a good job of that, I need to know the codebase, at least architecturally. I need to know how state is managed, what libraries are used, how the file hierarchy is organized.
The agents just do things. Yes let plan, read files, make tool calls and use MCPs. But then they just *go* and that is a problem. From experience, I don’t think I ever want an agent to even start writing code without proposing a plan for what it wants to do.
These problems can’t be anticipated. You can’t rule-write your way out of them because you rarely know what the X0,000 line codebase should look like when it’s only X,000 lines. You can write code that remains flexible and is refactorable but today only the human knows when there’s a problem.
This becomes a problem only later when you realize but at that point the agent has made more poor decisions based on this initial one.
The code will work and meet your requirements, but if you don’t read the code, you’re not going to realize when the model deviates in its approach from what you considerable reasonable.
It’s too late. For every convention rule you do write there will be one you miss. The agent will invisibly write working code that makes decisions on your behalf, filling in under specified requirements, and eventually you will have spaghetti.
Finally cracks open the code. What am I even looking at? Ever tried to grok XX thousands lines of legacy code? Not easy. Use the model to find which code to look at. State is everywhere. State in hooks. State in redux. State in zustand. I really should have written rules for conventions.
Now the codebase has fragmented state. Viber comes back to the codebase 15 commits later. The application has grown considerably. GPUs, brrr, etc. Prompts the agent to make more changes using the state and it fails. Follow up prompts, debugging, MCPs. Why isn’t it working?
Initially, this doesn’t seem like a problem. The agent does what it does best. Writes code to solve the problem. No shared states available in the React app? No problem, it’ll write some hooks for you. Viber validates the behavior in the browser. Looks good? Commit and ship. Never reads the code.
Agents use search to look around a codebase to find relevant files to pull into context. You can also use rules to define how an agent should structure the codebase. At some point, often unbeknownst to the viber, the agent fails to pull a relevant file into the context window.
Agents love to generate code. Give one a task and it is off to the races. In a new project, this isn’t the worst thing. In a project with existing functionality, this becomes a problem due to a combination of lack of context and lack of effective planning. The two go hand in hand.
You might argue I need to use rules better or something like that. I would say that isn’t vibe coding. I interpret vibe coding as the agent addressing whatever whim I have in the realm of the possible, figuring it out for me. Mostly, I end up with spaghetti codebases that the agent cannot untangle.
Having done a lot of vibe coding lately, I think I’ll move away from it exclusively. Current agents eventually fail to adhere to some prompt despite various attempts and approaches. Whenever this happens and I look in the codebase I am usually mortified by what I find.
For now, I’m out on vibe coding but I’ll still be using models and agents often.
Tell me about your vibe coding experience and nightmares.
