How Theo’s AI Coding Workflow Changed

Five months ago I described a workflow centered on Cursor, Opus and detailed plans. Since then my tools and habits have changed substantially. I now organize much of my work around conversations with coding agents, and I want to show how that looks on an actual project rather than pretend the old recommendations are timeless.

The example is Lakebed, an ambitious full-stack platform I was building largely on my own. Working across its runtime, backend, data and deployment pieces let me compare different models, harnesses and project instructions. A solo project is an important qualification: a larger team may need different coordination and review practices.

At the time of recording I mostly used GPT-5.5, though model preferences date quickly. My subscription also had a special tenfold promotional allowance, so my experience with limits was not representative of a standard plan. Availability, prices and allowances can change and should be checked for the plan a person actually has.

A harness is the application and tool layer that lets a model inspect files, run commands and make changes. I have been using the Codex harness frequently because I like its relatively simple CLI and the features available around it. Different harnesses can give the same model different tools and instructions, so the model name is only part of the experience.

T3 Code, which my team develops, is an interface for managing agent harnesses; it is separate from T3 Chat and is not itself the underlying harness. Julius did most of the implementation, and I am clearly biased toward our product. I also consider the Codex desktop app useful, especially for switching between projects and task threads.

I like this style of interface because it keeps conversations, projects and work visible without forcing me to live inside an editor sidebar. My judgments about individual apps, their stability and their teams reflect my experience at the time of the video. Other developers may reasonably prefer different interfaces and workflows.

I also discuss subscription restrictions and how third-party interfaces may be billed differently from an official client. Those details are specific to the products and terms I was discussing then, not a current price guide. Check the provider’s current rules and the actual plan before choosing a tool.

Remote work matters to me because I want an agent to continue after I close a laptop, then be able to reconnect and see the result. A persistent remote machine separates the execution environment from the device I carry. It also means I need a dependable way to inspect work and reconnect to sessions.

I tried controlling a Mac mini through the Codex desktop app and encountered a disappearing model picker, slow history and terminal input, and unreliable image pasting. Those are the problems I observed in that setup, not a claim that every remote connection or later version behaves the same way.

I then tried T3 Code’s remote and browser-hosted interfaces and found terminal input and image pasting more reliable for my work. A user also showed an instance running on Replit and controlled from a tablet. These are examples of setups people tried, not independent performance benchmarks.

I mention Tailscale as one way to connect devices across networks without exposing the service to the entire public web. The product had mobile web access at the time, and the team was working on a native app. Any remote setup still needs access controls appropriate to the machine and data involved.

Traditional SSH terminal workflows can require session persistence, switching between threads and worktrees, and workarounds for images. I paste screenshots frequently, so those frictions matter to me. I still use a CLI for quick local tasks; my preference for a desktop or browser interface is a workflow choice, not proof that terminals cannot work well for others.

When I am away from my desk, I increasingly run work on the remote machine; when streaming or collaborating locally, I may work on my own computer. The important property for me is being able to resume and inspect a task without tying it to a laptop staying open.

Context management is a major part of the workflow. When I needed authentication for Lakebed, I cloned a previous project called Shoo and pointed the agent at its implementation as a reference. A relevant repository can give the agent concrete examples that are difficult to convey through a vague description alone.

The original Lakebed thread began with a long voice-to-text description of the goal. For large changes I still like planning, but I prefer a conversation in which the agent can investigate and sometimes prototype rather than a rigid separation between planning and editing. I acknowledge that an agent can act too early, so the appropriate boundaries depend on the task.

I began by explaining the desired outcome: a full-stack TypeScript system where agents could build and deploy small applications without repeatedly navigating dashboards. I asked the model to critique the idea before proceeding. That prompt contained more context because the project was broad and the risks were not yet clear.

The agent pushed back that the proposal combined a runtime, database, synchronization, storage, deployment, security and more. I read the response, discussed which objections I accepted and which I disputed, and narrowed the idea. The conversation was useful because it exposed assumptions, not because the model’s first answer was automatically correct.

My strongest recommendation is to read what the agent says. If its output is too long or hard to follow, ask for a more useful format and then respond to the substance. Looking only at generated code can miss a disagreement about the actual goal or a warning about a design decision.

People ask which special skills or prompt frameworks I use. I generally start by asking directly and adding machinery only when it solves a recurring problem. I do keep a shortcut for a particular critique prompt, but my broader point is that a straightforward exchange can often be enough.

