AI tools have made it easier than ever to build and ship software. On one of my recent projects, I’ve seen firsthand how quickly a team can generate features, prototype ideas, and release new functionality.
But I’ve also noticed something else.
Just because we can build faster doesn’t mean we’re learning any faster.
On this project, the client frequently encourages the team to push something out quickly so we can “see what happens.” In theory, that’s solid product thinking. Ship something small, gather feedback, and iterate.
Shipping Without Learning
In practice, something different has been happening.
We ship a feature, move immediately on to the next one, and rarely pause to understand what we learned from the last release. There’s no clear owner for gathering feedback, and success metrics are vague or undefined. What was intended to be a learning loop has become a steady stream of new features.
As a delivery lead, I was left wondering: are we actually learning, or are we just moving faster?
When the Team Starts to Feel It
Over time, the consequences became clear. Developers optimized for speed, and technical debt accumulated. Features were released before the team had time to think through the user workflow or how they fit into the larger product. The user experience started to feel fragmented.
The strongest signal came from the team itself. After releasing to production, a developer told me they felt deflated. The feature had been criticized, and they believed they could have designed something much better with more context about the user problem and a little more time to plan. The issue wasn’t capability, it was a lack of clarity.
The Moment It Became Clear
About three months into the project, this came to a head during a retrospective. A couple of developers said they weren’t confident we were building the right things. We were shipping regularly, but it wasn’t clear what problems we were solving or what we had learned along the way.
I’ve seen versions of this pattern across many consulting projects. Product discovery is hard work. It requires understanding users, clearly defining problems, and deciding how to measure success before building. Many organizations either lack the roles to do this work or don’t see its value.
Recently, I saw this same pattern play out while discussing a new payment subsystem. We were talking about architecture and resourcing when the lead said, “I’m still trying to figure out what success even looks like. We’re talking about building it, but what does ‘success’ actually mean for this version?”
Faster Doesn’t Mean Better
That’s the tension I keep coming back to. AI is very good at helping teams answer the question, “How do we build this?” It’s much less helpful in answering, “Should we build this?” or “How will we know if it worked?”
Those questions still require product thinking, user understanding, and intentional measurement.
Shipping quickly can be a powerful way to learn, but only if teams define what they’re trying to learn and make time to reflect on the results.
Without that, shipping faster doesn’t necessarily lead to better outcomes. It just leads to more software.