Joshua Valdez

1.5 years with Claude Code

2026-09-02T00:00:00.000Z

It’s been a year and a half since Claude Code launched. In that time, coding with AI has gone mainstream. Anthropic and OpenAI have grown by leaps and bounds. And we’re seeing the complete transformation of a profession that’s only been around in machine form for 80 years.

Last year I was addicted. I spent days and nights glued to my terminal building prototypes. I had already been AI-pilled and with Claude Code, I became an evangelist. .

Fast forward to now and am I coding faster? Definitely. Do I enjoy it? I’m not sure. Do I still believe AI is the future of coding? Yes.

Strangely, I feel more ambivalent about coding with AI now. The shift feels less radical as time has gone by. It’s no longer the future of coding, it’s just coding.

Agents fill in the details of my work. I no longer have to bother with the intricacies of TypeScript.

Yet, I still have to determine the direction of my work. Agents amplify direction. If you don’t know what you’re building, you can certainly get to nowhere fast.

Early on when building with Claude Code, I compared it to being an engineering manager. I was happy to hand off the details. But I’ve now realized something is missing in that analogy.

When I hand off a task to another engineer, I know that engineer will be responsible for it. I know they’ll consider their options, interact with others on the team and use their knowledge of our systems to make reasonable choices.

I can prompt for the same thoroughness with AI and surely as the models get better, they’ll be more thorough.

Sure we’ll have systems that handle reviewing a plan, making sure the code adheres to the plan, adheres to our codebase guidelines and accomplishes the goals we set out.

But that sense that a task, a project, or an app is owned end to end is not there. Yet.

I’ve seen ideas here referred to as a “software factory”. The software is churning out itself.

For meaningful work that solves problems we care about, I’m skeptical.

There’s something missing from AI-produced software that only a human can add. AI doesn’t produce out-of-distribution ideas.

Humans will long be necessary to set direction and probe the limits of what’s possible.

I don’t see that changing anytime soon.

What changed?

2026-02-27T00:00:00.000Z

I’ve been using coding agents to write 100% of my code since Claude Code came out.

The discourse lately about a big shift in agent ability initially surprised me. I agree the agents are great. Though I have not seen a huge difference between Opus 4.5 and 4.6 as well as Codex-5.2 and 5.3. The new models are incredible. The models just before were quite incredible too.

I will admit, 4.6 and 5.3 seem to be just a bit smarter than their predecessors.

So is the change in the discourse that these models crossed a threshold for people?

Is the change that people had written coding agents off and came back to drastically better models?

Or is it something else?

I’d argue it’s a little bit of everything. The models are likely the majority, let’s say 70% of the change. But the harnesses also play a meaningful role.

A few major improvements in the harnesses have made a huge quality of life difference in my day to day.

Specifically, auto compaction has made a massive difference in being able to rely on an agent to complete it’s work. It can’t be understated how reliable auto compaction is a huge unlock to coding workflows.

Claude Code’s auto compaction initially was borked and I never used it. I would dutifully create a new session once the context window filled up.

Now, I have been working on greenfield projects for the past year. What about someone working on an old codebase?

Autocompaction is in my view the single biggest improvement outside of the model. I played around with making a fork of Zed in December and something in the agent’s ability work work independently gave me confidence that I could actually do this. Auto compaction was a huge part of it.

The ability of a model to take an underspecified prompt and do something reasonable with it has been a huge change. Early on with Claude Code, I would give it a task that was relatively well scoped and expect it to still need assistance. Now I can give it larger tasks, expect it to make reasonable decisions and test the output. That switch to larger tasks makes it more impressive to folks just tuning in.

Finally, the models have been RLHF’d to ask questions and be more conversational. This tuning makes them feel fun to use! It’s like working with a real collaborator. Opus 4.6 shines particularly well in it’s conversational style. Codex-5.3 shines in it’s speed.

I started to see the shift on conversational ability with Codex-5.1 and it it’s only gotten better since then.

