An analysis through constraints, mastery, and decision levels.

1. Introduction: A Contemporary Illusion

In both engineering and design practice, it is obvious that we never design an object entirely from scratch. An industrial product integrates standardized components: screws, connectors, protocols, and software libraries. It would be absurd to redesign an M4 screw for every project. Yet, no one disputes that the engineer who chooses an M4 screw over an M5 is making a conscious design decision.

Similarly, developers remain designers when they use an existing library or a payment module ready to plug into their application. They don't design everything, but they certainly design something: the integration, the architecture, the trade-offs, and the dependencies.

Knowing where one's own design scope begins and ends is already a daily challenge for any designer. AI simply makes this question more frequent and harder to settle.

This seemingly trivial observation becomes highly problematic in today's context of generative tools. When an AI system produces a complete 3D model, an interface, or a functional application from a simple description, the question arises differently: is this still design, or is it a form of assembling pre-existing "off-the-shelf" or "on-demand" solutions, masked by the power of generation?

This is the exact same question behind very practical debates: do people practice "vibe coding" truly design? Do they produce useful things? Or are they mostly building fragile, unmaintainable, or even dangerous systems?

In other words, if we accept that we never design everything, where is the boundary between designing, assembling, delegating, and using an off-the-shelf solution?

2. Definition: Designing is Solving Constraints

To answer this question, we must clarify what we mean by "designing." I propose an operational definition:

Designing consists of resolving a set of constraints to achieve a given intention.

This definition relies on three inseparable elements: an intention, constraints, and a resolution.

Let's take a simple example. Choosing a screw for a mechanical assembly isn't about inventing a new thread geometry; it is about balancing multiple constraints: space, mechanical resistance, material compatibility, ease of assembly, cost, and availability.

Choosing an M4 screw instead of an M5 therefore means resolving these constraints in a given context. The act of design does not lie in the creation of the screw itself, but in understanding and balancing the constraints that justify this choice.

This distinction allows us to introduce a fundamental separation between two scenarios.

In the first scenario, the individual understands the constraints and how they are resolved. They can explain their choice, modify it if conditions change, and anticipate the consequences.

In the second scenario, they use a solution without understanding the mechanisms that make it valid. They can see that "it works," but they can neither justify nor adapt the solution reliably.

The first scenario is design. The second is merely assembly or usage.

We can therefore visualize a continuous spectrum of design, ranging from designing everything, to designing only certain elements, assembling existing solutions, buying off-the-shelf, or simply using a pre-existing system.

3. Levels of Design: Abstraction and Granularity

This definition must, however, be complemented by an essential observation: design never occurs at a single level. It unfolds across at least two distinct dimensions.

The first is the level of abstraction, which corresponds to the nature of the decisions being made. We can simplify this into several design levels: strategic, functional, technical, and operational.

Simply put, we don't just design the technical part of a product. We also design its value proposition, its aesthetics, its user experience, its business model, and its place within a broader ecosystem.

The second dimension is the level of granularity, representing the scale of the system being considered: designing an entire product, a sub-system, a component, or a single detail. In practice, it is extremely rare to design 100% of any product.

These two dimensions are independent. You can design at a high level of abstraction on a very fine element—for instance, by defining the behavior of a single button in an interface. You can also design at a technical level of abstraction on a broad system, such as defining the global architecture of an application.

The example of a non-developer colleague using AI to generate an application perfectly illustrates this distinction. This individual can precisely define the expected features, interaction rules, and design system principles. They are working at a high level of abstraction. However, they do not necessarily master the structure of the generated code or the underlying technical mechanisms.

They aren't designing the technical resolution of the constraints, but they are certainly designing their formulation.

4. The Critical Dimension: Mastery

Beyond abstraction and granularity, a third dimension proves to be decisive: mastery over the resolution of constraints.

This mastery is more than superficial knowledge. It implies the ability to explain why a solution works, modify it precisely, and anticipate the effects of a change in constraints.

It is this dimension that rigorously distinguishes actual design from mere usage.

