The first half of my second year at university has been unusually busy. I spent much of it experimenting with different product forms, building working demos, and thinking through problems I had never encountered before.
More than ninety percent of those ideas never moved beyond an early stage, but each one exposed another question worth pursuing.
Models continue to advance at an extraordinary pace. This feels like a good moment to slow down and share some of the thinking behind that work.
How Models Trained My Expectations
Before learning to code, every major model release looked like a huge leap.
My first comparison goes back to December 2023. Claude felt far behind GPT-4, so I canceled after a month and did not return. By the summer of 2024, Sonnet 3.5 had completely changed Claude's reputation. I never used that model myself, but the message reaching me was simple: Claude had become very good.
Sonnet 3.7 was the first Claude model I used for programming. Only a month or two after I began learning to code, I built Restaurant Deep Research, a multi-agent system that used the Google Maps API to find restaurants. At that stage, simply getting an agent system to run from the command line felt amazing.
The move from Sonnet 3.7 to Claude 4 inside Claude Code was the first model upgrade I felt directly. The whole programming experience moved forward with it. My curiosity shifted from the code a model could generate to the agent around it. Inspired by Context Engineering for AI Agents: Lessons from Building Manus, I built a harness of my own. It became the core of Verina.
Verina was my first project to grow beyond ten thousand lines of code. Moving from a command-line experiment to a larger local application changed the scale of what felt possible.
Anoma raised that threshold again. Built with Opus 4.5 and Claude Code, it became my first production system. Something that would have felt unimaginable only months earlier was now running for real users. Some even told me that parts of its deep research experience could match Manus.
Each step reinforced the same expectation: the next model would absorb even more responsibility. First implementation, then integration, and perhaps eventually stability itself. The more capable the models became, the more of the system I expected to offload, leaving only the most exciting work: shipping new features.
By early 2026, this was no longer simple optimism. It had become path dependence, and at the time, it felt entirely justified.
Then the Curve Started to Bend
So I tried scaling the agents.
After Anoma, most of the attention moved to a longer-term bet, the cloud agent. The goal was to run agents remotely at scale and eventually use their work as feedback for evaluation and training. The desktop and iOS versions of Edith continued alongside it, together with several smaller experiments. At one point, four products were moving forward at once.
At first, it worked. Demos appeared within days. Different agents could explore features, write code, and test implementations in parallel. More tokens and more agents seemed to expand what I could attempt, faster than ever.
Taken separately, any one of those side projects was more technically ambitious than Verina, which had taken two or three months to build the year before. Yet none felt ready for release. They worked, but “working” was no longer an acceptable standard.
Agents were very good at producing the nodes. I still had to understand the edges.
Desktop Edith made the trade-off especially clear. At the time, the Gemini Live API path I was using did not expose context caching for the voice session, which made long-running conversations expensive. A direct real-time session kept the interaction responsive but expensive; splitting the pipeline into speech-to-text, a language model, and text-to-speech offered more control at the cost of additional latency. Once the context grew too large, even deciding when and how to compact the session became part of the product experience.
On iOS, an MCP layer validated the agent's tool call and turned it into a feed object built from a limited set of components. I still had to decide which components existed and what each interaction meant.
Both versions of Edith could have gone further. But they were side projects, and pushing either one toward its ceiling would have taken too much attention away from the cloud agent. So I paused both.
This was where the curve began to bend. At the demo stage, stronger agents translated almost directly into faster shipping. Once the problem was clear, they could carry much of the implementation end to end. What I had not understood was that software development is open-ended. A product does not converge on one correct answer, and once other people use it, every release creates the next problem. AI still raised the entire development curve, but its slope naturally became gentler as user feedback, system trade-offs, and wider responsibility entered the loop.
The same leverage also changed the shape of the team. Fewer people could cover wider parts of the system, but each person had to understand and own more. The challenge was no longer how to make an agent do more in one pass, but how to build a better loop with it across the full life of a product.
Product Form Is the First Frontier
Scaling was only one side of these experiments. From Verina to Edith, I was also thinking about how an agent product should meet its users. Before discussing interaction, however, there was a more basic question: how does a product create demand?
I keep returning to two ways this happens.
One resembles the central idea in Inception: plant an idea deeply enough that it begins to feel like someone's own. Products such as Manus, Lovable, Cursor, and Claude Code do this by showing people what they can build, research, or automate. Their showcases carry a simple message: You are a builder. You can ship anything. This approach works particularly well on me.
TikTok begins with a need that is already intuitive. People open it for entertainment or curiosity. The feed observes what they do and continuously creates more specific things they want to watch, follow, or buy. Demand forms inside an experience they already enjoy.
This is why TikTok remains tier zero to me. It is not only a successful product. It is a piece of art and an absolute animal.
My own experiments focused on a related question: how much intention should a user have to provide before the product can act?
Verina still followed the search engine model. Its interface was intentionally close to Google, with an almost empty screen and a single search bar. The user still had to describe what they wanted, but the product reduced that decision to one obvious action.
Desktop Edith tried to remove even that step. Press one key and start talking, whether at a desk, cooking, or washing dishes. The interaction was novel, but novelty never became habit. It was not something I depended on every day, so there was little reason to keep pushing it as a side project.
The iOS version explored a personalized feed of generated videos and location-aware restaurant suggestions. The goal was to make recommendations interactive. A ranked result could become the start of a conversation rather than the end of one. The user could tap it, speak, refine the request, and immediately receive another set of results. Traditional ranking could still do much of the selection; the agent made the first move and kept the loop going.
Verina reduced the initial interaction to a single search bar.
iOS Edith explored a proactive, personalized recommendation feed.The product remained a prototype for practical reasons. Personalized video generation was expensive, location and personal context raised serious privacy questions, and the experience still began with reaching for a phone. Scaling that experience was beyond what an independent developer could reasonably afford.
Across all three experiments, the direction remained the same: ask less from the user and move more responsibility into the product.
The Frontier Is a System, Not a Point
Product form was the system's interface with the user. Behind that interface, agents allowed me to move across frontend, backend, data, and infrastructure, but every additional layer also widened the scope of the decisions I had to own. The question was no longer how many agents I could run, but how to use them to build a coherent system.
Some parts of such a system are routine. Consider a presigned URL. The client asks to upload a file, the backend checks permission and returns a short-lived URL, the client uploads directly to object storage, and the system records the result. The information flow is well understood. An agent only needs to implement it correctly and test the relevant cases.
Most mature systems are not built entirely from problems this clean.
The recent rewrite of Bun in Rust is a useful example. The migration did not happen because someone gave Claude a broad instruction and waited. It worked because the runtime was already deeply understood. The architecture to preserve, the experiments to run, the feedback to trust, and the behaviors that could not change had to be made explicit and refined throughout the work.
Directing a migration at this scale is its own form of engineering. Knowing how to perform the rewrite is one threshold. Knowing whether the rewritten runtime is ready to ship is another.
Bun's entire test suite passed before the rewrite was merged, yet the rewrite still introduced nineteen known regressions, all of which Bun reported fixed by publication. One required side effect had been placed inside Rust's debug_assert!, so it disappeared from release builds even though debug builds behaved correctly. As of July 24, 2026, Bun 1.4 remained a canary while 1.3.14 was still the latest stable release.
Agents from two years ago could not have carried a rewrite at this scale. Today they can. But people remain inside the process, defining the migration, interpreting feedback, discovering missing cases, correcting behavior, and deciding when the system is ready.
This is why I like the phrase loop engineering, although perhaps in a slightly different sense. The loop should not apply only to agents. As models become more capable, the person working with them also has to keep learning what can be delegated, what still requires judgment, and how the workflow itself should change.
A large problem can be divided into checkpoints. At each checkpoint, the model and I continue until the current question is answered or one of us reaches a limit. The result becomes the starting point for the next loop. If the main path is blocked, a smaller loop can establish the missing lemma before returning to it.
Building an inference engine made this process concrete. The project began with a vague goal: host Kimi K2.6 on 8xB200. The first checkpoint was not inference at all. It was to give one request a visible lifecycle across the frontend and backend, including its generate, abort, and output paths.
Only after that boundary was stable did later checkpoints move into scheduling. The scheduler grew from admission into waiting and active requests, logical KV state, and the BatchPlan and BatchResult that carried one execution step through the system. Once the mock executor returned a result and the scheduler committed it, the CPU loop became a usable checkpoint for the next stage.
Every long-running agent session eventually runs into a finite context window. To continue, the conversation has to be compacted into a shorter summary. That became painful in this project. The code survived, but much of the reasoning behind it did not. Because the architecture was being discovered through failed hypotheses, a compacted or new session could see the current design without knowing which assumptions had already been tested and rejected.
The first attempt to solve this was trace retrieval. Redis and PostgreSQL would collect rollouts from many concurrent sessions and make them searchable. But building that pipeline introduced another complete infrastructure problem: concurrent writes, retries, replay, indexing, and deciding which parts of a trace were still valid. The retrieval loop was becoming larger than the problem it was meant to solve, so I stopped it.
What the next session actually needed was not the entire history. It needed the latest checkpoint: the current design, the failed assumptions, and the remaining questions.
That idea became agent-workspace, a private CLI built around Codex CLI. A workflow could launch independent Codex CLI processes, rather than native subagent threads, in parallel; give them the same goal or checkpoint; constrain their outputs with schemas; and persist the results in one shared workspace. Each agent worked independently, but began from the same checkpoint and wrote durable results to the same workspace.
The checkpoint still had to evolve with the project. When new evidence invalidated an assumption, the document changed with it. A new agent could begin from that checkpoint, inspect it against the current code, correct it when necessary, and continue.
With that workflow in place, work on the inference engine resumed one narrow question at a time. The request path, scheduler, state ownership, and mock executor each went through several checkpoints rather than one large implementation pass. Only after those smaller loops formed a working CPU control path did the design move toward eight workers.
The next architecture gave each worker process its own scheduler, executor, and BatchPlan. A StepCoordinator would collect their local shapes and produce one GlobalForwardShape, allowing all eight processes to enter Executor.forward() in the same order.
The next checkpoint required turning those plans into physical GPU work and verifying that all eight ranks remained synchronized through a real forward. The project had not yet entered the attention layer. Verifying the design required access to 8xB200, while the main focus had already returned to the cloud agent, so the work paused there.
The loop did not produce a finished inference engine. It produced a precise place to resume. Something that began as an unknown unknown had become a known unknown, ready to become the starting point of another loop.
Long Live the Human
A loop like this runs on curiosity. That is why a phrase I keep seeing online, fear of missing out, feels so different to me. It describes moving forward because fear is chasing you from behind.
I do not think fear is a particularly good engine for progress. It may make me run faster for a while, but it does not tell me where to go. Curiosity has carried me much further: trying things, burning tokens, and discovering what I can understand next.
Even the word boundary now feels slightly wrong. A person does not have one fixed boundary waiting to be measured. Learning keeps moving it, and curiosity gives me a reason to enter unfamiliar territory, stay with it through the frustration, and return knowing something I did not know before.
Whenever I begin to question the value of pure human intelligence, I like to return to PostgreSQL, Kubernetes, or the history of operating systems and read how their great system designers thought. These systems are not beautiful because somebody found one clever trick. They are beautiful because generations of people learned how to reason about ownership, information flow, trade-offs, failure, and change.
Models will keep getting better, and I will keep trying them. But I no longer expect every new release to tell me where the frontier is. There are still systems to build, unknowns to discover, and many things I want to learn.
And there is still life outside the loop. Drink coffee on Sunday afternoon. Go to a bar on Friday night. Take the time to read, think, and learn. None of this will leave me behind.
There is nothing to fear, and nothing I need to catch up with.
Long live the human.