The tuning here to default to asking the user questions softens the hurdle for getting good results from the first prompt. In a sense, the models train the human users to disambiguate. That makes a world of difference in helping a human user understand how to get the best results from the model.

A few other things I like:

Claude Code’s use of color helps me grok ideas faster
Codex’s app makes it seamless to start a bunch of ephemeral threads

The quest for flow with AI coding

2026-01-09T00:00:00.000Z

I love programming with agents. I was an early adopter of Claude Code and I feel like it unleashed a burst of creativity for me.

At the same time, I’ve been puzzled to find that as I use agents more, I get this distinct sense that they’re slow.

I’ve spent the past 6 months trying to root cause this feeling by building. At first I built my own cloud agents.

My reasoning went: if agents are slow, I’ll write up a decent plan and then kick it to a cloud agent to finish while I move on to other things.

Building the cloud agents was fun, in particular I enjoyed refining the interface and keyboard shortcuts for the cloud agents.

At the same time, I found that the bottleneck then became twofold:

Testing the results of the cloud agents
Iterating on a detailed enough plan for the cloud agents

Testing the results is a hard problem. Codex and cto.new both attempt to solve this with loading a web app and screenshotting the results. That’s great for web apps but as any experienced software engineer knows, iterating on UI is only half the battle.

So, setting aside that can of worms, I took inspiration from Repo Prompt and built my own code/chat interface.

For a relatively small codebase, I could drop entire folders of code directly into the model’s context and ask for a plan to build the next feature I was working on.

The plans I generated with this approach were great and I built an affordance to kick a finished plan into my cloud agents.

So far so good.

Except, not quite.

The model often took a long time to formulate a plan. When you’re waiting 5 minutes for the plan, you can’t stay in flow. You no longer feel like you’re pairing with the model, you’re just waiting on it.

Enter, GPT-5-Codex.

Using this model felt like a revelation. It’s designed for coding and it strikes the right balance of being smart and fast to respond.

I decided to transform my chat interface into a Codex driver and so far I’m very pleased with the results. It’s quite fun to use a chat UI to code.

At the same time, I haven’t quite answered my original question.

How do I stay in flow while coding with AI?

Do I lay out all my tasks up front and kick off simultaneous planning sessions? Do I spend more time writing elaborate RFCs for the agents to follow? Do I use beads?

I suspect we’ll be asking this question for a long time to come.

Build your own background agent!

2026-01-08T00:00:00.000Z

I recently shut down my startup, Engines. Coming off that experience, I felt a huge burst of creative energy to build and explore.

I had some inklings that AI coding interfaces didn’t align with my sensibilities (mainly achieving flow while coding with agents) and I want to build my own background agent interface to see how it would work.

Here’s my experience building a background agent on top of the Claude Code SDK with Claude Code itself.

First I needed to choose a sandbox provider. Initially I started with Daytona but I struggled to get Claude running. It turns out that even though the Claude Code SDK runs headless, the underlying libraries used still require a terminal present. This posed an issue on Daytona but eventually I was able to figure out a workaround.

Once I had chosen my sandbox provider, I chose a hosting provider. I’ve used Render in the past and liked it so it was the obvious choice.

I decided to build the backend in Rust and the frontend in Typescript. Mainly because I’ve been enjoying using Rust for AI projects, since I find the compiler can catch many potential errors before they are committed.

Building something end to end that worked took a week or so. Building something reliable has taken longer.

The first roadblock I ran into was that Daytona did not support SSH from outside the sandbox. That was initially a critical requirement because I wanted to support SSH into the container so I could test things locally.

So I switched to Modal. Surprisingly this was very straightforward since Claude had written a decent Rust interface for the sandboxes.

Once I switched to Modal, I was enamored with how convenient it was and how clean its interface is. It’s incredibly fast. The startup times for its containers are incredible. Less than 10 ms due to two clever proprietary filesystems.

