Drew Barontini | Equilio Coding

I rarely write code by hand now.

It feels weird to say that.

I worked hard for over 20+ years to learn design and engineering. Then I led cross-functional teams to build hundreds of products in dozens of industries. And in each step, I was in the work, shaping ideas, designing interfaces, writing code.

I’m still in the work, but at a new angle, with new AI colleagues and tools.

I don’t write ones and zeroes. I don’t know binary or assembly language. I didn’t create my own programming language. I write code built on layers of abstractions.

The best programming language today is natural language, which you use to tell a machine to write the code for review.

I moved up the abstraction chain. Again.

So what’s important now?

Preserving judgement by understanding the complexities of a dynamic system like a software product—the relationships, dependencies, and capabilities. You need to know what the code does and how the system works so you can instruct the agent and review the work. Your job is to maintain coherence at all levels so your product remains valuable and differentiated in an increasingly oversaturated and homogenized market of meh software.

When you write the code by hand, you directly participate in the process of building the codebase, the system.

You’re individually responsible for every choice, every character, every outcome.

I was thinking about a quip from Steve Jobs when he spoke at MIT in 1992.

“How many of you are consultants?,” he asked the room. “Oh, that’s bad,” he said as hands raised. The room filled with laughter.

When someone asked why, he elaborated:

I think that without owning something over an extended period of time, like a few years, where someone has a chance to take responsibility for one’s recommendations, where one has to see one’s recommendations through all action stages and accumulate some scar tissue for the mistakes and pick one’s self up off the ground and dust one’s self off, one learns a fraction of what one can.

It’s the perfect corollary for the moment we’re in now. Humans are using AI to design, write code, define strategies, and anything else at the altar of “efficiency.” If you can think about something, you can muster enough coherent sentences to get Claude to generate the output.

Viable? Yes.

Usable? Debatable.

Understandable? Hopefully.

And that’s the issue. When you don’t participate in the process of creation, you don’t understand what you create. It’s like leading a team where they do all the work and you only view the output—the manager who doesn’t really understand any of it because they stepped out of the work to “lead” and “manage.” It’s hard to understand how something works if you didn’t arrange the pieces, make trade-off decisions, and live in the tension of unresolved problems.

I’ve always stayed in the work to maintain coherence in the system. Now I’m building software through machines and designing systems that allow it to happen with humans and agents in the loop and shared understanding in the process.

So the question changes.

If it’s not economically viable for me to write code by hand, then how can I have code written by the machine while I direct and review its work? And what happens when you have an entire engineering team leveraging their own suite of AI coding agents to write code? How does the entire team, product, and system of work maintain coherence at that scale?

The lines of communication are exploding.

From me to an engineer to their agents to other agents and other engineers and other designers to other stakeholders. But, at the same time, collaboration and open discussion is shrinking. Engineers pair with their AI agent instead of a teammate. The shared context happens in silos instead of out in the open. Product Memory helps, but more intentional context curation is necessary to maintain coherence.

These are some of the bigger questions I’m thinking about. But for today, I want to focus on how I’m tactically writing code in a new way that aims to remove (or alleviate) the pitfalls of agentic coding. I packaged up my philosophy for writing code and building products into a set of repeatable skills to help centralize context in a way for humans and agents to maintain a shared understanding of the work.

I call it Equilio Coding, named after Equilio, my product philosophy for building software by creating value, refining quality, and building momentum with intuition, integration, and iteration.

It’s a way of thinking about the work, not a prescriptive framework that falls apart in the real world of building software.

In no way do these skills guarantee an understanding of the work. But it is a way to engage in the process so you’re still there defining the focus, helping make the decisions, and maintaining quality in the output, as well as the context to create a paper-trail your team of humans and AI agents can pick up and follow. The thread of context and information has always been inportant to the quality of creation, but now it requires a new interface for work.

Core Skills

Equilio Coding contains five core skills that make up the workflow:

Frame to define the problem.
Map to test it against real code.
Explore to test patterns in reality.
Build to execute the chosen path.
Integrate to refine the system.

Not every issue requires every skill. They can be mixed and matched.

There are three key differentiators that make these skills different than others:

Continual Context. Each skill continually updates and writes the current understanding back to the core artifact: the issue.
Plain Language. The issue and Pull Request templates adhere to strict constraints and style guides to avoid the nauseating AI-generated text.
Working Prototypes. Even AI uncovers issues when it writes the code, so the skills create working prototypes you can test before choosing the direction.

What’s most interesting is how this workflow aligns with how I worked when I was writing the code by hand. Using the skills with AI in the same workflow means I can follow along and track the work against my own mental model, while leveraging the speed and intelligence of frontier models.

Frame (/equilio-frame)

Start in the problem space. Don’t try to solve the problem before you know what you’re trying to solve. When you understand the problem clearly, you gain freedom in the solution space to explore new ideas and novel approaches. If you solve the wrong problem, you’re now wasting your time, tokens (money), and the opportunity to work on something else.

I give /equilio-frame the Linear ticket ID and it takes it from there. I use the issue description as the initial write-up of what I understand about the problem and what needs to be resolved. Then the skill reads it and will ask any questions it needs to build the frame of the issue.

It will write a local Markdown file I can read and provide feedback on. Once we agree, it will update the Linear issue to outline the:

Problem: the actual gap.
Solution: the high-level approach.
Decision: choices and reasoning.
Impact: changes in the system.
Reality: the real tests so far.

It writes the current understanding into the template. The format of the template won’t change as you go through the phases, but it will improve its resolution.

