Be the advocate for your agent’s UX

My first week of Mega.dev, a four-week online program for developers who already build with AI, taught by Kent C. Dodds, Angie Jones, John Lindquist and Theo Browne, strengthened some of my ideas and reminded me of the importance of having external eyes look at how my system works. I didn’t really know what to expect - I’m already a Theo enjoyer (Theo Browne, CEO of T3 and a YouTube personality who is passionate and deeply opinionated in a frustratingly right way about everything from type safety to skateboarding and keyboards) and he’s helped shape a lot of what I’ve done with my own systems. I had been watching him on Twitch one evening the week before Mega and I got interested but didn’t pursue it until a nagging feeling Sunday night had me submitting a request in hopes of a fast turnaround.

My manager is a great advocate for all of his employees, so he of course saw this as a good opportunity and got the approval but logistics caused a wait until late Tuesday. By that time the form was no longer accepting orders. I contacted Mega hoping that I could still get in - and either late in the evening or early the next morning I got the email that I could in fact get in. Now I was a couple days behind but I was in with an open mind and still somehow wanting to prove how good my systems and workflows were.

You Are In

LORE · MOMENT

the seat was empty. now it isn’t.

PR0 015/120

Lesson 1Thu Oct 29I read the first lesson and watched the video then had my agent at work run the first challenge - the lesson’s scored task for your agent, with traps built in. Everything went smoothly, I looked over everything and was happy.

But I knew I wanted to catch up so I ported over to my home setup. This was a key and interesting decision because the course is more than just tuning your understanding and exposing you to techniques - it’s putting in tricks and snags to really challenge not only how your system responds, but how your practiced behavior impacts the outcomes.

Thus, the environment matters a lot - at work, I have a single development machine set up for a different kind of workflow than at home. I use one provider’s models, same or similar interfaces, but a different set of workflows and approaches to software development. It isn’t completely different, but when you work with a team some things are necessarily different. There’s also the huge benefit of other minds to work with and who have to check my work - that has informed a lot about how I work at home where I don’t have that benefit, but I also don’t have as much friction in choosing exactly how I want to experiment and change my systems.

This mattered more now than usual because I was this week in a major transformation in my own practice. I had over a year built up a lot of things that I like but were getting too heavy, were organized in ways that I didn’t like or actually didn’t work and so I made wide sweeping changes to my environment including retiring a bunch of skills I had been using, setting up some leaner skills and working on getting my T3 environment working how I want - T3 Code is the app I run my agents in, across providers and machines.

At home I have a desktop, an AI server, a web & home services server and a NAS which all make up a fleet of systems that I work with. I do most agentic work on my desktop and the AI server and I want my surface, the UI on which I focus my attention, to be able to seamlessly utilize whichever machine makes the most sense based on what else I have going on. I also use several providers at home: Anthropic, Codex, Grok, Antigravity - T3 makes managing these super easy. Getting it all together allows me to orchestrate work across multiple machines, using multiple models which opens opportunities for cross model evaluations, spreading out my tokens or focusing them on the right model for the task.

Lesson 2Thu Oct 29So my home system wasn’t as finely tuned and I was going to be poking at it and I really hoped it would prove itself. I did the second day and this time I had only 2 snags, problems that changed what my agent or I did, but 50% of the challenge KPIs, 2 of the 4 things it was testing, went wrong the first time.

Did my configuration changes fail me? I have a strong preference for validation and evidence based work but that didn’t stop the agent from making a guess that caused a silly mistake. That irritated me to no end but the analysis led to immediate changes where I added a return-path hook on t3_thread_launch so a thread my agent starts can always report back to it, fixed some agents files being skipped problems - Claude Code wasn’t loading a repo’s AGENTS.md when a CLAUDE.md sat above it.

The assessmentThu Oct 29The course has an assessment tool which I had actually taken the day I started. It reads your agent session history and scores 24 working habits. The figure below shows what it found. This can be done multiple times before, during and after the course - the entire idea is that it examines your sessions to extract information about how you work, what’s working well, what costs time and a plethora of observations that allow for even further self-examination.

This is a core skill that I feel like I’ve been leaning into for quite some time - use your agent to help you with anything. Leverage your curiosity, your skepticism, your ambitions and make things happen that were too hard or too tedious to do before. Lean in to the tedium - those things are what agents are great for - one of many things Theo stressed in the first week.

So I dove in and made more changes and made plans for how to get those changes across my fleet and how I might transfer learnings without forcing myself to redo lessons on my work machine - I want everybody tuned!

Are you seeing it yet? I’m personifying my agents - not with silly personalities and wasted context, but in my mind. I’m thinking about them like my employees that I want to have the best environments and the least amount of friction. When I started down this journey a year ago it was about removing my friction, but now I realize that comes from getting out of the way of agents on the things they can do well, help them fix when things go wrong (they’ll just work around it and you may not even notice it because you get a good result), and make that my loop.

Lessons 3 and 4Thu Oct 29 and Fri Oct 30Lessons 3 and 4 were the first time I got really mad because the challenge showed 2 things that both went wrong first. In the previous challenge the agent recovered but in this one it was me finding the problem and informing the agent that got us over the hill.

But then the next problem happened because it jumped the gun on the last step. Small but irritating because my tooling does have timers for just this case - so the way I approached that was to examine how without writing prose - in code or a check rather than one more instruction file - I can make sure that the agent is aware particularly of T3 tooling that makes its ability to orchestrate my fleet smoother. Both of these could have been avoided with a bit more attention on my part and I wanted to make sure that was more built in. There are places where I need to change my behaviors, but I also recognize that I have a certain way of working and I want my system to be aware of that and compensate where possible - so I went down another fix round for the environment.

During this fix, my old skills really caused some problems - skills from a setup I had recently retired. Their docs still described them as live, so an agent planned around them which wasted time. The necessary step, which you’ll see is becoming a pattern, is to examine the problem and do another round of fixes so that wouldn’t happen again.

Lesson 5Sat Oct 31Finally day five comes to synthesize everything and I work carefully, I read the challenge thoroughly then have a session to examine it even more deeply, asking questions and pointing out where I see traps, planning out what my agent would need as this challenge had to host a service with an agent that would have to respond to mega.dev servers. Once I had all the components pulled together and a plan for how to satisfy all the items we went off.

I spent too long I think on this overall but I wanted a fully clean run. I almost got it - everything worked first time except for one issue where a fetch request option was supported by Node but refused by Cloudflare’s runtime - it was thoroughly tested locally yet the self-test, the live check the service ran on itself after deploy, never actually sent a reply.

Simple fix but I still didn’t love it - getting past the ego hit I realized that I need to keep questioning, analyzing friction and improving the agent’s experience, using the wealth of data my sessions create on their own. Most things working doesn’t mean you can put down the guards, but those guards are best served by an attitude of service to your agents to facilitate the best outcomes, including designing validations for all sorts of common failure modes in order to plug them up. It may be tedious, but the tedious work I had to do each day reduced a bit.