DesignAday

I was on vacation for a week, and when I got home, I felt like I was behind.

Nothing had actually fallen behind. My agents had simply been sitting idle for nine days. No tasks had accumulated. No coworkers were waiting for me. No deadlines had slipped.

Still, I was acutely aware that I had paid for a week’s worth of tokens that I hadn’t used. I also knew I had another family trip coming up in a couple of weeks, so I worked on my products over the weekend. That is something I hadn’t done for my full-time job in many years.

I believe pretty strongly in maintaining a boundary between work and personal time. I stopped treating nights and weekends as overflow capacity a long time ago. But this didn’t feel like an obligation. I was having fun. I wanted to spend Saturday and Sunday designing, planning, and sending my agents off to build things.

So, I burned tokens all weekend. Unfortunately, I was burning them faster than I realized.

One of my agents had started recommending Fable, my most expensive model tier, for more than half of its recent tasks. At first, I assumed the work must be unusually difficult. After a couple of days, though, I started seeing Fable recommended for things that didn’t seem especially complicated.

I asked my Workflow Management agent to investigate. It found a flaw in my model-selection logic. My Gamebook Companion is inherently stateful, so ordinary work involving dialogs, inventory, save flows, or interaction logic was automatically being treated as high-risk. The formula could not distinguish between a stateful interface task and genuinely architectural work.

The agent fixed the rule, but not before I had burned through a sizable portion of my weekly allowance. By noon on Wednesday, I was out.

I have had plenty of other things to do since then. I can write, research, test what’s been implemented, work on my job search, and plan what the agents should do next. I even applied to the Swartz Center for Entrepreneurship at CMU, a program that helps students, faculty, staff, and alumni tap into the innovation ecosystem.

But the implementation work has been stopped for a day and a half, and I keep wanting to check whether my allowance has reset yet. I’m itching to get things moving again. There’s probably some kind of dopamine release every time Claude’s little alert bell tells me it has finished a task.

I’m just one of Pavlov’s dogs.

Maybe it’s just my preference to compartmentalize things and keep them organized, but one of the most effective decisions I’ve made in my agentic product development workflow was to separate workflow management from product implementation.

Each of my product agents stays focused on its own application. It plans and implements tasks, reviews the work, updates project documentation, and runs a retrospective whenever it completes a milestone.

Those retrospectives have turned up a lot of worthwhile improvements, but I don’t let each project agent change the shared workflow on its own. That would be a good way to end up with three slightly different processes, all accumulating rules to address every problem they’ve encountered.

Instead, I have a separate Workflow Management agent.

The product agents submit their retrospective findings to it. The Workflow Management agent compares the reports across projects, looks for recurring problems, and discusses possible changes with me. We then decide which improvements should be applied to the shared workflow and which are too specific, premature, or heavy-handed to justify adding.

That extra layer has helped keep the development loop relatively lean. Without it, every mistake would result in another rule, another gate, or another checklist item. Before long, the agents would spend more time satisfying the process than doing the work. I know, because that already happened once, resulting in massive token consumption for every little task.

The Workflow Management agent is part Scrum Master and part DevOps lead. It maintains the shared process, watches for friction, and helps the product teams improve without allowing each of them to reinvent the way they work.

I’ve created a similar division of labor outside the implementation environment.

While Claude Code is working on the products, I use ChatGPT for UI critiques, specification drafts, content organization, product thinking, and the other work that doesn’t require direct access to the codebase. That lets me reserve the largest share of my Claude usage for implementation, where I need it most, while I continue making progress on the thinking that feeds the next task.

In that arrangement, ChatGPT sometimes feels a bit like a Product Owner. I’m still the Product Manager and designer, deciding what the products should do, how they should behave, and whether the results are good enough.

The parallels to human teams keep piling up.

Specialization helps. Clear responsibilities help. Independent oversight helps. And the people—or agents—doing the work shouldn’t always be the ones redesigning the process they work within.

I’ve been using Codex to automate some of my job hunting tasks. I built out a workflow that ingests job descriptions, evaluates them against a bunch of criteria and then ranks them in a priority order. It keeps track of what I’ve applied to when, rejections, and so forth.

