When everyone can make, judgment becomes the work.
AI has widened access to making. A convincing interface, prototype or presentation can now appear before the underlying problem is understood. At the table, that was both an invitation and a source of unease: the ability to produce something is increasingly mistaken for the ability to design it well.
The distinction leaders returned to was judgment. Who is this for? What makes this direction right? What has been left out? A polished output cannot answer those questions on its own. Experience matters when it helps someone recognise consequences, not simply when it confers seniority.
There was optimism about building directly and experimenting more freely. There was also frustration with work that looked finished but had not been thought through. The opportunity is to shorten the distance between an idea and a test, without shortening the thinking that makes the test useful.
Ask for the reasoning behind an output, the alternatives considered and the evidence that would change the decision.
Protect the practice that builds taste.
When a tool can complete a task immediately, the unfinished stage can start to feel like failure. But sketching, trying alternatives, observing people and struggling with a problem are also how designers build discernment.
Leaders described pausing before prompting, writing ideas down independently and making space for exploration that does not need to become a deliverable. A more restrictive suggestion was to delay access to AI for people still learning the foundations. That remained a proposal, not an agreed approach.
The unresolved question is how to teach judgment without making people rehearse yesterday’s workflow. A deliberate pause can deepen a decision. A blanket ban can also prevent learning. Teams need to explain what a learning exercise is protecting, not simply ask people to slow down.
In a critique, ask what the designer noticed, what they rejected and what they learned. Evaluate understanding alongside execution.
“There are a lot of human things that we have in our control, but we choose to outsource.”
The interface is only one layer of the system.
Systems thinking connected several strands of the conversation: placing someone on the right project, enabling their growth, understanding a customer’s constraints and anticipating the effect of a product decision elsewhere.
Leaders worried that a working front end can hide a fragile system. Shipping code brings responsibilities beyond the visible screen: dependencies, data access, testing, security, observability and recovery. These are not reasons to exclude designers from code. They are reasons to make ownership and review explicit.
The same principle applies inside a team. Optimising one function in isolation can move the burden to another. Faster generation can leave engineering with more to review, or push basic questions about users and success to the final deployment stage.
Before calling a prototype production-ready, identify who reviews it, how success is measured and how a failed release is reversed.
An interface is not the whole product
Design for the customer’s constraints, not your own access.
The table described very different conditions for experimentation. Some environments provide extensive AI access; others allow only a narrow set of approved capabilities. Neither experience is a reliable proxy for what customers can afford or use.
Usage-based costs can turn a delightful workflow into an expensive habit. Leaders raised a practical risk: a team with generous access may design a product whose economics make little sense for the people buying it.
There was a counterview, too. As capability improves and costs change, today’s token constraints may become less visible. The disagreement matters. Design should account for present costs while avoiding the assumption that today’s pricing is permanent.
Explore repeated use, not just a single successful demo. Make cost, latency and recovery visible during evaluation.
Explore the trade-off
A cheap action can become an expensive workflow.
Illustrative model only: 1 versus 3 abstract cost units per action. No prices, usage data or results from the event are represented. The relationship shown is deliberately simple.
A flatter team still needs a place to grow.
Leaders described the tension between being closer to the work and being pulled into every decision. Flatter structures can reduce distance, but they can also consume the time needed for strategy, coaching and cross-functional relationships.
Expectations were moving faster than the time available to develop people. The conversation did not resolve how a leader can support everyone equally under pressure. It did make that limit visible.
There was a strong thread of investing in people beyond their immediate usefulness to an employer. Alongside it sat a harder question: what can a leader honestly promise when organisational decisions are outside their control? Care requires candour about those limits, rather than reassurance that cannot be kept.
Make growth support concrete: clear decision rights, a realistic next responsibility and time to learn with feedback.
Boundaries are something leaders demonstrate.
The discussion moved beyond tools into identity, exhaustion and the difficulty of separating commitment from constant availability. A leader can value their work deeply and still need a life outside it.
Leaders spoke about making expectations explicit, distinguishing an emergency from an internal habit and using scheduled messages instead of triggering weekend notifications. These were ordinary behaviours with cultural consequences.
The point was not that every role can follow the same hours. It was that unspoken expectations travel down a hierarchy. When leaders protect time themselves, others have more permission to do the same. More automated output should not quietly become a demand for more human availability.
Agree what counts as urgent. Say when a response is expected. Model the boundaries you want the team to believe.
What does your own availability teach the team to expect of itself?
Move upstream, before the brief becomes the answer.
If design’s value is defined entirely by producing the final artefact, easier production puts that value under pressure. Leaders discussed moving earlier into the work: identifying the right problem, framing options and connecting experience decisions to business outcomes.
This is not an argument for abandoning craft. It is an argument for giving craft a better problem to solve. A large quantity of generated research or pitch material has little value if someone still needs to turn it into a relevant decision.
The table questioned reliance on cost advantage alone. The more durable distinction was framed around impact, specialist knowledge and the ability to understand a system. None of these guarantees job security. They do provide a more useful direction for development than competing on output volume.
Write the decision a piece of work needs to enable before generating the material that supports it.
Where design can contribute
Curiosity needs room for disagreement.
AI adoption did not fall neatly along age or seniority lines. Leaders described enthusiasm, scepticism and uneven confidence across experience levels. The conversation challenged its own assumptions about who is willing to learn.
Questions from less experienced people can reveal expectations that have become invisible to leaders. Asking why a tool is necessary, what a new responsibility means or how someone will be supported is not automatically resistance.
The table also recognised the limits of a room made up of experienced leaders. Future conversations would benefit from more career stages and more varied perspectives. Learning across generations should involve listening in both directions.
Invite the question you find inconvenient. Explain the purpose of a change and let the people affected help evaluate it.

