The Answers Are Getting Cheap
Finding answers used to be the hard part. Now the hard part is knowing which questions to ask — and not handing the Why to an agent.
Knowing Things
I've been thinking a lot lately about how much of being a good software developer used to be tied to simply knowing things.
When I started out down this path of the dev, finding the answers to the questions I had, and I had a lot, seemed like a large portion of the work. How you found those answers ran the gamut from leafing through books to rifling through source code. Eventually we had Stack Overflow and Google as shortcuts. If you were really lucky you had someone in your life that was farther along the path than you, and you could take your questions to them.
Eventually you climbed that particular mountain enough times that you became the one others ran to for wisdom and guidance. This wisdom, earned through fighting through so many unknowns, is what we call experience. The thing is, AI is drastically changing that process, since finding an answer is now one quick prompt away. It's now, in some cases, the easiest part of creating something.
The Trap
It's very appealing, seductive even, to leave all the decisions up to the agent. Hell, maybe I don't even need to know how to implement a solution anymore. I can just trust the agents to make all the right decisions.
And that, my friends, is the trap.
You see, knowing the answers was only ever one small part of what that earned experience gave us. A larger part, at least for me, was learning to see through the chaos that software development can be at times, and asking the questions that other folks don't even think about.
Useful Baggage
A coworker tells you not to worry, the DB has backups turned on. You immediately ask, "When was the last time we ran a restore?" A junior developer adds a new dependency to a project, you immediately ask how well it is maintained and how old it is. What other dependencies does it bring in with it, and how well are they maintained?
Nobody taught you to ask those questions. You ask them because you have been on the receiving end of situations where not asking them blew up in your face. As we grow as developers, as engineers, we create baggage that we carry around. Some of it is good and useful, formed by years of dealing with and resolving problems, either from our own ignorance or someone else's.
Eventually you mature in your journey such that the way you approach a problem changes. You bring a healthy level of suspicion. You ask better questions earlier because you remember what happened when those questions were asked too late, or not at all.
The Other Side of the Equation
I wrote recently in An Audience of One about a possible future I can see, where AI would allow people without formal training, or years of experience, to build new unique things for an increasingly smaller and smaller audience, even down to an audience of one.
I'm still convinced that could be one of the most critical things to come out of this current wave of AI adoption, but there's another side of that equation that we need to figure out to give this new community of citizen makers the best shot at succeeding.
If we eliminate the years normally required to learn the ins and outs, dos and don'ts of building software, we're also removing the processes that accumulate all of the useful baggage I just mentioned. This is the component of developing great software that agents can't replace, at least not yet.
An agent can easily answer a security question if asked. Of course, if the question is never asked, that doesn't really help now, does it? This goes for accessibility, privacy, architectural decisions, scalability and all the other things that make a piece of software succeed or fail.
Work For You, Not Think For You
You can't let the agent think for you. You let the agent work for you. Vastly different things.
Look, agents and the LLMs that back them know an extraordinary amount of information, more than I do certainly, and that will be more and more true as they are further developed and evolve. Knowing isn't understanding. Knowing isn't creativity. Without a human's ability to filter that knowledge through intuition, creativity and all that accumulated baggage, it's just information.
This is where I believe the current obsession with having agents do more of the work, more of the thinking, is moving us into dangerous waters.
We've become so enamored with what it appears these systems can do that we've stopped employing discernment around the answers that are returned. We don't want any answer, we want the rightanswer. Even worse, we've started convincing ourselves that the role we play in this new workflow is to simply provide some context in a prompt, then sit back and wait for the agent to return the finished project.
I don't think that's the future we need or that we should want. And it doesn't have to be.
Direction and Clarity
The more powerful and capable these systems become, the more important our role becomes, in my opinion. Specifically, the ability to apply critical thinking and judgement, filtered through our experience, to their output. Not because we need to understand every line and function that is returned, but because someone needs to maintain tight control of where the development is going and whether it really accomplishes the goals we have.
This is why I don't go in for the belief that experience suddenly isn't as important in a world where an agentic system knows more information than any one person does. Because again, information isn't wisdom or discernment. Information isn't creativity. Information is fuel for those things, not them.
This is what I think humans, you and I, need to become better at understanding and become more proficient at applying.
Our job, our purpose, isn't to compete with agents on how much information we can jam into our heads, or synthesize that information into code. That war is over, I'm afraid. No, our value, our purpose is to give direction and clarity to that information so that the code that is produced is right.
Agents will still do the work, but we'll still be responsible for the ultimate outcomes.
The Citizen Maker Gap
And that brings us back to the folks I talked about in An Audience of One, the "citizen makers," as I have dubbed them, because as you can likely see, there is an obvious flaw in my pontifications up to this point. What do we do when the maker in question doesn't have 20-plus years of experience to help them discern what is right and drive the process and workflows?
The answer can't be that they have to become software devs before they can take advantage of this brave new world. That flies in the face of what is so exciting to me about this moment in history. With that being said, we can't just shrug our shoulders, abdicate our role completely and rely on these increasingly capable agents and assume it will all work out.
What we need is a solid middle ground. Finding it has been my most recent obsession.
Basically, it boils down to:
How do we take that useful baggage that a dev builds up over years of writing code, and make it available to someone who hasn't had that journey?
And look, I'm not talking about teaching people how to write code. Focusing on that misses the point entirely. Agents can write code. What we need to figure out is how we help "citizen makers" confidently drive and direct the work, ask the right questions and recognize when something doesn't smell right, so to speak.
The Middle Ground
Conveniently, this is exactly the point of The Principles and the skills built atop them. They aren't there to tell an agent how to write a React component, Python function or draft a database schema. They are designed to establish how the work should be approached by guiding the person to the Why for this specific project.
The Why is where we humans come in.
Once the human knows the Why, the agent can run with the How.
This is where the skills that I have built on top of The Principles come in. While The Principles help you establish the Why, the skills help protect the Why while giving the agent the context needed to effectively tackle the How. They do this by guiding you through a multistep process that replicates, as much as makes sense, the questioning process of an experienced developer. The questions that have become instinctual through years of doing this thing.
That setup is important. I'm not trying to turn "citizen makers" into software developers. I am trying to equip them with tools that will allow them to successfully direct and manage software development so that the product that is produced is the best it can be.
I can give them some of the most important baggage that we all carry around as devs, not only so that they can ensure the agent is solving for the correct Why when dealing with the How, but so that they can understand why they're building what they're building, recognize the decisions that actually matter and, most importantly, maintain control over where the work is going.
Protect the Why. Direct the How.
Principles establish judgment. Skills replicate the questions experienced developers ask by instinct — so citizen makers can drive the work without becoming developers first.
Why Isn't Getting Cheap
That's the middle ground I am working towards. The answers to the Why aren't getting cheaper, the How is. The Why is now becoming potentially the most expensive mistake vector in software development.
This is where we, as humans, should be focusing and spending our time.