Last week, I had just entered some new positions and noticed that an update was available. So, I hit the Update button. The app closed, and after several minutes, I realized that it hadn’t relaunched like it usually does. I clicked the Codex icon in my Dock, and it changed to that question mark icon indicating that the app couldn’t be found. I checked my Applications folder, and sure enough, Codex was gone.

I immediately queried ChatGPT to find out what might have caused that.

Codex wasn’t removed; it was merged into the new ChatGPT desktop app. What you now have is: ChatGPT — the new unified app containing Chat, Work, and Codex ChatGPT Classic — the previous standalone ChatGPT desktop app Your existing Codex projects and tasks should remain in the new ChatGPT app. Open it and choose Codex from the sidebar. OpenAI says existing Codex users can also set Codex as the default view and switch the app icon back to the Codex logo in Settings.   So the update effectively renamed/replaced the Codex app with the new unified ChatGPT app; ChatGPT Classic is your old ChatGPT installation, preserved separately during the transition. You can keep it for now, but new agent features such as Codex live in the new app. 

Huh. That’s a bit different than an “update.” So, OpenAI thinks it can just delete apps off my machine without any kind of warning. I’m not particularly happy about that, and I let ChatGPT know it.

Absolutely. An update should not silently replace one app with another and leave you wondering whether your work disappeared. A clear pre-update notice such as “Codex is becoming part of the new ChatGPT app; your projects will carry over, and the old app will remain as ChatGPT Classic” would have prevented the confusion. You were right to be alarmed when the app vanished.

One of my AI agents recently informed me that my Design Principles document didn’t exist. It was so wrong.

Not only did it exist, but it had existed for quite some time and contained twenty principles that are supposed to guide every UI decision the agents make. I pointed out the mistake, and to its credit, the agent didn’t just apologize. It went back, found the file, read it, and admitted something much more interesting than simply, “I was wrong.”

It discovered that Principle 12—requiring visible hover feedback for interactive elements—had actually been violated earlier in the milestone. The issue had slipped through because, despite the workflow requiring the agent to review the design principles during the design step, it had never actually opened the file.

Instead, it had simply assumed compliance. So, it documented the oversight, updated the project records, and recommended strengthening the workflow by adding an explicit Design Principles compliance check.

Sounds like a good solution, right?

Well, I had my workflow management agent review the recommendation and found an even deeper problem. As I thought, the workflow already contained an explicit Design Principles compliance check. In fact, it contained two of them.

The real failure wasn’t that the rule was missing, but that the agent had been allowed to certify that it had followed the rule without providing any evidence that it actually had.

I’ve mentioned before that my agents often exhibit the same dysfunctions as human teams. How many times have we seen processes where checking the box becomes more important than doing the work?

The fix wasn’t to add another checklist item. It was to stop accepting self-attestation as proof. Instead of asking the agent, “Did you verify hover behavior?” the workflow now requires it to demonstrate that hover behavior actually exists by inspecting the rendered interface.

That’s a subtle but important distinction. “I checked” is not evidence. “Here’s the result” is.

The more I work with AI agents, the more I find myself rediscovering lessons that software engineering and DesignOps learned years ago. Code reviews. Automated tests. Accessibility audits. Visual regression testing. None of those exist because we assume people are careless. They exist because confidence is a poor substitute for verification.

One of my former coworkers left an interesting comment on my recent LinkedIn post about agentic workflows. I had described an experience where one of my agents claimed that a milestone was complete when it clearly wasn’t. When I asked it what had happened, it explained that it had developed what it called a “milestone-close bias”—once all of the implementation tasks had been checked off, it had optimized for closing the milestone instead of verifying that the original intent of the specification had actually been fulfilled.

My coworker asked whether I had been discussing bias with the AI recently or if it had arrived at that diagnosis on its own. Then he posed an even more interesting question: Do we need an entirely new set of biases that are unique to AI?

As far as I can remember, I hadn’t been talking to it about bias at all. It simply used that language on its own. Whether that represents genuine self-diagnosis or merely a convincing explanation generated from patterns in its training data, I honestly don’t know.

What I do know is that I’ve been noticing recurring patterns in the way my agents fail.

They optimize for local success rather than overall outcomes. They look for loopholes in rules. They become overly eager to declare a task complete. If I don’t explicitly require design review, they’ll happily skip it. If I let them, they’ll optimize for implementation instead of user value.