I was able to quickly build a custom image for my background agents to have the right compile time tools.

The most useful learning by far in this process has been to understand what background agents are useful for.

I have come to see background agents as one of three things:

Exploratory agents for a new feature
Quick bug fixers when I know the root cause or can point to a set of potential causes
Executors for concrete plans

I have come to the conclusion that for these tasks, the agent itself doesn’t matter much. I switch often between Claude Code and Codex and I find the results typically are about the same.

That’s surprising! I would expect Opus to yield dramatically better results but I don’t find that to be the case.

My take on the future is that background agents will become a commodity. Everyone will have one for the aforementioned tasks above and you will likely rely on a competent but not SOTA model to get things done.

Since I was programming almost entirely with background agents, I came up with another tool to speed up planning. I found myself relying often on Repo Prompt (link) but I found the copy/paste tedious.

I wanted to select files for the context window just like I would in Zed, with a Crtl + P workflow.

So I built Swarm Desktop. It’s a chat interface that allows you to drop files into GPT 5 and chat with them. GPT 5’s context window is quite large so depending on your codebase, you can drop plenty of files.

You can then ask for detailed plans based on your desired changes and get back a plan that Claude Code or Codex can follow.

Swarm Desktop also allows you to spawn a task to Swarm Cloud with the click of a button.

I find myself using this often when I discuss a plan at length with GPT 5 and then have it output the final plan for implementation.

Through this all, I have found my preferred way to work with agents and I’ve built more of an intuition for when these tools are useful and when they need more direction.

A startup is momentum

2025-11-13T00:00:00.000Z

Over the course of building Engines, I came to realize that a startup is momentum. You can build momentum in various ways:

Outreach to customers
Building new products and features
Blogging about what you're building
Raising funding

To win, you have to do all these things. Not necessarily at the same time. But relentlessly over time.

You have to tap into a deep well of demand for something people want and then harness that demand with relentless focus and execution.

Stop reading, start doing

2025-09-12T00:00:00.000Z

If you try to read everything there is to know about a subject, you’ll never get started learning.

Starting a company is an act of doing.

When I first decided to become a founder, I did what I’d done when preparing for any other thing in life. I sat down to research how to become a founder.

When brainstorming ideas, I would first search for competitors.

When trying to sell to customers, I would first ask for feedback.

But a startup is a process. It’s not a chain of thought.

8 hours sending cold emails and 1 hour reflecting on the results is worth more than 9 hours “doing research”.

Stop reading. Start doing.

The unbearable slowness of AI coding

2025-08-19T00:00:00.000Z

I’ve been coding entirely with Claude Code for the past two months. At first it was exhilarating. I was speeding through tasks. I was committing like mad.

Now, as I’ve built up a fairly substantial app, it’s slowed to a crawl. Ironically, the app I’m building lets me parallelize many instances of Claude Code at once.

Often, I’ll have 5 instances running while I’m thinking about new features.

The slowness comes in when I actually need to review all the PRs. One by one, I have to apply them locally. One by one, I have to step through the console logs. One by one, I have to tell Claude to fix the issues it created.

Yes, it’s faster. I’m committing an incredible amount of code these days—more than I ever have.

It also feels incredibly, maddeningly slow. Once you’ve felt that first boost of speed with Claude Code, you want every coding task to feel like that. It’s addictive.

Instead, as you build, you still have to serve as Claude’s QA engineer.

Maybe one day we’ll solve that. But I’m skeptical it will be in the form of a CLAUDE.md. I can barely get Claude to consistently follow the bare set of rules I have, much less ensure it performs a complex integration test for a web app.

Until then, I’ll keep pulling PRs locally, adding more git hooks to enforce code quality, and zooming through coding tasks—only to realize ChatGPT and Claude hallucinated library features and I now have to rip out Clerk and implement GitHub OAuth from scratch.

On building trust

2025-08-05T00:00:00.000Z

