I love how much a small team can build now.
An idea that would have sat in a backlog can become something you can actually use. You can try things you would previously have talked yourself out of. The cost of getting started has dropped, and I think that is a huge opportunity.
But I keep coming back to something that feels almost boring to say.
We still struggle to decide what we are building.
AI has made development faster. It has not made everyone in the room mean the same thing when they describe a feature.
And from what I have felt building with it, a lot of the time still goes into rebuilding. You get something working, realize it was built around an assumption nobody discussed, and start pulling it apart.
That problem existed long before AI. We can just get further into the implementation before dealing with it now.
There is a version of the AI conversation that goes: building is easy now, so just make it and figure it out.
I understand the appeal. Sometimes that is exactly the right thing to do. If you need to see whether an interaction feels good, make a rough version. If you have a question that a prototype can answer, go answer it.
Where I get uncomfortable is when we start treating a working prototype as evidence that we understand the product.
You can have something running and still be very unclear about what it needs to become.
Consider something as ordinary as “let users share a project.”
Sounds small. You can probably get a share button working quite quickly.
But what does sharing mean? A public link? An invitation? Can the other person edit? Do they see future changes? Can access be taken away? What happens to their contributions when it is?
Those answers affect how you build the thing. If everyone has a different answer in their head, the first implementation quietly picks one for you.
Then someone sees it and says, “Oh, I assumed it would work differently.”
Nobody necessarily did a bad job writing the code. The code may do exactly what it was asked to do. The team just never finished the conversation.
I think this is easy to miss when you are moving fast. Every individual addition looks manageable. Add this screen. Change that flow. Support one more case.
After a point, you have a collection of decisions that made sense individually but do not fit together very well. Extending the project becomes harder than it should be. You start thinking about a rewrite.
The speed was real. So was the rework.
This is why I feel spending more time on planning matters more now. Especially in a small team, where a few people can turn an unclear idea into a surprisingly large amount of software.
I want to be able to describe the core experience before building too much of it. Who is using this? What are they trying to get done? What belongs in this version? What are we deliberately leaving for later? Which assumptions would be painful to reverse?
Write those answers down. Sketch the flow. Walk through an actual example together. A spec earns its place when it catches a disagreement while changing our minds is still cheap.
The length of the document is beside the point. Two pages that settle the important questions can be more useful than twenty pages that repeat the idea in different words.
There is a limit to this, obviously. You cannot plan your way into knowing everything.
Sometimes you rebuild because a user shows you that your original idea was wrong. That is useful learning. I would happily take faster development if it helps us get to that realization sooner.
But rebuilding because we learned something from users feels very different from rebuilding because we never agreed on what “sharing” meant.
I want to get better at telling those apart.
AI can help with the planning too. It can question a spec, suggest cases we have missed, or produce a few versions of a flow for us to compare. I find that a much more interesting use of it than rushing straight to implementation every time.
Still, someone has to decide which of those possibilities matters. A detailed answer is not automatically an agreed requirement.
This also changes how I think about product and engineering working together.
I get frustrated when the ease of creating a demo becomes “engineering should be easy now.” At the prototype level, yes, building has become dramatically easier. I am excited about that.
Once people depend on the product, there is more to answer for. Their data needs to survive changes. Permissions need to behave consistently. Failures need a way back. The next feature needs to fit without breaking what they already use.
There is still a lot of engineering in that.
And good engineers have something valuable to contribute before any of it is written. They understand what is possible, where the difficult choices are, and when there is a simpler way to solve the same problem.
An engineer might hear a requirement and say, “We can get the user what they need without building that entire workflow.” Or, “If we expect teams to use this later, we should make this decision differently now.”
That can change the product itself. You lose those options when engineering only enters the conversation after the solution has been decided.
I do not think this means engineers automatically know what users want. Knowing what can be built is only part of deciding what should be built. Customer understanding and business judgment matter just as much.
But I do think defining the product has to be shared work. A PM cannot hand over all the uncertainty in a ticket and expect implementation speed to resolve it. An engineer cannot ignore the purpose of a feature and expect a technically sound result to make it useful.
The opportunity for small teams is that this conversation can happen directly. The people understanding the problem and the people building the solution can work through it together, then use AI to move quickly on what they have learned.
I am more optimistic about that than about the idea that we can skip the thinking now.
We have more room to experiment. More chances to build something good with fewer people. More ways to test an idea before committing to it.
I just want more of that speed to survive past the first demo.
For me, that means getting clearer about what we are building, early enough that we do not have to discover it by rewriting everything.