My career started with a love of building UIs and products. I was self-taught, I "learned to code" back when that was a thing. I learned the basics of UX and product design as well. Don't make your users think; the right path should be easy and the wrong path should be hard; simplicity was an ideal to strive for. We might have the same books on our shelves if you have one with a very dangerous-looking coffeepot on the cover.
As we've seen LLMs and agents become the dominant paradigm, wholesale design changes have felt inevitable. Natural language, even voice, can be the single interface. We can finally do the most challenging thing in life, making a restaurant reservation, by talking to a robot in more or less the same amount of time.
More ambitiously/less sarcastically, a blank canvas where the computer could just figure out what we wanted and then do it seemed like it might solve all of our problems.
About a year ago I decided that the best way to learn AI development was to start a side project. I did, to be honest, fall into the same trap a lot of developers do: I know software, and so I decided to build a software tool. I wanted to approach it from a different angle though: not making one developer stronger, but making difficult processes easier.
I'd worked at large, geographically dispersed corporations and seen that the hardest thing wasn't the code but making sure everyone was on the same page. Even then, it wasn't when you were shipping the first version, it was after the weekly meetings had stopped. Then the chance that another team would break your services because an unspoken contract had changed became more and more likely.
That this problem would resemble many of the challenges users have with agentic coding would become clear soon.
Discovery
The strategy initially seemed simple: treat the current hard path (busy teams whose documentation was disorganized and who just needed to ship the next initiative) like a process that could be made into an easy one ✨with AI✨. If a change or new feature meant another team could be affected, couldn't we just, you know, figure it out by checking if system A spoke to system B?
As I built, I found myself both discovering new patterns with agents but also thinking how product design still played a role. For one, you couldn't hope to fix the high-level problem if you didn't solve the core interactions. If you search for the things people struggle with in their projects, you find the same things:
- How do you keep the agents from forgetting?
- How do you structure your markdown and PRDs?
- Why do the agents keep making the same mistakes over and over again?
In a sense, the same problems were showing up on different timescales. Another team might miss something agreed on months ago; an agent might miss something discussed yesterday. The knowledge existed, but it wasn’t reaching the next person—or agent—who needed it. The connective tissue was missing.
How do you structure a project?
In software engineering we love abstractions, because it's too complicated to understand whole systems without them. We love trees too, owing to that one time we went outside. They're also nice as a structure that lets us reason about hierarchical relationships.
In Hey Hey, this became the feature tree: the broad shape of the product at the top, the nitty-gritty details further down. Each feature gives its designs, mockups, diagrams and implementation a home. You have to think a little about where something belongs before starting work on it, but that means the next person can find it in the context of what it’s supposed to achieve.
The relationships become a key component. If you wanted to be able to answer the question of how service A could break service B, you needed to know how they work together. To do that, you needed something more than a post-hoc analysis; you needed a system built around understanding the whole product from the start.
Here was a classic bit of design thinking: make building it as a system the easy path. You don’t start a session in a repo, you start it at a feature, and the agents know where it’s implemented and where it connects to the rest of the design. They can even suggest where new work goes.
How do you keep the velocity and ease of a CLI?
Is there any question that Claude Code and Codex are the single most successful CLI products since, I don't know, DOS, in terms of mass adoption? They nailed something, despite a command line not even being many developers' favorite interface. This was one design principle, simplicity hiding complexity, taken to an extreme. You could tell a terminal to build you anything and it would. But it was also the hard path made too easy. We'd start calling it vibe coding, and new developers learned by day 100 that writing code on day one was never the hard part.
So simplicity has its limits; a car with one pedal will leave your average driver thrilled, for about a quarter mile. The coding CLI asked every user to apply the principles of a domain that was already well known but via a completely blank prompt. In Hey Hey, design docs, requirements, decisions, mockups, diagrams (and even a custom type if you want to add one) are the elements of a software product. Every one of them is an entry point to a question, research, or a new element connected to the old one.
The trick, though, is that the elements are only the visible part of the project; the agents between them are what make it work. On their own, the elements can be leaky abstractions, saying more or less than they should, or imposing a rigidity that feels arbitrary and onerous. The agents keep each one honest with the others. They follow the links to find what your change actually touches. They point out where you’ve evolved, contradicted, added to, or quietly dropped something an existing spec says. And they suggest what’s missing: a new requirement, a contract between two pieces, the task that would actually implement it. You still decide what gets in; they just make sure you’re deciding with the whole picture.
The joy (really, it is kind of fun) of vibe coding is still possible, but when you say “hey, let’s get rid of that button,” your request gets worked out against the whole of the project. The agent can tell you that the task that first implemented the button was fulfilling a requirement to let users archive their old conversations. With one pedal, that button is just gone, and you find out what you were missing too late.
Make me think?
I am a worse coder than I was a year ago. I’ve made the tradeoff because I can focus on what I can do best: design, systems, the big picture, and, yes, taste.
Hey Hey divides the work at intent. You own what you want your project to be, the agents help you manage that.
So, everything goes through a proposal process. Feature updates, mockup changes, new design docs... you can use the agent to help with all of these, but you keep control over what changes get approved in your project. Hey Hey keeps the history; the agents read it and remind you why you did things.
Happily, the agents rarely forget anymore. Mostly, they remind me what I've forgotten.
Ultimately, not making users think takes on a different aspect: let them think about what they want to build without making them remember to set 'depends on'. Always present but quick-running assistants, sync, and review processes help users catch the obscure requirement or the missing step in their plan. And finally, Hey Hey can do things like catch that change in system B that would have broken system A.
Where we go from here
I think about the human psychology of the product more than anything. What's the tradeoff between an annoying, onerous process and letting users just mindlessly click accept? Every design I work on these days goes towards making choices easier to understand. In my day to day, I still make mistakes while rushing too much to get a solo project out of the door. I find I should have read a paragraph a little more closely. Maybe that's just on me, but making the consequences clearer is going to be one of the biggest challenges of the AI era.
What it costs
I break cost down into three categories: money, time, and frustration. I've almost come to think frustration is actually the most important one. The point of using agents is to make your life easier. When deciding where the tokens go, I think they're better spent on search and analysis, not just pure implementation. That said, if this sounds like an excuse for why it costs hundreds a month, I just stepped down to a single $100 Anthropic plan and a $20 Codex one (you use whatever plan you have with Hey Hey), and I still have usage left over despite other projects. Starting with the right context can make the agent's life easier too.
What's shipped
https://heyhey.dev is a website that you can sign up for. You bring your own plan, but for now it's in beta and free to use (capacity allowing). It works with what you already have. A small CLI on your machine runs your own Claude Code or Codex sessions, so the agents work against your local repo using your plans. The only thing stored on the server from your session is the conversation messages, so your team (and other agents) can see what was discussed and decided.
Already have a codebase? Hey Hey imports it and the agents draft a feature tree. But Hey Hey can only know what was built, not why, so you'll have to fill in some details, at least once. It’s the same trade as everywhere else in Hey Hey; pay a little up front, and the agents stop guessing.
Top comments (0)