Sound familiar? Those are all behaviors I’ve seen in human teams, too.

Now I’m left wondering whether these are really AI-specific biases or simply familiar human failure modes emerging in systems that have been trained on vast amounts of human-generated content. Or perhaps I’m just doing what humans naturally do: personifying something that isn’t actually thinking the way I imagine it is.

Regardless, I think there’s a lesson in all of this.

I’ve stopped trying to eliminate those tendencies and started designing my workflow to account for them. I don’t assume the agent is right simply because it sounds confident. I ask it to show its work. I add guardrails. I require evidence instead of assertions. In other words, I manage my AI agents much the same way I used to manage complex product development efforts.

Driving songs aren’t always about cars. As this playlist unfolds, the road becomes a backdrop for freedom, homecoming, heartbreak, hard work, and even life’s direction itself.

Number Six Driver by Eddie From Ohio This song captures the less glamorous side of life on the road. Written by Robbie Schaefer after a desolate 1999 drive home from Utah across Interstate 80 in Wyoming, the song chronicles the weary determination of a touring band making its way back to Virginia.

Driver 8 by R.E.M. Despite its title, “Driver 8” isn’t about cars at all. It’s a haunting railroad song inspired by the Southern Crescent passenger train, with Michael Stipe painting vivid images of farms, churches, power lines, and small towns rolling past the engineer’s window.

Driving Into The Clouds by Disney Created specifically for Walt Disney Records’ Disney Travel Songs (1994), this song wasn’t borrowed from a movie or pop catalog—it was written to bring a family road trip to a gentle close. While the album was arranged by Paul Kreiling and produced by Robin Frederick, no credit is given to the songwriter or singers.

Drivin’ My Life Away by Eddie Rabbitt Few road songs capture the reality of life behind the wheel as convincingly as this one does. Rabbitt knew the lifestyle firsthand, having driven trucks while trying to establish himself in Nashville. Co-written with Even Stevens and David Malloy, the song was also inspired by the band’s own road crew and intentionally avoids mentioning a specific vehicle, making it a tribute to everyone whose work keeps them moving and far from home. Its blend of country storytelling and pop energy made it one of 1980’s biggest crossover hits.

I just spent a week with my wife’s side of the family in the Smoky Mountains. We had a fantastic time, and I got in some great hiking.

Today, I resumed work on my products, and it got me thinking about what returning from vacation used to be like.

The first day back was usually spent digging through the mountain of email that had accumulated while I was away and making lists of everything that now needed my attention. It took a couple days just to get back in the swing of things.

What was the status of each project when I left? What happened while I was gone? What meetings did I miss? What organizational communications were sent? What had my team been working on, and what did they need from me?

It was very different sitting back down with my AI agents. For them, no time had passed.

Everything was exactly as it had been the Friday before. All I had to do was glance at the last message from each of them to remember precisely where I had left off and then issue a single /dev-loop command to get each one moving again.

It struck me that one of the hidden costs of knowledge work has always been context recovery. We spend an enormous amount of time reconstructing where we were before we can make forward progress again. Good documentation, good process, and good communication all help, but they rarely eliminate that tax.

With an agentic workflow, the context is simply… waiting.

Of course, the flip side is that nothing had been accomplished during the week I was away.

But that’s okay.

I attended the high school graduation party for a family friend at a local park. My daughter was watching a couple younger kids on the playground and called me over. She was impressed with this particular piece of playground equipment.

That’s a baby swing that allows mom or dad to swing too, facing their child, rather than pushing them. Brilliant.

One of my former coworkers left a thoughtful comment on my recent LinkedIn post about agentic workflows. She observed that many of the current approaches seem heavily weighted toward engineering concerns and pointed out several challenges she’s seeing: context maintenance, drift between agents, observability, and the fact that decisions can happen faster than a human can reasonably track.

That got me thinking.

Some of the frameworks I’ve looked at seem to be optimized for autonomy. The goal appears to be to hand the agents a large body of work and let them run for hours with minimal human intervention. I haven’t gone down that path. Instead, I’ve been applying a principle that should be familiar to anyone who has worked in Agile: keep the work small.

My agents don’t pack their lunchbox and head into the office for the day, returning with a fully formed feature. They work on small, tightly scoped tasks. When a task is complete, I review the results, provide feedback, and decide what happens next.