For Lakebed I wrote AGENTS.md myself as a short explanation of the project’s purpose, audience and working assumptions. It is closer to a letter than a catalogue of every file. When I noticed repeated misunderstandings, I refined the shared context so future requests could stay simpler.

I also listened when the agent challenged ideas that were hard to justify, and sometimes dropped them. For planning, an HTML document with diagrams was easier for me to review than a wall of text. The first version needed substantial feedback, including annotated screenshots, before it became useful.

Once the repository contained examples of a good plan and the agent had useful project context, later tasks often followed the same conventions. That can reduce repeated steering, although existing examples can also propagate mistakes. Review and updating the instructions remain necessary.

I started many threads during the project, but nearly all were sequential on the main checkout rather than many simultaneous worktrees. Parallel work can be useful, yet I found tracking numerous concurrent changes distracting for this solo project. The right amount of parallelism depends on the team, dependencies and risk.

One short request asked how server-side environment variables should be deployed. The agent proposed treating a local file as the source of truth: additions create values, edits rotate them and deletions remove them on deploy. I liked the design and asked it to implement it. Those replacement semantics are a design choice, so teams should consider deletion and secret-handling consequences.

For another task I asked for an administrative user table with per-user limit overrides. I gave a little more detail because the authority and user experience mattered. A good prompt can be concise while still naming the outcome and constraints that determine whether the result is acceptable.

A glossary in the project instructions helps disambiguate who is speaking and acting: the agent building Lakebed, the humans building it, the developers using it and those developers’ agents. Shared vocabulary is especially useful when the same words can refer to several layers of a system.

I start a new thread for a new concern so old conversation history does not steer the next task unnecessarily. The agent has to explore the repository again, but I find that acceptable for my work. Starting fresh trades retained context for less irrelevant context; neither choice is universally right.

I usually describe what I want rather than naming a file in advance. The agent can search for the relevant implementation, and I may discover that my first guess about the right file was wrong. When precise locations, constraints or permissions matter, they still need to be communicated.

For a complex custom-domain question, I gave a concrete example of a deployed project, a domain, a CNAME and the desired user experience. I asked how to handle certificates without excessive cost. The example made the problem and constraints clearer than a long abstract explanation would have done for me.

The initial answer did not give enough cost detail, so I asked for a breakdown and then described a preferred user flow more precisely. For a change I was ready to implement, I would have the agent write a plan, review it and hand the result to a fresh thread. The conversation is iterative rather than one perfect prompt.

Give the agent a way to verify its work: appropriate commands, tests, logs or a real UI check. In my setup, computer-use tools let it inspect an application after deployment. I found that this improved my confidence in the completed work, but an agent’s own verification is not a substitute for suitable human review or production safeguards.

I estimate that most of the threads in this project met my expectations on the first attempt, but that is my informal recollection, not a controlled success-rate study. I also show an anonymous deployment change where review feedback led to fixes and merge conflicts were resolved before I merged.

For a new change I estimate its complexity and decide whether to stay in the current checkout or use a worktree. If discussion reveals a bigger task than expected, I may start a new worktree and thread with the initial request plus the lessons learned. Isolation is a tool for managing changes, not a requirement for every task.

On my solo project I used fewer pull requests than one might expect, but I did seek extra review for security-sensitive and hosting changes. Automated review tools and other agents can identify issues, which I then ask the agent to address. Their findings still need judgment, and the review process should match the risks and team rules.

Easy pull-request creation has a downside: a shared project can accumulate many stale proposals that nobody intends to merge. A one-click workflow is useful when the PR is a deliberate review artifact, but it can create noise when used for every unfinished experiment.

I asked an agent to compare an old admin branch against the latest main and resolve conflicts only if the changes were still useful. It reported that the relevant work had already appeared on main in newer forms, aborted the merge and recommended closing the branch. That is a useful example of checking whether work is still needed before doing more of it.

My overall advice is to keep the workflow understandable, focus on the desired result, read the agent’s responses and give it ways to verify. I am happy with this setup today, but tools change quickly and my preferences may change again. Teams should adapt the approach to their own review requirements and projects.

I prefer conversation-centered interfaces for my work and encourage people to try them. The important part is not adopting my exact app or abandoning code review; it is creating enough shared context to make useful progress and checking that the resulting software actually does what is needed.