We can illustrate this idea with two contrasting scenarios in software development. In the first, a developer implements a critical function while fully understanding the data structures used, performance constraints, and maintenance implications. In the second, a user copies a code snippet generated by an AI without understanding its internal logic.

In both cases, a functional result can be achieved. But only the first scenario truly qualifies as mastered design.

The second approach can be highly useful. It allows for quick testing, prototyping, and learning. But it must not be confused with robust, engineered design.

5. The Design Space

By combining these three dimensions—abstraction, granularity, and mastery—we can better map and understand different forms of design.

Certain configurations represent robust forms of design. For instance, high mastery at a technical level across a broad system characterizes complex systems engineering, where the architecture is built to be coherent and scalable.

Similarly, high mastery over fine details represents localized technical expertise, which is absolutely essential for execution quality.

Other configurations are more ambiguous. High abstraction combined with low mastery, for example, represents situations where one specifies functionalities without understanding their implementation. This is typically the case with naive use of generative tools, where the user expresses intentions but entirely delegates constraint resolution to the machine.

Finally, some configurations are clearly risky, particularly when the granularity is broad and mastery is low. In this case, an entire system is deployed without any understanding of its internal mechanisms, creating heavy dependency and severely limiting future scalability.

The value of this framework is that it avoids a binary view. It is not about declaring whether someone is designing or not. It is about asking exactly what they are designing, at what level, across what scope, and with what degree of mastery.

6. The Impact of Artificial Intelligence

The rise of generative artificial intelligence tools is profoundly transforming how design activities are distributed across this space.

Traditionally, producing a system required understanding its mechanisms. Production and comprehension were deeply intertwined. AI introduces a separation: it is now possible to produce complex outputs from high-level instructions without mastering the underlying technical layers.

This shift has two major consequences.

First, it allows non-specialist individuals to operate at high levels of abstraction. They can define design intent, formulate constraints, produce prototypes, and get tangible results incredibly fast.

Second, it creates an illusion of design. The mere act of producing an artifact can be mistaken for the ability to master its internal logic.

Yet, as we have seen, design does not lie solely in the generation of the result, but in the understanding of how the constraints are resolved.

AI is not eliminating design. It is simply blurring the lines between formulation, production, delegation, and mastery.

7. The Case of Vibe Coding

"Vibe coding" perfectly illustrates this ambiguity.

On one hand, it would be too easy to dismiss it as an amateur practice destined to produce poor-quality systems. In many cases, it allows for rapid prototyping, user-need testing, idea materialization, or building extremely useful internal tools.

It can even improve the formulation of requirements, as it allows the person who actually experiences the constraint to produce a first, concrete response.

An operator automating an internal process often understands operational constraints better than anyone. A business lead building the first version of a product can quickly validate a value proposition. A designer generating an interactive interface can rapidly explore real-use scenarios.

In these cases, genuine design is happening. But it is located at the level of intention, usage, business rules, or functional exploration.

On the other hand, it would be naive to assume that this rapid production is always sufficient.

The trouble begins when a prototype becomes a final product without changing gears—when generated code becomes infrastructure, local automation becomes a critical dependency, or a patched-together tool becomes indispensable to a team without anyone truly mastering how it works.

Vibe coding is not bad in itself. It becomes problematic when low technical mastery remains hidden or is never compensated for.

The question isn't whether people who vibe-code are producing garbage. The real question is: under what conditions must rapid, low-mastery production be transformed into controlled, mastered design?

8. The Evolution of Designer Profiles

Design doesn't belong to a specific job title; it depends on one's position in the space defined by abstraction, granularity, and mastery.

Traditional professional design roles—engineer, designer, developer, architect—can be reframed as specific zones of mastery rather than rigid, fixed categories.

Historically, these professions were distributed in a relatively stable manner. Engineers operated primarily at technical levels of abstraction, with deep mastery of resolution mechanisms. Designers worked at higher levels of abstraction, structuring usages, interactions, or aesthetics. Architects, whether technical or product-focused, occupied a unique position by connecting multiple levels of abstraction while maintaining a global mastery of trade-offs.