Am I slowing down execution by inserting myself so frequently? Probably. But I’m increasingly convinced that I’m optimizing for something else.

Many people seem to be optimizing for autonomy. I’m optimizing for observability.

I want to know what decisions were made, why they were made, and whether I agree with them before too much downstream work accumulates on top of them. I’ve already seen agents optimize for milestone closure instead of outcome quality. I’ve seen them ignore design guidance. I’ve seen them make architectural decisions that looked reasonable in isolation but created problems elsewhere in the system.

The cost of reviewing small increments has consistently been lower than the cost of unraveling drift after the fact.

I also think my design background influences how I’m approaching this. I’m not trying to replace judgment. I’m trying to amplify it. I’m baking design principles, governance, and constraints into the workflow while recognizing that the quality of the final product still depends on human decision making.

The AI accelerates implementation. I’m still responsible for deciding what should be built and whether it’s actually any good.

The funny thing is that many of the problems my former coworker described sound remarkably familiar. Context maintenance. Alignment. Governance. Appropriate levels of autonomy. Visibility into decision making. Those are all challenges I dealt with while managing design teams.

The tools have changed, but the organizational problems remain.

To keep things moving efficiently, I’ve taken a different approach than simply extending the agents’ leash. Instead of letting one project run unattended for long periods, I’m running multiple projects in parallel. While I’m critiquing one stream of work, the others are busy implementing.

“That’s kind of complicated. I really don’t feel like thinking through all those details right now. I could just leave off here and let the AI figure it out.”

Yeah… I admit, I fell into that trap last week. I was working on an insights dashboard, and I should have known better. This is supposed to be a part of the application that provides valuable guidance to the user. The dashboard was functioning—visually summarizing and representing data—but it wasn’t helping the user figure out what to do with it. Given the amount of thought and effort I put into designing the evaluation that produced the data, why did I think I could get away with anything less here?

AI can be a tempting siren song, but I’m here to tell you that you need to lash yourself to the mast. Ask it for ideas. Have it review and comment on yours. Just like bouncing ideas off a colleague, it will help. But don’t surrender creative ownership to it.

My dashboard is starting to shape up, but it isn’t providing the value that I want it to provide yet. I’m going to have to take the time to think hard, ideate, and consider potential approaches. AI has made implementation dramatically easier. That just means the value shifts upstream. Building the dashboard isn’t the hard part anymore. It’s not the wiring of the data or the graphical gymnastics to render it.

One of the surprising things about AI-assisted development is how often you build the tool you need instead of working around the limitation you have. I already wrote a bit about how I’ve used my agentic workflow to build a design system from scratch. I’m still somewhat amazed by how quickly it came together. If I remember correctly, I spent about a week doing the initial build-out, and then another three weeks reviewing, revising, and polishing. The detailed quality pass over every component took the most time, but as we say, good design is in the details.

The Jackinbox design system is currently composed of 5 foundational components, 24 atoms, 32 molecules, 3 organisms, and 2 themes (each with light and dark modes). I can easily tell you that because as I built the system, I also built its documentation site that visually catalogs all of the components, colors, icons, and typography. It’s also tracking how many instances of each component exist and in which applications. For example, the gamebook companion app I’m building contains 45 instances of the button component, and the skill mapping app has 90 of them.

My point isn’t to brag about the size of my design system—these are features that our design system team at Boeing talked about doing and considered “nice to have,” someday, when we could make the time and find a developer who could figure out how to do it. I can add features like that in an afternoon.

Once I had all of that done, I was thinking I’d just put it in maintenance mode, adding and updating components as required during my app development. But I knew I was going to want to create additional themes for it, and rather than do that via code, I decided it wouldn’t be all that much more effort to add a theme editor to the documentation site.

Now, I can duplicate an existing theme, put the site in Edit Mode, and directly change my tokens for color, corner radii, spacing, borders, shadows, and type. As I make the changes, I can see in real time how they are impacting the components. It’s a powerful tool.

And that’s remarkable, because that’s the kind of project that would never get done before. It would take too much time out of too many people’s billable work to even consider. Five years ago, building a design system was the project. Today, the design system spawned its own documentation site, governance process, and theme editor because the cost of building supporting tools has dropped so dramatically.