I spent the last 30 days vibe coding Swarm. The experience keeps bringing me back to one overriding question about AI coding: how do I build trust in the agent’s outputs?

Building trust in the outputs is critical to scaling usage.

If I can check out a PR and be sure it’s correct by running a few tests locally, that’s great.

If I can see the tests on the PR passed, that’s even better.

If I can see the agent ran a comprehensive integration test in its own sandbox that ensures the end-to-end flow works correctly after the changes, that’s the best.

I am a longtime Phabricator user, and one of my favorite aspects of the tool is the “Test Plan.” At Gem, we used the Test Plan section to write down how we tested the changes in the PRs we put up for review.

So far, I have not seen an AI coding tool that has a similar concept.

I want to know the code generated is trustworthy. Trustworthy means more than just passing the linter, unit tests, and compiler. It means it won’t break production. It actually handles edge cases gracefully.

With convincing test plans, we’ll be able to treat agents as actual engineers vs. the very smart interns they are today.

Eventually, we will move beyond humans as the gatekeepers for trust and agents will be able to establish trust with each other.

Engineering is writing

2025-08-05T00:00:00.000Z

I spent the last 30 days vibe coding and it’s changed how I think about programming.

Programming is clarity of thought and writing. This was always the case but LLMs make it more clear.

Once you’ve spent a lot of time exclusively using LLMs to code, they feel more like fancy autocomplete. They initially feel like a miracle. They can output so much code in so little time. Building a basic web app has never been faster.

But they can’t replace clarity of thought.

If you don’t ask for a specific structure in the code, they’ll put everything in one file. If you don’t specify edge cases, they’ll default to non sensical behavior.

To get the most out of coding agents, you have to write very clearly.

You have to sit down and really think deeply about what you’re building it before you start building it.

Future of coding agents

2025-08-05T00:00:00.000Z

Soon we will all be using coding agents. Hundreds of them. The best software engineers will be the best multitaskers. The ones who can architect a great application, split it into parallelizable work and guide a team of agents to build it.

Agents reward expertise and clarity of thought.

We will still need software engineers. Our jobs will just be different.

Companies will use a variety of coding agents just like companies use a variety of IDEs today.

One team will prefer Claude Code. Another will use Devin exclusively. Another team will build their own agent, specialized to writing bullet proof Terraform.

The coding experiences that win will deeply understand:

How to build great UX so engineers understand the work agents are doing
How to build great agents

A winning experience must have both. Great agents without great UX will be increasingly harder to use as agents do more and more of the work.

Principles for vibe coding

2025-08-05T00:00:00.000Z

1. You get out of it what you put into it

I’ve seen engineers say “AI doesn’t work well” and simultaneously be giving Claude Code prompts like “fix this.” If your task description to the agent wouldn’t be good enough for a human engineer, it’s not going to be good enough for an agent.
Using agents is work! They can dramatically speed you up but you need to make use of them well.
Building an intuition for what an agent will do well at and where it will struggle is critical.

2. Get clear on what you want to build

Do you want to modify a React button to update on an app change? How do you want the button to change? What color should the button be? What state should the button store?
If you can answer these questions, you will get a better response from the agent.

3. Use o3 for planning

So far, o3 seems to be the best thinking model for coding. I dump my code into o3 in ChatGPT using Repo Prompt, ask for a plan that I can put in Claude Code, and then run the plan.
If I am struggling with a bug, I ask o3 for information on the bug.
Using Wisper Flow dramatically speeds up my prompting. I find myself giving a bunch of additional context to the model when I’m speaking instead of typing.

4. Test agent output just like you would an intern!

You would not trust an intern’s code!
You would pull the PR, test it thoroughly and review it.
You should treat AI generated code similarly.
You can speed up review with o3 before taking a look at the code to catch any obvious issues.

5. You are the architect and your existing codebase is the guide

