If your opinion of AI still comes from a chatbot giving you broken code a year ago, it might be time to try again. My development workflow has changed enough that I can’t treat AI as a novelty anymore. And I think refusing to use it out of pride could become an expensive decision.
It’s been a while since I posted here. Fatherhood has kept me busy, but I’ve also been changing how I work. Over the past year or two, I’ve gone from asking AI for suggestions to letting agents do work directly on my machines.
That difference needs more attention than another argument about whether AI-generated code counts as real coding.
From suggesting commands to running them
I used to look up how to check disk usage on Ubuntu because I rarely needed the command and never remembered it. A chatbot could give me the command, but I still had to run it, interpret the output, and figure out what to check next.
With an AI agent connected to the server, I can ask:
How much storage do I have left, and what’s taking up most of it?
With the right tools and permissions, the agent can inspect the machine and report what it finds. It works with the actual server state instead of guessing from whatever I remembered to paste into a chat.
That’s what I mean by an agent here: AI that can use tools to carry out a task, rather than only reply with instructions.
Finding large files and deleting them are different jobs, though. I’d want to review a cleanup plan before letting anything remove files. Giving an agent access doesn’t mean every action deserves permission.
Why Pi and T3 became part of my routine
Pi fit the way I work. It’s lightweight, runs in my terminal, and lets me work directly on my virtual private server (VPS). I’d tried OpenClaw and Hermes too, but Pi suited my technical work better.
Then Theo’s T3 Code caught my attention. My first reaction was basically: great, another wrapper around a wrapper. I liked Pi partly because it didn’t need all that.
But in the 0.0.46-nightly build I tried, the Pi integration worked well enough to change my mind.
I have three servers, each with Codex, Claude, and Pi installed. T3 lets me access those setups from one workstation and switch between them. I can also hand a conversation from one model to another when I want a different approach or a second opinion.
The mobile app made that setup much more useful to me. I could reach the same servers from my phone, ask for changes, and use Codex Computer Use to interact with another computer. I eventually dropped my Hermes setup and moved that work to T3.
I’m not suggesting everyone needs this exact stack. The useful part is having access to tools that can do the work, wherever I happen to be. Pi and T3 are how I got there.
A website in nine minutes, then the review
One example was Towers, a website for comparing skyscrapers around the world.
My request was roughly:
Build me a public website comparing skyscrapers around the world. Host it on towers.anazhd.com. Use TanStack Start, Cloudflare Workers, and Cloudflare D1. Use the relevant skills.
Nine minutes later, it was up and running.
That was my experience with this project, not a promise that every website takes nine minutes. A deployed page also isn’t proof that everything works correctly.
I still had to verify the result. For a site like this, that means checking the comparisons and data, testing the interface, and making sure the deployment behaves as expected. The agent getting something online faster gives me more time for that work; it doesn’t excuse me from doing it.
But going from an idea to a working site that I could inspect in nine minutes? Yeah, that changes how I think about starting a project.
I spend less time typing and more time checking
Before, I wrote the code myself, patched things as I went, and sometimes tested less than I should have because I was tired. Doing everything manually didn’t automatically make my work better.
Now I spend more time describing what I want before implementation. I work through the plan and requirements, let AI handle more of the coding, then focus on reviewing the changes and testing the result.
Here’s the shift in my own workflow:
| Before | With an agent |
|---|---|
| Look up a command, run it, interpret the output | Ask the agent to inspect the server, then review its findings |
| Write most implementation code myself | Describe the requirements, then inspect the generated changes |
| Work through setup and deployment manually | Delegate setup and deployment, then verify the result |
| Squeeze testing in after writing the code | Spend more of my effort on functional and visual testing |
This is a change in where I spend my effort, not a claim that every task should go to AI.
Reading code still matters. So does understanding the system well enough to spot a bad assumption. If I can’t explain a change or work out how to undo it, I shouldn’t approve it because the agent sounds confident.
Skepticism is useful. Arrogance can cost you.
There are good reasons to question AI. It makes mistakes. Some work involves sensitive data. Costs can add up, and an agent with excessive permissions can do damage.
Someone who tests a tool and decides it isn’t suitable for a particular job is making a judgment. Someone who refuses to try it because they consider themselves too good for AI is avoiding one.
That second attitude worries me.
If another developer can produce comparable work faster with AI, your insistence on doing everything by hand may stop looking like craftsmanship. To the person paying for the result, it may look like a longer wait.
That doesn’t mean everyone who avoids AI will lose their job. Hiring and replacement decisions depend on far more than one tool. But refusing to learn can narrow your options, especially when the work you sell includes tasks that others can now complete with less effort.
Experience should help you decide when AI is useful and catch its mistakes. It shouldn’t become a reason to stop testing new ways of working.
Try it on work you can verify
You don’t need to buy every subscription or rebuild your entire setup. Pick a task you understand well enough to judge:
- Ask an agent to investigate a problem without changing anything.
- Let it draft a small code change and review the diff.
- Have it write tests, then check that they cover the behavior you care about.
- Try a deployment in a disposable environment before giving it production access.
Compare the result with your usual process. Include the time you spend correcting mistakes, the cost, and the review effort. If it doesn’t help, you have a concrete reason to say so.
Keep credentials scoped to the task, require approval for destructive actions, and have a way to roll back changes. Check your workplace’s data rules before sending anything sensitive to a model.
I still care about understanding what I build. I just don’t feel the need to type every line to prove that I understand it.
You can dislike the hype and still learn the tools. What worries me is refusing to learn, then expecting your experience to protect you when the expectations around your work have changed.