This distribution implicitly relied on a strong constraint: to produce was to understand.

The emergence of generative tools changes this equilibrium. It enables non-technical profiles—business, marketing, operations—to directly produce artifacts: internal apps, automations, interfaces, printable 3D models, and structured content.

While these profiles don't necessarily acquire equivalent technical mastery, they command the power of execution.

Thus, a new category of designers is emerging, which we can call "situated designers": individuals who possess a strong mastery of constraints in their specific domain, but currently have a low mastery of their technical resolution. And this can bring immense value.

An operator automating an internal workflow understands the operational constraints better than anyone. A marketing manager designs acquisition funnels by integrating constraints of user perception and conversion. A business leader structures a value proposition and an economic model.

In these cases, design is fully alive. But it is localized. It focuses on specific constraints, not on the entirety of their execution.

This evolution presents a double-edged sword.

On one hand, it represents a massive opportunity. Constraints are formulated by those who actually live them. The gap between design and usage shrinks, and previously ignored or poorly translated problems can be addressed directly.

On the other hand, it introduces a structural risk. The disconnect between formulating constraints and mastering their resolution can lead to an accumulation of fragile, hard-to-maintain solutions that are difficult to evolve.

Ensuring overall system coherence becomes more challenging because it is no longer safeguarded by a limited number of profiles capable of bridging all levels.

Thus, the transformation of designer roles does not remove the need for design. It redistributes it, creating exciting new zones of mastery, but also new blind spots.

9. Strategy as a Mapping of the Design Space

So, who is right? The business lead who launches their app on the market in 24 hours, or the developer who takes more time but builds a clean, maintainable system?

To find out, we must distinguish the design space itself from how it is leveraged within an organization: strategy.

The dimensions of abstraction, granularity, and mastery describe possible positions in this space. Strategy, however, is the evaluation of these positions against business objectives such as cost, speed, robustness, maintainability, or market differentiation.

Certain positions are perfectly suited for short-term goals. Using a generated solution with low technical mastery might be ideal to quickly test a market, explore an idea, or validate a hypothesis.

Other positions are mandatory for building a sustainable competitive advantage. This is especially true when the solution touches on security, compliance, critical customer experience, data management, or a core differentiating feature of the product.

The strategic question isn't whether to design or buy, or whether to produce fast or produce clean. The real question is determining at which level of the design space it is vital to retain absolute mastery.

10. AI as the New Subcontractor

To understand the role of artificial intelligence more precisely, it is helpful to view it not just as a tool, but as a new actor in the design chain. More specifically, as a unique form of subcontracting.

In a classic model, outsourcing involves a partial delegation of constraint resolution. A company might delegate the design of an electronic module or software development to an external partner. The company might not master every detail of the solution, but it trusts the partner's expertise, which it evaluates and manages through a relationship of trust.

This model relies on key structuring elements: the identifiable competence of the provider, open communication, contractual responsibilities, and, to some extent, the ability to audit or challenge choices.

Generative AI introduces a completely different form of subcontracting. It produces solutions based on a description, without always explaining the internal mechanisms behind the results. It doesn't report its trade-offs, formalize its assumptions, or guarantee performance consistency over time.

It is closer to a dynamic, on-demand provider of off-the-shelf solutions: artifacts generated instantly, tailormade to the context, but whose internal logic remains opaque to the user.

This dynamic brings several major consequences.

First, the barriers to entry are practically eliminated. Where building a system previously required specialized expertise or dedicated outsourcing, it is now accessible through simple conversation with a generative system.

Second, delegation becomes instantaneous. There is no longer a need to select a vendor, negotiate a contract, or manage a relationship. But this ease also makes delegation harder to control. And this is the critical point: the responsibility for the generated solution remains entirely with the user, even if they do not always have the means to fully own it.

Third, the question of mastery shifts to a question of trust. Just like with a human subcontractor, the user accepts not fully understanding the solution. But unlike an established expert, AI offers no explicit guarantees on the validity of its choices, nor on their alignment with specific constraints.