Do not trust the agent to architect well! You should ask o3 to plan good decomposition in advance and instruct it to structure things well.
Your codebase being well decomposed will help here! If it’s clear to you where something should go, it will be clear to an agent.
This is one of the biggest struggles for vibe coding. You can get started quickly but multiple Claude Code sessions later and your codebase is a mess. I often have o3 suggest a refactor which works quite well!

6. Have tests!

This is one I am still struggling with. When I’m iterating quickly on a codebase, it seems superfluous to create integration tests.
On the other hand, when an agent can run the tests, or at a minimum, run the type checker, it can usually iterate to a decent solution.

1 week with Claude Code

2025-03-21T00:00:00.000Z

The repo stats for the Rust CLI agent codebase. 100% AI written LOC.

Hooked!

Do you remember when you wrote your first working program? The high you got seeing it compile? The rush of changing a few lines and seeing it do something new?

I first experienced that in middle school with my TI-89. I took the calculator manual and started to write simple programs.

In high school, I wrote an entire stoichiometry program. I remember I was so addicted to coding that my chemistry teacher would ask me if I was following along with the lesson. Of course! I had already read the entire chemistry textbook cover to cover. So I told her what the lesson covered and got back to TI-BASIC.

Now, hold on to the feeling. Because you’re about to feel it again. Claude Code is that good.

Claude Code Changes Everything

Claude Code has completely changed the way I write software. If you haven’t tried it, you should.

Claude Code paired with Sonnet 3.7 is the best agentic software engineering experience I have tried.

It can handle bug fixes, UI changes, test updates, and more.

I’ve written an entire Rust CLI agent with Claude Code (and a bit of Devin). 100% AI written. I have not touched a single line of code.

This is my first time writing a lot of Rust, and I’m flying. I built the majority of the CLI agent over this past weekend.

This is my workflow:

Spec out what I want to accomplish
Write a detailed task message in Sublime
Copy the message into Claude Code
Have Claude iterate till the compiler passes
Test it myself
Report any errors back to Claude
Repeat

Problems with Speed

There is no way I can possibly review all the code that is generated by Claude Code. It’s too much. I’ve found myself getting carried away with the iteration loop and realize that I have a massive amount of unstaged changes in my git repo.

That necessitated that I build msg (also with Claude Code). It passes the diff of the git changes into Claude 3.7 and outputs a short commit message. This has saved me so much time and keeps me in flow.

Additionally, the codebase is large enough that Claude Code can get a bit confused and break things between large changes. I’ve had to get more in the habit of:

Prompt Claude Code
Test changes
Commit

If I miss the commit and the changes are directionally correct, Claude Code might break something already working.

Another problem I have yet to address is how my cofounder will manage to review all the PRs I’ve been pushing. There’s just too much code! 😅

It’s great for an MVP. It will be interesting to see how my workflow changes as we move this MVP into production use cases.

The Vibes Are Real

Claude Code has forever altered how I relate to coding. It feels lighter. It feels faster. It feels like I’m floating.

I can output an incredible amount of working code for $1 here or $1 there. Sure, Claude Code is more expensive than Cursor or Windsurf, but it’s also better. It produces great results at light speed.

In the past week, I’ve spent $94.99 on Claude Code—$400 a month—to output an incredible amount of software that I wouldn’t have been able to do otherwise. I sped through building a prototype and trying different ideas.

What is the price of your time? Using Claude Code changed my mindset.

Paired with Devin, I can achieve the equivalent output of a few engineers—worth hundreds of thousands of dollars. The only limitation is the speed of my own thoughts!

This is not vibe coding. This is real, working software. I’m demoing it to a potential customer tomorrow; with a bit more polish, they’ll be able to use it.

In a way, Claude Code helps me type code at a superhuman speed. So, instead of handcrafting each line, I am free to iterate on my startup's higher-order work: building what customers want.

Tips

