Almost a year ago, I wrote about my early experiences with AI coding. At the time, I used it primarily to prototype ideas, build customer demos, evaluate vendors, and explore technical feasibility.
A lot has changed. AI coding tools have advanced incredibly quickly and have become part of everyday software development. In its 2026 Developer Ecosystem Survey, JetBrains reported that 90% of professional developers surveyed were using AI coding agents at work at least weekly, with 68% using them daily.
Fortunately, at PubNub, we are encouraged to experiment with AI within appropriate guardrails. We are pushed not only to use AI to work more efficiently, but also to think AI-first about our products and processes. Here are some of the things I have learned one year later.
Build, learn, rebuild
One of the biggest changes is how quickly we can go from an idea to something tangible, especially with greenfield, zero-to-one products. There have been times when we started working on a significant capability in the morning and had something meaningful to demo by the next morning.
That does not mean AI makes every kind of development faster. The biggest gains I have experienced have been with greenfield work, prototypes, and well-defined tasks.
Learning through building: The first version is rarely the final one. We created a command-line tool, learned from putting it in front of people, and eventually overhauled it based on what we learned.
The cycle can become very compressed:
- Define what we are trying to accomplish
- Build enough to see it working
- Demo it and gather feedback
- Change direction
- Build again
What “enough” means: This follows a familiar principle from lean product development: build enough to test an assumption, learn from it, and decide what to do next. AI makes it easier to do this before investing in making something production-ready.
AI also changes what “enough” can look like. We can build a larger, more polished prototype in the same amount of time, which may help customers provide more realistic feedback. But additional functionality can also distract from the core assumption we are trying to test. The goal is not to build the smallest thing possible. It is to build enough to learn.
For a product manager, this is powerful. I can explore an API, create a working UI, investigate technical feasibility, or put something tangible in front of a customer without pretending that I am now a software engineer.
The tradeoff: Imagine spending a day building something only to have it significantly changed or replaced the next day. Do that repeatedly and the pace can become exhausting. There is also a risk of moving simply because we can, before we have enough of the right feedback to know whether changing direction is warranted.
Faster development is useful only if we understand what we learned.
Just because we can build it does not mean we should
AI is very good at imagining a complete, mature product. Ask it to create a way to charge for something, and it may propose subscriptions, usage-based pricing, multiple pricing tiers, free trials, invoices, refunds, administrative tools, and review or moderation workflows. These ideas are not inherently wrong, and a mature product may eventually need many of them. But adding them before we have validated the basic experience increases complexity and makes it harder to learn what customers actually value.
Where context matters: That is where I often have to step in and narrow the scope. Just because we can build it does not mean we should. Product context and judgment determine:
- Who we are building for
- What problem we are solving now
- What customers, Sales, and Account Management are telling us
- The stage and maturity of the product
- How it supports product and company strategy
- What is intentionally out of scope
- What success looks like
Some of this context can and should be provided to AI through better prompts, reusable context, Skills, and other instructions. But someone still has to decide which context matters, what tradeoffs are acceptable, and whether the result drove adoption, engagement, growth, or revenue. AI can help analyze the outcome, but it cannot own it.
Requirements for humans and AI
There are now two audiences: I increasingly write requirements knowing they may be consumed by both humans and AI coding tools. This mirrors another shift happening in our products. Just as we think about user experience, or UX, for people, we are beginning to think about agent experience, or AX, for AI agents consuming APIs, documentation, tools, and workflows. For some products, an AI agent may eventually become the primary direct user, acting on behalf of a human.
The underlying challenge is similar. Whether the audience is a person or an AI agent, we need to provide enough context, make the expected behavior clear, and reduce assumptions. AI can help develop a requirement, identify missing considerations, or check whether an idea is realistic. But I also have to keep it focused on the problem, use cases, target end user, expected behavior, and desired outcome.
How we solve it: I do not necessarily want the requirement to prescribe the technical implementation before the team has explored it. Engineering leads the technical approach, while product, design, and engineering work together to shape the solution. Better prompting and better context help, but knowing what to ask for and what to leave open still matters.
UX still needs a lot of humans
AI has gotten much better at creating interfaces quickly, but good UX is still inconsistent. Sometimes the output is surprisingly strong. Other times it misunderstands the workflow, prioritizes the wrong information, creates unnecessary complexity, or produces something that technically works but does not feel intuitive.
A polished interface can also create a false sense of completion. Because it looks finished, it is easy to overlook whether the workflow actually makes sense to the person using it. AI can help us get to something tangible faster, but it does not remove the need for user feedback, UX expertise, and iteration.
We are all still figuring this out
One of the most interesting parts of the last year has been how much we are learning from each other. When I catch up with former colleagues, meet people in the industry, or talk with product managers and engineers at other companies, we inevitably compare notes: What tools are you using? What are you letting AI do? Where are humans stepping in? What is working? What broke?
I do not think any of us can be particularly confident about exactly what AI coding will look like a year from now. The tools will change, our processes will adapt, and some of today's best practices will probably look outdated surprisingly quickly.
A year ago, I wrote that the familiar product principles of focus, clarity, iteration, and documentation still applied to AI coding. One year later, I would add one more: judgment. The context has changed faster than we expected, but the fundamentals have not.
Try it yourself
Want to see how quickly AI can turn an idea into something tangible? Ask an AI coding tool to use PubNub to build a simple group chat or multiplayer game that you can invite your friends to. Start with the PubNub MCP Server to give the tool the product context and PubNub capabilities it needs.
As AI suggests live polls, online status, notifications, moderation, leaderboards, administrative tools, and more, notice how quickly a simple idea expands. It can help you build all of them. The judgment comes in deciding which ones matter now and which can wait. If you want to talk through an idea or whether PubNub is the right fit, contact us.