Map (/equilio-map)

The next step is to start mapping the surface area. Look at the code and the product to understand the solution space.

/equilio-map builds on the problem framing from Frame and will investigate the code to map out what changes should take place. I also like to use this time to think about the changes to the product.

Do we need a new screen?
Are we removing something existing?
What new affordances (buttons, copy)?

The agent comes back with updated information about what needs to change. It writes another local Markdown file to review and iterate on before the next step.

When I’m good with it, I say so and it writes the update to the issue. It fills out the same sections as before, but with an improved understanding from looking at the code and the product surfaces.

Explore (/equilio-explore)

Explore is my favorite step. I don’t just jump to building it yet. Well, sometimes it’s simple enough and I do, but I really like the exploration step. The agent explores a few prototypes to test in a live browser so I can see how it feels.

I recently updated our AI chat interface with new side panels. During Map, the agent asked about the side panels floating above the content or sitting next to it.

I paused and thought.

I didn’t know. This is exactly the type of decision you should make only once you play with it in the live environment. You have to feel it and use it to know.

So that’s what we did.

The agent created both versions of the UI, and included a small toggle on the panel so I could swap between the two options in real-time in the browser. Seeing the quick contrast between the options made the decision easy. That’s why I have always loved designing in the browser. I use the browser DevTools to change the HTML and CSS to see the changes happen instantly, making it easy to decide with the contrast.

Build (/equilio-build)

With the prototype path chosen, the next step is to build it. The agent writes the code against the chosen option, removing any prototype code so it’s fully working.

This is where I pay more attention to reviewing each change, but the skills also adhere to my own development principles to make sure the output is consistent. And we have agent Markdown files in our repos to provide further constraints.

Let me pause here to talk about how important constraints are. And I’m not just talking about for AI. When engineers build new features, they need constraints to make decisions and progress without ballooning scope. In a complex system, constraints provide protection against increasing complexity. I remember Claude writing a bunch of extra logic for a React component (hundreds of lines of code) when there was already a simple prop built into the component. It was a few lines of code to make the change. Without added constraints—like always referencing existing components—Claude added more complexity because it was easier to write net-new code than it was to understand the current system design and think about how to integrate it.

I add some of these constraints to the skills in the form of principles:

Understand First to make sure the problem is clear before changes.
Fewest Changes to reduce the surface area to the smallest possible changes.
Optimize for the Reader to make sure code changes, comments, and the written updates are clear.
Better Than Before to leave the code in a better state than the system was before you changed it.
Close the Loop to create appropriate tests that improve the coverage and make the system better.

Integrate (/equilio-integrate)

The final step is to integrate your work back into the system. The agent wrote the code with you as a passenger, but you still need a refinement pass. This is where you review the code again, and have the agent look for key changes that affect the system in a measurable way. You need to know and understand those changes so you can make it clear in the Pull Request when more humans and AI agents review the code. The agent also updates the issue with the final understanding, linking it directly to the changes in the PR.

This is where the Product Memory system kicks in because it picks up on those changes and uses them to document decisions and key product updates.

When reviewing AI-generated code, make sure the code introduced is necessary and not duplicated or overlapping with another part of the codebase. AI also loves to add superfluous comments everywhere. The more, the better! Code should be self-documenting, but comments are still useful with certain changes. And AI also loves to write tests, but no test is better than the wrong test, so be mindful of what tests it’s adding. Testing strategy matters.

When I’m using Integrate, I focus on leaving the code better than I found it.

If I’m fixing a bug, let’s add protection and test that will catch drift the next time.

Be a good code citizen.

More Skills

Outside of the core skills, there are two other skills I’ve built into Equilio Coding:

Loop to run the above steps until done.
Explain to walk through key changes.

Loop (/equilio-loop)

/equilio-loop is a specific skill to run through all of the core skills until the goal is reached, calling for human judgement and understanding when the changes warrant. I typically do this for fixes I know ahead of time. They have smaller scope and don’t need to step through every skill with me involved. Use your judgement to decide when to use this in your workflow.

Explain (/equilio-explain)

/equilio-explain walks through the changes and teaches what a maintainer should understand differently because of the changes that were made. I use this when I’m making larger changes, reviewing other people’s changes, or just trying to understand a new part of the codebase.

Change & Opportunity

The way we write code is changing.

It always changes.

As Lorri Gottlieb says in Maybe You Should Talk to Someone:

“The nature of life is change and the nature of people is to resist change.”

I get it. I used to write code and love the flow state, the ability to make changes and get immediate feedback, and working with the code to make something valuable.

Losing that is hard.

But what if we look at what we gain? Building anything at the speed of thought. Great! But we also need to be mindful of how much we both influence what is created and how much we understand what is created.

I talk about “coherence” a lot because I believe it’s what’s at stake—in the code AI writes, in the experiences AI increasingly has a hand in, in the strategic thinking we offload. To make anything great, it requires a deliberate and thorough understanding of what you’re making. You have to participate. You can’t outsource thinking to a generative AI model and expect something novel, beautiful, and handcrafted on the other side. It’s a machine built to predict. My Claude is trained on the same data as your Claude, but our brains are not. The best teams were always the best because of their unique perspectives built on a wide range of unique work and life experiences. Skills developed over time, refined through the creative process.

That’s still true now.

We just have a new technology blurring the lines of ownership. One thing I refuse to give up is understanding the work. It takes continuous effort to change how we approach the work every day. Question your use of AI, improve your process, and always pursue a better way to work.