This transformation doesn't mean traditional subcontractors will disappear. On the contrary, it can reinforce their value in high-stakes contexts. Where robustness, security, or compliance are critical, the need for explicit, human-mastered engineering becomes more central than ever.

In this sense, artificial intelligence does not replace design. It simply redefines the terms on which design gets delegated.

11. Is AI Truly a Design Tool?

Categorizing design in terms of abstraction, granularity, and mastery can also be applied to the tools we use to build projects.

However, it would be incorrect to assume that a specific tool (such as CAD!) intrinsically belongs to a single zone of this space. The same software can support high-mastery design or, conversely, encourage execution without comprehension, depending entirely on how it is used.

It is therefore more accurate to view tools not as fixed categories, but as vectors of movement within the design space.

Some tools expose constraints and demand explicit resolution from the user. In mechanical engineering, software like SolidWorks or Fusion 360 requires defining dimensions, geometric relationships, materials, and stress conditions. In digital design, tools like Figma or Illustrator structure the representation of interfaces or graphic shapes without fully automating their logic.

In software engineering, AI-augmented environments can speed up coding while keeping architectural responsibility and technical decisions in the developer's hands—provided they are used with that mindset.

Other tools, on the contrary, rely on a more implicit resolution of constraints. The user expresses an intention, often via text or global parameters, and instantly receives a functional or visual output.

In these scenarios, the user retains a level of control over the intent and overall parameters, but the internal logic of the resulting solution remains largely implicit. The constraints are resolved, but their resolution is not exposed.

These tools are highly effective for rapid exploration of variations, building prototypes, or testing hypotheses. However, they make deep understanding of the chosen solutions much harder, which limits future adaptability and optimization.

Finally, some systems heavily encapsulate the resolution logic. These can be complex SaaS services, proprietary modules, automated processing pipelines, or autonomous AI agents whose internal operations are neither visible nor editable.

Using such systems is not inherently wrong. It can be highly efficient for non-differentiating functions or temporary needs. It only becomes critical when these systems occupy a core position in your global system architecture.

The challenge is not to oppose traditional tools and generative tools. It is to understand which zones of mastery they steer the user toward.

In summary, AI is a design tool if utilized as one. It becomes a mere generator of solutions if it allows us to produce without understanding. And it becomes an organizational risk when it permanently places opaque systems in critical business areas.

12. Handing Over Design and Collaborative Dynamics

One of the most visible effects of contemporary tools, and artificial intelligence in particular, is the partial blurring of traditional roles.

Where activities were historically siloed—functional specifications, product design, engineering, deployment—it is now possible for a single individual to work across multiple layers.

A designer can produce coded, interactive interfaces that developers can directly use. A developer can quickly generate user interfaces or explore user journey logic. A business lead can prototype a product and instantly test it in the market. An operations manager can build a tailored internal tool in just a few days.

This evolution is a massive win for exploration speed and reduces friction between design phases.

However, this new capability does not solve the challenge of mastery; in fact, it often displaces it.

Artifacts produced under these conditions often sit in intermediate zones of the design space. They work, but their internal logic is partly opaque. They meet an immediate need, but their robustness, scalability, and integration into a larger ecosystem are not guaranteed.

The central question then becomes: what happens after the prototype?

Moving from a rapidly produced solution to a sustainable, engineered product is not just about "polishing" the prototype. It represents a fundamental shift: moving from a scenario where constraints are implicitly handled by a tool to one where they are explicitly understood and mastered.

This transition first requires making constraints explicit. A prototype always carries assumptions about usage, edge cases, expected performance, and interactions. As long as these assumptions remain implicit, they can neither be debated nor validated.

It then requires formalizing the resolution. It is no longer enough to observe that a system works; we must understand how it works. For software, this involves structuring the architecture, clarifying data flows, or identifying dependencies. For physical products, it means understanding mechanical stresses, material choices, or manufacturing processes.

Finally, it requires the capacity for controlled, seamless modification. A mastered solution must be able to evolve without breaking.