Make it clear to Claude how to run your tests
- Ideally, one simple CLI command: cargo test or npm run test
Give Claude a linter!
Be very specific with your prompts!
Ask Claude to tell you its plan
- Spot issues with the plan that result from ambiguity in your instructions.
- Tell Claude Code to “think hard” or “think harder” to kick the Sonnet 3.7 model into thinking mode.
- This approach results in a more well-reasoned plan.
Ask for options
- Request various options and their tradeoffs when generating a plan.
- This allows you to choose the best option or instruct it on something it didn’t consider.
Have empathy for the LLM
- LLMs are incredible, but they have non-human-like shortcomings.
- Develop an intuition for what will and won’t work through iterative testing.
Iterate on the outputs instead of the code
- Focus on the result you’re aiming for.
- Consider all the ways to verify the program’s results, encode these in tests, or have Claude Code write the tests.
If you want to go all in, sign up for Devin too
- Typically, I kick Devin off right before I head to bed.
- I Slack it ideas before sleep and wake up to review and merge working PRs.
Also, consider giving Codebuff a try
- Similar to Claude Code and Aider, Codebuff has a streamlined terminal UI and doesn’t require you to approve every action, saving time on small fixes.

I’m Not Going Back

After a week with Claude Code, I am never going back to writing hand-crafted code.

There are a few areas where it struggles but I will iterate on my prompts. Specifically, it can’t build a great terminal chat UI. But that’s probably because what I want for the UI is underspecified.

You have to overcome the initial inertia of being frustrated with bad outputs. And remember, prompting is a skill!

Engines

This post wouldn’t be complete without a word on Engines.

We’re building a CI/CD agent. Drop it into any repository and it can:

Generate a working Dockerfile to containerize your codebase
Run your linter automatically
Run your tests
Help you deploy your code

If that sounds helpful to you, reach out to me at josh@engines.dev.

Additional links to coding with LLMs

Simon Willison is one of my favorite newsletters to follow, and his piece on coding with LLMs is worth a read.
Ryan Endacott’s post has similar vibes and inspired me to write this.
John Horton's Claude Code presentation is great for tips! I learned about git worktrees (for multiple instances of Claude Code running at once on the same codebase)!

On getting startup ideas

2025-03-04T00:00:00.000Z

Doing is better than thinking. Pick a direction, get a customer, iterate.

We tried to take a top down approach to deciding what to build in multiple iterations of our company. Each time we approached starting that way, we ended up finding dead ends.

It's impossible to tell why a company is truly successful from the outside. Their marketing is tailored to a specific problem they are solving for the customer so the marketing is downstream of the problem.

To truly understand a problem, you have to talk to users.

Talking to users means identifying the rough shape of a problem, asking people if they have it, and listening to what they say. They will guide you in solving their problem.

This does not mean a vague "discovery" conversation. Pick a specific problem. Include a short description of the problem in your outreach. Then dive deep in the meeting.

Once you know the shape of the problem, ask them to pay!

If you never test willingness to pay, you will never know if your product is actually useful.

Dev tools for agents

2025-02-20T00:00:00.000Z

A common theme I've seen emerging lately is dev tools built specifically for agentic use cases. I think the next billion dollar companies in dev tools will be here.

To clarify, I mean tools that LLM agents can use directly for the purposes of software engineering. Agentic tools are a broader category that includes web browsing, payments, etc. I think those will be big. However, I'm primarily interested in tools that AI SWEs use.

A few examples that resonate in this space are:

I think evals, memory and agentic frameworks will also play a role in AI SWEs. My take is that these will be AI SWE-specific, but I have yet to form a strong opinion on how these pieces will be tangibly different from the same infra for agents broadly.

Weights and Biases is building an interesting trace-based approach to AI SWE evals.

Why I'm starting a blog

2025-02-19T00:00:00.000Z

I come across a ton of launches and papers at the intersection of AI and software engineering. I'm starting this blog as a way to keep track of what I've read over time and also share my perspective on new developments.

I'm the founder of an AI SWE infra company: engines.dev. We're building the best platform for AI SWEs.

I am a former infrastructure engineer from Uber and a former engineering manager at Gem.