AI makes development faster. Can your organization decide what matters?

I recently spoke with a few industry colleagues about how AI is changing development work. All of them had noticed a similar shift: as creating code becomes faster, more of the difficulty lies in understanding what is actually important for the company to achieve.

The conversation also touched on what this means for developers. Business understanding, product judgment and the ability to question the purpose of a request become increasingly valuable when implementation takes less time.

These were observations from a handful of conversations, and the pace of change varies considerably between teams. Engineering still involves difficult work in architecture, security, integration and reliability. But the pattern was familiar enough to make me think about what companies are doing to prepare for it.

I have written before about how the bottleneck can move towards choosing, understanding and validating the work. The question I want to explore here is what the organization needs to change when that starts happening.

If we expect more people to understand what matters to the business, how do we give them the context and authority to act on that understanding?

Faster development puts pressure on how decisions are made

Many organizations depend on a relatively small group of people to carry the reasoning behind their priorities. A founder understands the commercial urgency. A product manager remembers the customer conversations. A CTO knows why a particular technical investment matters now. Together, they hold much of the context that makes a request understandable.

The rest of the organization often receives a more compressed version: a roadmap item, a ticket, a deadline or a feature description.

That arrangement already creates friction. When implementation becomes faster, I expect the friction to become more visible. Teams can reach the next decision sooner, explore more possible solutions and raise questions that the original request never anticipated. If those decisions all need to return to the same few people, the queue simply moves upstream.

Another possibility is that teams act independently with incomplete context. Each team makes reasonable decisions based on what it can see, while the organization gradually accumulates work that serves different interpretations of the strategy.

Neither outcome is inevitable. Both are reasons to examine how strategic understanding is shared as execution capacity increases.

The ability to build faster raises the value of being able to decide well, close to the work.

The same developer, with different context

Imagine a SaaS company that helps small businesses manage invoicing and payments. New customers are taking too long to get started, and the product team wants to improve onboarding.

A developer receives a ticket to build an onboarding checklist. It specifies five steps, a progress indicator and reminders for users who have not completed the setup. With AI assistance, the developer can produce a working version quickly, review the implementation and prepare it for release.

The work may be technically excellent. Yet the ticket gives the developer little basis for evaluating whether a checklist addresses the reason customers are struggling. The important product decision has already been made somewhere else.

Now imagine the same developer, with the same tools, receiving a fuller picture.

The company wants to help more small businesses get paid reliably. One current priority is helping new customers reach their first useful result. Customer Success has noticed that many new administrators stop when asked to import invoice data because they are unsure which file to use. The team wants to increase the share of new accounts sending their first valid invoice within seven days, and it has room to investigate how.

That context changes what the developer can contribute. They can speak with Customer Success, inspect where imports fail and ask whether customers understand the required format. They might suggest a clearer example file, better validation messages or a short assisted setup session before committing to a new onboarding flow.

AI still helps them build quickly. It also makes it easier to test a small change and revise it once they have evidence. The checklist remains an option, but the team has a basis for deciding whether it is the most useful one.

The difference comes from giving technical skill and implementation speed a meaningful problem to work on.

Business understanding needs organizational support

It is reasonable to expect developers to become more curious about customers, commercial priorities and the outcomes their work supports. That expectation also creates an obligation for leadership.

People need access to customer evidence and to colleagues who understand different parts of the business. They need time to investigate uncertainty and enough authority to propose a different approach when the original request appears weak. They also need to know which decisions they can make themselves and which involve commitments or risks that require a wider discussion.

If the organization measures contribution mainly through completed tickets and treats questions about purpose as delays, it makes that development harder. The message people receive through everyday decisions will outweigh the invitation to “think more commercially”.

Product and engineering leadership have an important role here. They can help teams understand the trade-offs, bring relevant evidence into the conversation and make the boundaries of autonomy clear. That allows more people to exercise judgment while keeping accountability visible.

How NSF makes the reasoning accessible

This is one reason I believe the North Star Framework becomes increasingly useful as AI changes the pace of development. In the version I work with, it gives the organization a shared structure for connecting long-term direction to the problems, goals and work being pursued now.

The five connected layers are:

North Star → Product Drivers → Top Problems → Current Goals → The Work

Each layer contributes context that is easy to lose when someone sees only the final request. The North Star describes the direction. Product Drivers express what we believe will move us towards it. Top Problems make the currently important obstacles explicit. Current Goals describe the changes we want to achieve during a cycle, and The Work captures the activities and experiments we believe will help.

For the invoicing example, one branch could look like this. The figures below are hypothetical:

The title and metric serve complementary purposes. The title makes the intended direction or change understandable, while the metric gives people something concrete to examine. The connections show why the work is being considered and which assumptions need to hold for it to matter.

Successful imports, for example, may help customers send invoices sooner. That relationship needs to be checked. Sending an invoice also does not guarantee timely payment. Making these links visible gives the organization a way to discuss the limits of its current reasoning and improve it.

For a developer, the branch creates several useful options. They can question the diagnosis, suggest a smaller experiment, identify a dependency or explain why a proposed technical change would help. Colleagues in Product, Sales and Customer Success can contribute their own evidence to the same discussion.

NSF makes the reasoning behind the work available for people to use, challenge and improve.

Keep faster execution connected to learning

The board needs to remain part of the conversation as the work progresses. Otherwise, it becomes a record of assumptions that everyone gradually stops examining.

Suppose the team improves import completion, but the share of customers sending an invoice stays unchanged. That result matters. It may reveal another obstacle, or suggest that the original problem affected fewer customers than expected. The team needs to bring that learning back into its priorities before generating another round of improvements around the same assumption.

This is where the recurring rhythm of planning, follow-up, demos and reflection helps. Teams return to the intended outcome, examine what changed and decide what to continue, adapt or stop. Within that rhythm, they can run smaller experiments and respond to evidence as it emerges. Faster implementation does not require waiting until the end of a cycle to learn.

AI can support this work through prototypes, analysis and implementation. Customer responses and meaningful business results may still take time to observe. The organization needs to make room for those different speeds.

The detailed execution can stay in the tools teams already use. NSF Board provides the shared view of direction, problems, goals and progress, without requiring every technical task or operational responsibility to appear there.

Leadership has to make context usable

The practical starting point can be small. Choose one active initiative and ask the people working on it to explain what should change for customers or the business, which problem currently prevents that change and what evidence would make them reconsider their approach.

If the answers differ, make the reasoning visible together. Identify the missing evidence, clarify who can decide what, and give the team a measurable outcome to work towards. That conversation is already useful before any new tool is introduced.

NSF gives it a structure that can be maintained across teams and over time. It still depends on honest priorities, customer contact and a willingness to revise assumptions. A neatly connected board cannot compensate for avoiding those conversations.

As AI improves and more work can be implemented quickly, I expect the gap between execution capacity and shared understanding to become increasingly consequential. Companies that address it give more people the ability to turn their expertise into useful decisions. Companies that leave it unresolved risk making the same few decision-makers busier while everyone else waits or guesses.

For me, that brings the discussion back to a central responsibility of leadership: creating enough clarity that people can make good decisions without you being in the room.

If your team can build faster than it can explain why the work matters, that is a useful place to start. Pick one initiative and map its connection to the problem, the intended outcome and the company's direction. You can use NSF Board to make that reasoning visible and keep learning from it together.