I’ve always loved a good DX, and followed the work of companies that really care about it.
Lately, I’ve been wondering how much that still matters when an agent writes most of my code. DX is about how developers experience a piece of software, how they interact with it and the outputs they expect from it. But where does all of that go when an agent is the user?
Looking at my own workflow helped me figure out that yes, of course it still matters. I experience that DX through what I have to explain to agents, the code they produce, and how much of it I have to review.
The perspective
I've always looked at DX as a consumer. I choose the tools I work with based on my perceived experience.
- How much plumbing do they require?
- How much machinery do I have to interact with to get them to work?
- How easy is it for agents to find what they need to implement or fix issues?
All of this is stuff at some point I need to interact with it even though im not manually writing code. But the point of this post is actually sitting on the other side of the table. I want to talk about what happens when there's no tool at all. That forced me to ask the same set of questions but from a different perspective.
I’m getting blasted
Even though I now write very little or none of the code I ship myself (for good), I spend my time prompting, interpreting AI’s outputs and reviewing PRs.
I hate getting bloated with massive PR descriptions or lines of code I can’t interpret in a reasonable amount of time. It gets worse when the code solves a problem my team has already figured out in the past. Over time, I noticed how much time went into fixing the same bugs and rebuilding the same behavior across projects, like WebGL scroll sync.
That repetition isn’t new. But now with more code than ever, and every new implementation is another one to review, debug, and keep consistent. Generating the same code got faster, but making sure it behaves predictably still takes work.
Build and shape your solutions
I already know how I want something to behave, I can put that knowledge into a library and improve one implementation over time. If you ever tried doing something like this, you already know that it’s not free. Designing a solution agnostic across projects takes effort. But you can always start small and iterate till you cover all the use cases.
That could be a utility I reach for often, or a set of entities that keeps logic in the right places across a larger system. Build a library around those decisions. Give the next project something solid to rely on, and carry its improvements back to the others.
Of course, code reuse has always been there. I’m not inventing anything. What makes me look at it differently now is how much faster and easier it’s become to build a library, harden it, distribute it, and adopt it across projects. Even if you don't care about the retrocompatibility, the ugliest migrations are a piece of cake for agents nowadays, changesets are your friends for this.
Your team probably already agrees on how to solve certain problems. Start there. Figure out the DX and make it your own. You don’t need to nail the first version.
DX is a matter of polish
Now that you encapsulated a solution, on your way to implement it, you always find simpler ways to do stuff. That includes finding ways to reduce the API surface or require less code to do the same.
I like to treat host projects as “clients” and my libraries as “providers”. I ask the host project to write a feature request or API change spec to improve the implementation ergonomics. Then I hand that document to an agent on the library project to evaluate what is worth doing and what is not.
Of course, there’s always some personal taste in that, I define the boundaries of what to encapsulate and .
Relying on pieces of code that get shaped and reused is more token efficient, bloats your review context much less and allows you and your team to move faster.
The mindset
The JOYCO development team is constantly shaping it's workflow based on this set of questions:
- Are we producing code for already solved problems? If yes, why don't we have a solution for them?
- How much of the code agents produce feels like plumbing or excesive machinery? Is there any tool opportunity?
- How easy is it for agents to find what they need to write code using our tools and reasoning?
Developing for the next project to have a better starting point is a whole mindset. And so far it has proven to have a huge impact on working less on what we solved already, and more on what's yet to be discovered.