This process usually cannot be handled by a single individual, especially when levels of abstraction and granularity vary. It relies on collaboration between complementary profiles, each bringing mastery over a specific set of constraints.

A designer can clarify user flow logic and experience goals. An engineer can formalize the technical structure and guarantee robustness. An operations expert can specify real-world workflow constraints. A business leader can ensure economic and strategic alignment.

Collaboration is not simply about stacking these contributions together. It is about translating constraints from one level to another.

In this context, prototypes, coded mockups, scripts, or automations serve as valuable communication tools. They bring intentions to life and test assumptions, but they also highlight where mastery is missing.

13. The Risk of Stagnating in Intermediate Zones

One of the major risks introduced by modern tools is getting stuck in these intermediate design zones.

A working prototype can easily be perceived as "good enough" and deployed as-is, skipping the necessary phase of formalization and engineering mastery. This is typical of certain forms of shadow IT.

The problem is not the existence of these prototypes—they are highly valuable. The problem arises when they become backbones of the organization by default, without clear ownership, documentation, validation, integration, or real maintenance capabilities.

This scenario is incredibly common when time-to-market pressure is high or when the initial stakes seem low. It gradually leads to an accumulation of disjointed, hard-to-maintain solutions whose interactions eventually become unmanageable.

AI significantly accelerates this phenomenon by making localized production effortless.

The goal is not to ban these initiatives, which would be highly counterproductive. Instead, it is about setting up organizational guardrails to identify when a solution should remain a simple prototype, when it can be tolerated as a local tool, and when it must be brought into a controlled, mastered design workflow.

This is no longer just a technical issue. It is a strategic, organizational one.

14. Moving Toward Design Governance

This brings us to a much broader challenge: design governance.

In the AI era, organizations can no longer assume that design is reserved for a few isolated departments. Diverse roles can now build artifacts, automate workflows, generate interfaces, prototype products, or create custom internal tools. Design has become distributed.

But if design is distributed, then mastery, responsibility, and validation must be actively structured.

Design governance is not about banning the use of AI, nor is it about letting everyone build freely without guardrails. It is about defining how an idea, a prototype, a local tool, a shared solution, or a critical system moves from one maturity status to the next.

Each status must carry different requirements regarding mastery, documentation, validation, security, integration, and ownership.

Therefore, an organization must be capable of identifying what can be generated freely, what requires code review, what must be refactored by expert profiles, what needs documentation, what must be integrated into a larger architecture, and what must be discarded before it turns into technical debt.

This governance must also recognize the high value of "situated designers." Business, marketing, design, or operations profiles should not be viewed merely as users to be controlled. They are active players in the design journey because they formulate critical real-world constraints.

However, their output must seamlessly connect with a mastered design pipeline when the business stakes demand it.

Design governance is about balancing two vital needs: enabling rapid innovation by those closest to the problems, and organizing the rise in technical mastery as solutions scale of importance.

15. Conclusion: Designing is Choosing Where to Maintain Mastery

The challenge presented by AI is not entirely new. It simply shines a spotlight on a fundamental truth of any design practice: we never design everything.

Every project relies on scoping choices. We decide what to design, what to assemble, what to delegate, what to buy, and what to use as-is. These decisions are not secondary—they are the core of design itself.

Designing is as much about resolving constraints as it is about deciding which ones we must absolutely master. This is the difference between simple functional execution and truly strategic, controlled design.

AI intensifies this challenge because it allows us to produce faster, with more team members, and sometimes with a more fragmented understanding of the underlying technology. It does not create the scoping challenge; it simply makes it more frequent, visible, and highly strategic.

The response cannot solely be individual. As design becomes distributed among business units, designers, developers, experts, and generative tools, organizations must learn to map, manage, and elevate these varying levels of mastery.

This is the true role of design governance: enabling rapid exploration without mistaking a prototype for an engineered solution; recognizing the value of situated designers without ignoring technical gaps; and deciding precisely where delegation is acceptable, and where deep, human understanding must be preserved.

In the age of AI, designing doesn't mean mastering every detail. It means knowing how to draw, own, and continually evolve your design boundaries.