The Problem Isn't How. It's Why.
The quality of agent work has very little to do with clever prompts. It starts with judgment.
The Wrong Problem
Over the last year I've had the opportunity to work with AI almost every day. Some days it's writing code. Other days it's reviewing architecture, researching a problem, helping think through product strategy, or pulling together information that would have taken me hours to collect on my own. Like most people, I started by thinking the challenge was learning how to ask AI better questions.
I don't think that's true anymore.
The more time I've spent building this way, the more I've become convinced that the quality of the output has very little to do with how clever the prompt is. Most modern models are already remarkably capable. Give them a well-defined task and they'll more than likely produce something useful. The problem comes much much earlier than that.
Obsessed With How
What problem you ask? We've become obsessed with asking how while spending almost no time understanding why. We should be focusing on:
- Why are we building this instead of something else?
- Why does this workflow exist?
- Why are these constraints important?
- Why is this the right technical direction?
- Why should we trust this output?
- Why does the user actually need this?
Those aren't implementation questions, they're judgment questions— and that's where I believe people still create the most value.
Once the Why Is Clear
Once we land on a concrete, well thought out why, the how becomes infinitely easier. An agent with a clear understanding of the problem, the desired outcome, the important constraints, and the reasoning behind previous decisions can produce consistently good work with very little instruction. Without that understanding, even the most capable model is left guessing what success actually looks like, and they guess wrong a lot of the time.
That's one of the biggest shifts in my own thinking over the last year. I used to think the goal was getting better at prompting. Now I think the goal is getting better at thinking, and doing it alongside agents.
Those are a very particular set of skills. One teaches you how to ask for work, while the other teaches you how to define the work that should be done in the first place. That's ultimately why I started writing these skills and principles down.
Not Prompt Templates
They aren't documentation or a collection of prompt templates. They're the themes that kept emerging across completely different projects. Whether I was reviewing a product, helping a founder shape an idea, designing a workflow, or building software myself, I found that the best outcomes — the consistently best outcomes — came from employing the same processes:
- Gather context before implementation.
- Separate decisions from execution.
- Verify important work before trusting it.
- Reduce unnecessary complexity.
- Preserve focus wherever possible.
Look, none of those ideas are groundbreaking on their own. The point, dear reader, is that I see them rarely being applied consistently now that AI has entered the chat. People spend hours comparing models, debating prompts, or experimenting with tools, while skipping the work that actually determines whether a project is going to succeed or fail.
A Workflow Problem
The more I have watched this happen, the more I have realized that we don't really have a model problem anymore. We have a workflow problem.
We've spent decades developing practices for building software. We have discovery processes, architecture reviews, code reviews, quality assurance, deployment checklists, and postmortems because experience taught us that the best software doesn't happen by accident.
Now we're entering a world where humans and agents build products together, but we're still improvising the workflows. Everyone is experimenting. Everyone is inventing their own way of working. Some of those approaches are excellent. Many aren't. Very few have been written down, tested across different kinds of projects, and refined over time.
Training for People
That's what these skills are intended to become: Training.
Not training for the models, but for the people working alongside them. The goal isn't to teach an agent how to write better code — giant labs are holding that down. No, my goal is to teach people and agents how to arrive at the why together, because once that foundation exists, almost everything that follows is easier.
Better decisions lead to better implementation. Better context leads to better output. Better workflows lead to better products.
I don't think that's a temporary advantage. I think it's the next discipline our industry has to learn.
Skills and principles
The library is where this training lives — playbooks for judgment, and the doctrine behind them.
The Next Decade
The companies that build exceptional software over the next decade won't necessarily be the ones with access to the newest models. They'll be the ones that develop better ways of thinking, better ways of making decisions, and better ways of working with agents. The technology will continue to improve whether we're ready for it or not. The question is: are we willing to improve ourselves, to take advantage of it?
That line of thinking led somewhere else too: if agents are going to build software with us, they deserve better software too.