DEV Community: Remy Loubradou

Explicit vs. Implicit in the Age of Intelligences

Remy Loubradou — Thu, 07 May 2026 15:06:00 +0000

Why the implicit becomes fragile when humans and agents co-produce code.

In the previous article, I defended a simple idea: code is not elegant prose. It is a system, to be judged by its robustness.

But that idea calls for another one.

If code is a system, then it is not enough for it to be pleasant to write, locally fluid to read, or elegant in appearance. Its structures must remain visible. Its boundaries, states, contracts, responsibilities, and effects must be understandable, revisitable, criticizable, and transformable.

In other words: the system must be explicit.

This is where a very contemporary tension appears. For a long time, part of software tooling has valued the implicit: conventions, framework magic, inferred behaviors, invisible structures, shortcuts that let us move faster. This has often been useful. It has sometimes even been very productive.

But in the age of intelligences — human and artificial — the implicit changes in nature.

The problem with the implicit is not only that it is hidden. It is that it is no longer guaranteed to be shared.

The implicit has long been an accelerator

We should not caricature the implicit.

The implicit is not bad by nature. It has made it possible to build more fluid tools, frameworks that are faster to adopt, and more productive conventions. It has made it possible to write less, repeat less, and move part of the work into the framework, the language, or the environment.

This is often what makes a technology pleasant.

A file placed in the right location automatically becomes a route. A function named in a certain way is recognized by a tool. A discreet directive changes the execution location of a piece of code. A naming convention avoids explicit configuration. A React hook makes it possible to reuse logic by connecting to a component’s lifecycle.

All of this can be practical.

And sometimes, this local comfort creates an impression of elegance.

But we need to name what is really happening: part of the system’s structure is no longer in the code itself. It is in the prior knowledge one must possess to interpret that code correctly.

The implicit works well when everyone shares the same context.

It works less well when that context becomes unstable.

The implicit becomes fragile when it is no longer shared

In a stable human team, some implicit knowledge can hold for a long time.

Developers know how the system works. They know the local conventions. They know why one layer must not import another. They know that a given function must only be called in a given state. They know that a given hook is fragile, that a given abstraction hides a side effect, that a given route depends on a file convention.

This knowledge is not always written down. But it circulates through habit, code review, oral transmission, and familiarity with the project.

In the age of agents, this situation becomes more fragile.

Humans and agents do not produce code according to the same internal logic. Humans mobilize concepts, intentions, mental models, and a more or less explicit causal understanding. Agents produce a plausible continuation under constraints, then are brought back into line by the compiler, the type checker, tests, linting, and audit rules.

Both can produce valid code.

But they do not produce it in the same way.

And above all, they do not necessarily share the same implicit knowledge.

An agent can introduce a locally plausible form, compatible with immediate constraints, but unnamed, unstabilized, and unshared by the humans who will later take over the system. Another agent, or another version of the same agent, may infer something else. A human may not recognize the hidden assumption. The code may continue to work, but its collective intelligibility will have decreased.

An unshared implicit becomes an invisible dependency of the system.

And an invisible dependency always ends up being costly.

A probabilistic machine facing a system that must remain stable

An LLM is a probabilistic machine.

It produces a plausible continuation. It works from a context, learned patterns, examples, constraints, and tool feedback. It does not understand code the way a human understands a system they have designed, inhabited, corrected, maintained, and confronted with reality.

And yet the code it produces must join an artifact that cannot remain probabilistic.

The software system must tend toward something stable: defined states, controlled transitions, verifiable contracts, localized effects, observable errors.

There is therefore a central tension: a probabilistic machine participates in producing a system that must remain predictable, testable, and controllable.

The explicit does not remove that tension.

It reduces it.

The more a system relies on implicit knowledge, the more the agent has to infer. The more it has to infer, the more likely drift becomes. Conversely, the more concepts are made visible, the less the agent has to guess what is expected.

The explicit does not cancel the probabilistic nature of the model. It bounds what the model needs to guess.

This is why the explicit is not only a reading aid. It is the shared language of production for a system whose authors do not reason in the same way.

When the producers of code do not reason in the same way, the explicit becomes a condition of coordination.

The explicit creates cognitive portability

There is another important consequence.

When concepts are explicit, the language becomes partly secondary.

Take a simple example: the possible states of a system.

In TypeScript, they can be represented with a discriminated union:

type RecorderState =
  | { type: "idle" }
  | { type: "recording"; sessionId: string }
  | { type: "paused"; sessionId: string }
  | { type: "error"; reason: string };

In Rust, we would rather write:

enum RecorderState {
    Idle,
    Recording { session_id: String },
    Paused { session_id: String },
    Error { reason: String },
}

In Swift:

enum RecorderState {
    case idle
    case recording(sessionId: String)
    case paused(sessionId: String)
    case error(reason: String)
}

In Kotlin:

sealed interface RecorderState {
    data object Idle : RecorderState
    data class Recording(val sessionId: String) : RecorderState
    data class Paused(val sessionId: String) : RecorderState
    data class Error(val reason: String) : RecorderState
}

These are not the same languages.

But they are the same conceptual form.

We are no longer merely reading TypeScript, Rust, Swift, or Kotlin. We are reading a finite set of possible states. We are reading an intention of modeling. We are reading a structure that says: these are the cases recognized by the system.

This is what I would call cognitive portability.

The explicit does not only make code readable. It makes it readable independently of the language.

The implicit, by contrast, travels less well. It is often local to a framework, a convention, a directive, runtime magic, or team knowledge. It can be very effective inside its own context. But as soon as one changes language, framework, agent, team, or era, it becomes more fragile.

The explicit makes forms recognizable.

And recognizable forms make convergence easier.

A grid for analyzing the implicit

We can then propose a simple grid.

To analyze the implicit in real code, we need to cross three dimensions.

The first dimension is the system concepts:

boundaries;
contracts;
validation;
invariants;
explicit states;
responsibility and authority;
deterministic transformations;
proof;
observability.

The second dimension is the layers where these concepts can appear:

the language;
the framework;
libraries;
application architecture;
team or project conventions.

The third dimension is their mode of expression: explicit or implicit.

Each time, the question is the same:

Is this concept made visible in the code, or does it rely on a convention, magic, an abstraction, or prior knowledge?

This is not a condemnation of all abstraction.

A good abstraction hides noise.

A bad abstraction hides the system.

The difference is essential.

When an abstraction hides an unimportant detail, it helps us. When it hides a boundary, a state, a responsibility, a side effect, or an invariant, it makes the system harder to understand and easier to drift.

Here is a synthetic version of this grid:

| Concept | Layer | Explicit form | Implicit form | Risk | | ----------------------------- | ----------------------- | ------------------------------------------------------------------- | ------------------------------------------------------- | ----------------------------------- | | Boundaries | Language | modules, visibility, input/output types, controlled imports | free imports, globals, unchecked conventions | porous boundaries | | Boundaries | Framework | server/, client/ files, separate handlers, server-only | discreet directive, colocation that masks client/server | forgetting the boundary | | Contracts | Language | strict types, interfaces, discriminated unions | any, free strings, informal objects | silent assumptions | | Validation | Framework / library | validation schemas at boundaries, explicit parsing | payload accepted by convention | doubtful data in the core | | Invariants | Architecture | controlled constructor, bounded domain model, forbidden transitions | mutable objects everywhere, scattered rules | possible inconsistent state | | States | Language / architecture | state machine, statechart, discriminated unions | scattered booleans, local conditions | illegal transitions | | Responsibility / authority | Architecture | clear ownership of a resource or transition | several layers can mutate the same thing | unclear authority | | Deterministic transformations | Business code | pure functions, immutability, clear input/output | hidden side effects | behavior hard to test | | Proof | Language / tools | typecheck, exhaustiveness, tests, constraints | human trust, conventions | undetected omission | | Observability | Runtime / architecture | contextual logs, traces, correlation IDs | console.error, generic error without context | impossible to understand production |

The point of this grid is not to be exhaustive. It is mainly to shift the question.

We no longer ask only: “is this code clean?”

We ask: “where are the important concepts of the system visible? And where have they disappeared behind implicitness?”

Example: boundaries in Next.js

Take a contemporary example: Next.js Server Actions.

The problem is not that the tool is bad. Nor is the problem that it forces boundaries to be blurred. It is perfectly possible to define server actions separately, in dedicated files, and to mark the split clearly.

But the framework makes possible, through a directive, a very practical form of colocation between frontend code and a server action. This local comfort can create an impression of elegance.

And yet the boundary has not disappeared.

It has only become more discreet.

Behind this apparent simplicity, there is still a real mechanism: server functions callable over the network, authentication and authorization checks to perform again inside the action itself, captured variables sent and then returned, encryption, dependency on the build.

The framework takes part of this on itself, but the abstraction does not remove the complexity. It shifts it and partially masks it.

In the grid, we could say:

concept: boundary;
layer: framework;
explicit form: clear separation between client and server;
implicit form: very practical colocation that makes the boundary less visible;
risk: forgetting the requirements specific to that boundary.

Again, the problem is not the tool.

The problem is how easily local comfort can make us forget a real boundary.

Example: React hooks

React hooks are another interesting example.

They brought something very powerful: the reuse of logic.

Before hooks, React already made views composable. With hooks, it became possible to make local logic reusable too: state, effects, subscriptions, access to the lifecycle, shared behaviors.

It was a real step forward.

But that progress came with a very strong form of implicitness.

Hooks are not ordinary JavaScript. They obey specific rules: constrained call order, impossibility of calling them conditionally, the use prefix, dependencies to maintain in arrays, dedicated linting to flag invalid usages.

Part of the system therefore lives in the implicit rules of the framework.

Of course, we can learn these rules. We can tool them. We can respect them. But we must recognize what they are: prior knowledge required to correctly interpret the code.

And the problem becomes clearer when hooks are used to carry complex behavior.

A few useState, a few useEffect, a few callbacks, a few handlers, and suddenly the component no longer merely renders a view. It hides a small system: states, transitions, effects, resources, invariants, lifecycle.

The view becomes the place where behavior has been mixed in.

The logic is reusable, but it is not necessarily explicit.

Hooks made logic reusable. They did not make it explicit.

Moving logic out of React

One possible direction is not to remove hooks.

It is to put them back in their place.

In this approach, React remains a layer of view and adaptation. The important logic lives in an explicit model outside React.

The model carries:

states;
events;
transitions;
effects;
resources;
invariants;
the data exposed to the interface.

React merely subscribes to the model and sends it user events.

We could represent the architecture like this:

Explicit model → Snapshot / ViewModel → React view

The hook then becomes an adapter, not the main place where logic lives.

For example, for a simplified recording system:

const recorderModel = createRecorderModel({
  services: {
    recordingApi,
    uploader,
    createMediaRecorder,
  },
});

recorderModel.send({ type: "start" });
recorderModel.send({ type: "pause" });
recorderModel.send({ type: "resume" });
recorderModel.send({ type: "discard" });

The model exposes its states and events:

type RecorderState =
  | { type: "idle" }
  | { type: "recording"; sessionId: string; uploadedSegments: number }
  | { type: "paused"; sessionId: string; uploadedSegments: number }
  | { type: "saving"; sessionId: string }
  | { type: "saved"; recordingId: string }
  | { type: "discarded" }
  | { type: "error"; reason: string };

type RecorderEvent =
  | { type: "start" }
  | { type: "pause" }
  | { type: "resume" }
  | { type: "segment-ready"; blob: Blob }
  | { type: "save" }
  | { type: "discard" };

Then React subscribes:

function useRecorderModel(model: RecorderModel) {
  const snapshot = useSyncExternalStore(
    model.subscribe,
    model.getSnapshot,
    model.getSnapshot,
  );

  useEffect(() => {
    model.mount();
    return () => model.unmount();
  }, [model]);

  return {
    snapshot,
    send: model.send,
  };
}

And the component no longer carries the main behavior:

function RecorderScreen({ model }: { model: RecorderModel }) {
  const recorder = useRecorderModel(model);

  return (
    <RecorderView
      snapshot={recorder.snapshot}
      onStart={() => recorder.send({ type: "start" })}
      onPause={() => recorder.send({ type: "pause" })}
      onResume={() => recorder.send({ type: "resume" })}
      onSave={() => recorder.send({ type: "save" })}
      onDiscard={() => recorder.send({ type: "discard" })}
    />
  );
}

The exact details of the API matter less than the conceptual shift.

The hook no longer hides a combination of states, effects, resources, and implicit rules. It connects React to an explicit model.

Libraries like XState already move in this direction: the logic is externalized into an explicit model, and React mostly serves as a display and adaptation layer.

XState is not the only example. Redux was already moving in that direction: taking transition logic out of components, representing changes as actions, and making state evolve through reducers that can be tested separately. Even useReducer, when used with a reducer defined outside the component, can be a step toward more explicitness. The difference is therefore not between “hooks” and “no hooks.” It is between logic hidden inside the component and logic made visible in an autonomous form: reducer, store, state machine, or explicit model.

The problem is not that a hook calls this logic. The problem appears when the hook itself becomes the place where state, transitions, effects, and responsibilities get mixed tog

So the question is not: “should we use hooks or not?”

The question is: “when does a behavior become too systemic to remain hidden inside hooks?”

What should not be misunderstood

The explicit is not a religion.

This is not about making everything heavy, verbose, ceremonial. It is not about rejecting conventions, frameworks, abstractions, or shortcuts.

A fully explicit but poorly organized system can be unreadable. The explicit is not enough to produce clarity.

We must therefore avoid the wrong conclusion: more code does not automatically mean more robustness.

What matters is making explicit the concepts that truly carry the system.

A local convention can work very well if it does not hide anything essential. An abstraction can be excellent if it hides noise, not a responsibility. A framework can increase robustness if it makes the right boundaries visible instead of diluting them.

The goal is not to naively oppose explicit and implicit.

The goal is to know where the implicit becomes dangerous.

It becomes dangerous when it hides a boundary, a state, an invariant, an authority, a side effect, a security assumption, a validation rule, a business transition, or production behavior.

That is where we need to make visible.

That is where we need to name.

That is where we need to model.

Conclusion — the explicit as a support for convergence

In the age of intelligences, the explicit is not merely a style preference.

It is not merely a way to help humans read code.

It is a condition of coordination between producers of code who do not necessarily share the same implicit knowledge.

A human can read a system with a mental model. An agent can produce a plausible form under constraints. Another agent can produce a different one. A future maintainer can arrive without knowing the history of the project.

What allows them to converge is not a shared implicit.

It is a shared explicit structure.

The explicit makes concepts visible. It reduces the amount of guessing. It makes forms more portable from one language to another. It makes boundaries, states, responsibilities, and effects harder to forget.

It does not guarantee that the system is good.

But it makes one essential thing possible: to take it up again, discuss it, correct it, make it evolve.

The implicit can accelerate.

The explicit allows transmission.

And in a world where humans and agents write together, what cannot be transmitted eventually drifts.

Code Is a System, Not Elegant Prose

Remy Loubradou — Tue, 28 Apr 2026 14:00:00 +0000

Code is not elegant prose. It is a system, to be judged by its robustness.

Too often, we talk about code as if we were talking about style.

We say that a piece of code is elegant, beautiful, refined, clean, sometimes even inspired. We attribute to it qualities that are almost literary, almost artistic, as if writing software were first and foremost an art of form. As if the quality of code were decided mainly by the way its sentences look.

That is a category error.

The problem is not the word elegant in itself. The problem is everything it carries when it is used in a romantic, literary, aesthetic sense: the idea that good code would first and foremost be code admired for its formal poise, its grace, a kind of almost autonomous inner beauty.

And yet code is not a text to be contemplated. Code runs in the world.

It runs in machines, networks, browsers, phones, databases, message queues, distributed systems, human organizations. It encounters latency, outages, incomplete responses, side effects, inconsistent users, imperfect environments, intermediate states, unstable dependencies.

The real world does not applaud the beauty of an abstraction. It punishes the absence of guardrails.

That is why the right vocabulary is not, first and foremost, the vocabulary of elegance. It is the vocabulary of robustness.

One thing must be made clear, however: I am not arguing here against elegance in the sense some engineers mean it — clarity, sound decomposition, the right simplicity. That tradition is valuable. What I am aiming at is another way of talking about code: a more romantic, more aesthetic way, one that judges it first by its appearance rather than by how well it holds up in the real world.

What is often celebrated as “elegant” is not always a structural quality. It is sometimes a quality of local comfort: less code, more fluidity, more colocation, more convention, more implicitness. And yet what is practical to write or pleasant to read locally is not always what makes a system more explicit, more stable, or more transmissible.

Robustness as the real criterion

I use the word robustness here in a broad sense.

Robust code is not simply code that “doesn’t break.” Robust code is code that is:

intelligible;
resilient;
observable.

That definition changes the very way we judge software.

The question is no longer: is this code beautiful?

The question becomes:

Can a human understand it without taking a leap of faith?
Can a machine reason about it without guessing?
Does it absorb failures and deviations from the real world cleanly?
Can we know what it did, in what state, and why?
Can we take it up again, extend it, audit it, without weakening the whole?

That is where the real shift lies.

We should not judge code first as an aesthetic object. We should judge it as a system exposed to reality.

That does not mean every piece of code requires the same level of formalization everywhere, but that the right compass is not how code looks: it is the level of robustness the situation actually requires.

These tools have a cost as well. A prototype still looking for its problem does not need the same level of formalization as a critical system. The discipline is not to structure everything everywhere, but to know what deserves to be structured, when, and for what risk.

Intelligible, because it must be possible to read it without guessing

Robustness begins with intelligibility. And in this article, what I call intelligible depends first on one property: the explicit. Visible boundaries, clear responsibilities, named states, stated contracts, declared transitions, but also clear names, understandable flows, localized transformations, and stable conventions. A system does not become automatically simple merely because it is explicit. But without explicitness, it forces us to guess — and a system that forces us to guess quickly becomes costly.

But today, that is no longer enough.

Code must also be intelligible to machines.

We are entering an era in which code is no longer read only by developers. It is also read, audited, transformed, completed, explained, and sometimes generated by intelligences. Ambiguous, implicit code, full of unstated conventions, does not merely become painful for a human colleague: it also becomes fragile for an agent. It forces it to guess.

And as soon as a system relies on guesswork, it becomes costly to maintain and dangerous to modify.

Intelligibility is therefore not a luxury of style. It is an operational property. And here, it depends largely on making the system explicit.

Resilient, because the world deviates

Good code is not code that assumes everything will go well. It is code designed in the knowledge that not everything will go as planned.

I use “resilient” here in a broad sense. A resilient system does not merely survive a failure. It absorbs deviations from the real world: latency, incomplete responses, unstable dependencies, replays, temporary unavailability, side effects, partial interruptions, variations in context.

As soon as a system touches the outside world, it encounters that uncertainty: a network response may arrive late, an API may change shape, a user may send absurd data, a database may be temporarily unavailable, an event may be processed twice, a state may be partially updated.

A robust system does not deny that reality. It frames it.

It distinguishes what is reliable from what is not.

It limits the places where side effects occur.

It makes error cases and degraded cases explicit.

It accepts that failure is part of the system’s normal behavior.

Robustness is therefore not an extra layer you add afterward with a few try/catch blocks. It is a way of designing software from the outset.

Observable, because in production we never see everything in advance

Even a well-designed system will encounter cases in production that nobody had fully anticipated.

That is inevitable.

The question, then, is not whether errors will occur. The question is whether, when they do occur, the system will give us the means to understand what happened.

Observable code produces useful traces. It makes important transitions, significant failures, useful contexts, external interactions, abnormal delays, and relevant business states visible.

It does not merely fail. It fails while leaving usable clues behind.

Observability is not a secondary concern reserved for operations or infrastructure. It is a software design concern. A poorly structured system is hard to observe because it already struggles to describe what it is doing. A well-structured system, by contrast, naturally makes it possible to attach traces to boundaries, contracts, validations, state transitions, and domain errors.

Observing a system is not a matter of adding lamps to an obscure machine. It is a matter of building a machine whose mechanisms can be inspected.

What makes code robust

Once we accept that robustness is the real criterion, another family of concepts becomes central.

No longer the concepts of style, but the concepts of system.

And these concepts do not simply sit side by side. They follow one another.

This sequence is an order of exposition, not a strict order of construction. In practice, these dimensions respond to one another, correct one another, and are co-constructed. But to think about them clearly, it is useful to unfold them this way.

1. Boundaries

Everything begins with boundaries.

A robust system must know where it begins, where it ends, and where its zones of uncertainty lie.

Boundaries separate, for example:

the internal from the external;
the domain from the infrastructure;
pure logic from side effects;
trusted data from data that is still suspect.

Without boundaries, everything communicates with everything else. Responsibilities blur, causes spread, and errors become hard to localize.

Boundaries are therefore not just there to “organize code well.” They are there to contain uncertainty.

A contemporary example: in web applications, some frameworks make client/server interactions feel very fluid. Next.js Server Actions, for example, do not force us to blur boundaries: they can perfectly well be defined separately, with the split clearly marked. But the framework makes possible, through a simple directive, a very practical form of colocation between frontend code and the server action. That local comfort can create an impression of elegance. And yet the boundary has not disappeared: it has merely become less visible. Behind that apparent simplicity lies a whole real mechanism: server functions callable over the network, authentication and authorization checks that must be performed again inside the action itself, captured variables sent out and then sent back, encrypted, and tied to a given build. The framework takes part of that on itself, but this abstraction does not remove the complexity: it shifts it and partially masks it. The problem is not the tool. The problem is how easily local comfort can make us forget the boundary, its requirements, and the operational burden that still exists behind it.

2. Contracts

As soon as a boundary exists, we need to define what is allowed to cross it.

That is the role of contracts.

A contract states what is expected, what is guaranteed, and under what conditions. It can take several forms: a type, an interface, a schema, a protocol, an explicit convention. The exact form does not matter. What matters is that it reduces ambiguity.

The logic is simple:

boundary → contract

We do not let just anything circulate between two zones of the system.

A system without contracts rests on assumptions. And assumptions fail silently.

3. Validation

A contract that is never checked remains wishful thinking.

That is why contracts call for validation.

As soon as data crosses a boundary, it must be validated. This applies to user input, an environment variable, an API response, an imported file, a message consumed from a queue, a network payload.

To validate is to refuse to pretend that every input is legitimate.

A robust system does not trust too early. It validates at the boundaries. It turns the unknown into the known.

That is especially true when we consume an external system. The mere fact that it advertises a contract never removes the need to verify what actually comes in. An API may drift, be incorrectly implemented, or occasionally violate its own promise. Without validation at the point of entry, we let data into the system that is treated as true even though it is not.

The chain then becomes:

boundaries → contracts → validation

And that chain is essential, because it prevents uncertainty from the outside world from silently contaminating the core of the system.

4. Invariants

Once inputs have been framed and validated, the system can begin to protect its internal truths.

That is the role of invariants.

An invariant is something that must remain true.

For example: a paid order does not become pending again; an authenticated user always has a valid identifier; an object in a given state cannot trigger a given transition; data marked as validated actually conforms to the expected schema.

Invariants give the system anchor points. They reduce the space of possibilities. And reducing the space of possibilities is what makes the system more intelligible and safer.

An invariant is not merely an abstract truth; it is also something that must be protected against the system’s real behavior. If a payment webhook is replayed, for example, the system should not behave as if a brand-new event had arrived. Without idempotency guardrails, the same signal can produce multiple effects and make the state drift instead of stabilizing it.

We can put it like this:

validation protects invariants

5. Explicit states

As soon as a system depends on time, stages, permissions, sequences, events, transitions, or temporality, its state must be made explicit.

As soon as a resource exists over time, it also has a lifecycle. Thinking about that lifecycle explicitly means refusing to let it be scattered across a multitude of local, implicit, or contradictory conditions.

And in practice, making state explicit means modeling it.

We then mobilize conceptual tools such as:

state machines;
statecharts, when we need to add hierarchy, parallelism, or communication.

Why are they useful? Because they force us to name the possible states, define the allowed transitions, make triggering events explicit, and limit illegal moves.

They replace diffuse logic with a declared structure.

The progression then becomes:

invariants → explicit states → allowed transitions

And that is often where a system really begins to hold together. Not because it becomes more “intelligent,” but because it becomes less blurry.

Take an audio or video recording system. Before anything even starts, the user can choose a camera, a microphone, a background, check a preview. Then they start recording, can pause, resume, turn the camera off, change certain settings, while in the background the system creates a server-side trace, listens to devices, and uploads segments. At the end, they can delete or save. Without explicit states, all of this quickly gets scattered across local conditions and contradictory flags. With a state machine, we name the phases, constrain the transitions, and finally make coherent what the user sees, what the system does, and what the server receives.

6. Responsibility and authority

Once states have been made explicit, another question becomes unavoidable: who is allowed to act on what, at what moment, and with what responsibilities?

Here, the question becomes one of responsibility and authority.

A system becomes blurry when multiple parties can create, modify, transition, or destroy the same resource without a clear rule. By contrast, a robust system knows who owns what in the operational sense: who is responsible for a piece of data, a process, a resource, a transition, a cleanup, a closure.

Lifecycle tells us in which states something may exist over time. Responsibility and authority tell us who may act on that thing, when, and under what conditions.

This point is essential, because an explicit state without explicit authority still leaves room for drift. We then know what may happen, but not who is legitimate to make it happen.

The progression is therefore enriched as follows:

explicit states → responsibility and authority → controlled transitions

7. Deterministic transformations

Once boundaries are in place, contracts defined, validations in place, invariants protected, and states made explicit, another question becomes central: how do we make the system’s local behavior as readable and predictable as possible?

That is the point at which the question of deterministic transformations arises.

Whenever possible, we want transformations whose behavior is stable, understandable, and testable. We want, as much as possible, pure functions, immutability, composition, and isolated side effects.

Not out of doctrinal taste, nor to signal allegiance to a school, but because this makes the core of the system more robust.

Ideas from functional programming are valuable here. They do not replace boundaries, contracts, invariants, or explicit states. They simply make internal behavior more predictable.

A pure function does not, by itself, constitute a system invariant. It does, however, provide a local unit of predictability. Same input, same output, no hidden side effects. And those local units of predictability are extremely valuable when one wants to build a whole that is readable, testable, and reliable.

In practice: at the boundaries, we validate; in the core of the system, we seek purity as much as possible; as soon as time, permissions, or transitions matter, we make state explicit.

That search for local determinism does not replace system thinking. It complements it.

And it naturally prepares the next step: proof.

8. Proof

Once boundaries are in place, contracts defined, validations in place, invariants protected, and states made explicit, one question remains: what still depends solely on human discipline?

The question of proof then appears.

In software, proof is not always formal in the mathematical sense. But there are several degrees of proof:

types;
schemas;
tests;
exhaustiveness;
compile-time constraints;
the structural impossibility of certain states or certain transitions.

The central idea is simple: everything that can be guaranteed structurally should not rest solely on habit, caution, or a team’s memory.

We can summarize it this way:

contracts + invariants + explicit states → forms of proof

The more a system replaces implicit discipline with explicit guarantees, the more robust it becomes.

An important nuance must be added, however: proof here is not limited to the most common and accessible forms of structural guarantee. In some contexts, it can go as far as formal verification, using languages, proof assistants, and methods capable of demonstrating that a program satisfies certain specifications. This path remains demanding and uncommon in day-to-day development, but its existence reminds us that “proof” is not merely a convenient metaphor. In some cases, it can become a real technical objective.

We can also see this in more ordinary forms of proof. Between a state stored as a simple string and an exhaustive type that forces the compiler to handle every case, the difference is clear: in one case, we hope; in the other, we make certain omissions structurally impossible.

9. Observability, as the extension of the system into the real world

And finally, everything that has been structured conceptually must be made visible when it is actually running.

Observability returns here, no longer as a simple general criterion, but as the concrete extension of the system’s entire architecture.

A well-structured system makes it possible to observe:

what enters through its boundaries;
what is accepted or rejected by validation;
which contracts were violated;
which invariants were protected or threatened;
what state it is in;
which transition took place;
which external interaction failed;
which abnormal delays or behaviors were encountered.

Observability is not something added at the end like technical decoration. It is attached to the very structure of the system.

The full logic then becomes:

boundaries → contracts → validation → invariants → explicit states → responsibility and authority → deterministic transformations → proof → observability

At that point, we are no longer talking merely about organized code. We are talking about a system that can be understood, constrained, evolved, and inspected.

The difference becomes obvious very quickly in production. A log that only says “500 error” signals a problem, but rarely helps us understand it. A log or trace carrying a correlation ID, the current business state, the attempted transition, and the rejected input is already telling part of the system’s story. Useful observability is not about producing more noise, but about making the system’s behavior intelligible when it deviates.

In the age of intelligences, blur becomes more costly

In the age of intelligences, system thinking becomes even more important. The issue is not merely that agents produce code. The issue is that this code must be able to circulate between several forms of intelligence: human and artificial today; often intertwined tomorrow. We do not merely want a machine to write code. We want it to write a system that a human can reread, understand, critique, and validate. And conversely, we want humans to produce structures that machines can follow without guessing.

When several humans and several agents intervene in the same code, the absence of boundaries, contracts, invariants, explicit states, and clear authorities opens the way to every kind of drift: drift of meaning, drift of architecture, drift of behavior. The code may continue to function, but it gradually stops forming a system. Conversely, a well-structured system does not merely make maintenance easier: it contains distortions, makes deviations visible, and allows transformation to remain controlled.

For a long time, a small team could compensate for blurry code through familiarity. Someone knew “how it really works.” An implicit, collective, more or less artisanal understanding made it possible to patch over the gaps.

That era is eroding.

Today, code circulates between more actors: developers, reviewers, newcomers, analysis tools, pipelines, assistants, agents. Every zone of ambiguity becomes a multiplied cost. Every implicit convention becomes heavier debt. Every porous boundary, every missing contract, every poorly modeled state reduces the ability of a human or an agent to intervene safely.

There is another important shift as well. For a long time, some forms of modeling seemed too costly to write, maintain, or even justify. We settled instead for more implicit, lighter, sometimes blurrier forms. With the productivity gains brought by intelligences, that trade-off changes. Implementation cost drops in many cases. What becomes more costly instead is understanding, validation, testability, and control of drift. As a result, more explicit structures — which might have seemed too heavy yesterday — become good investments instead, because they make the system more readable, more controllable, and more transmissible.

Such code is easier to take over, audit, instrument, and transform, not because it is “prettier,” but because it exposes its logic and reduces the amount of guesswork.

And this is perhaps one of the great shifts of our time: blurry code is no longer merely difficult to maintain. It is also much harder to evolve properly with intelligences.

Conclusion

Code is not elegant prose. It is a system, to be judged by its robustness.

And robustness here is not a vague word. It refers to something precise: code that is intelligible, resilient, and observable.

To get there, we need to think less in terms of style and more in terms of structure: make the system more explicit, set boundaries, define contracts, validate at points of contact, protect invariants, make states explicit, clarify responsibilities and authorities, build forms of proof, and attach observability to the architecture itself.

If we still want to speak of elegance, then we need to shift our gaze. What deserves admiration is not code that impresses. It is code that forms a system.

Elegance is a vocabulary of the surface. Robustness is a vocabulary of the system.

DEV Community: Remy Loubradou

Explicit vs. Implicit in the Age of Intelligences

The implicit has long been an accelerator

The implicit becomes fragile when it is no longer shared

A probabilistic machine facing a system that must remain stable

The explicit creates cognitive portability

A grid for analyzing the implicit

Example: boundaries in Next.js

Example: React hooks

Moving logic out of React

What should not be misunderstood

Conclusion — the explicit as a support for convergence

Code Is a System, Not Elegant Prose

Robustness as the real criterion

Intelligible, because it must be possible to read it without guessing

Resilient, because the world deviates

Observable, because in production we never see everything in advance

What makes code robust

1. Boundaries

2. Contracts

3. Validation

4. Invariants

5. Explicit states

6. Responsibility and authority

7. Deterministic transformations

8. Proof

9. Observability, as the extension of the system into the real world

In the age of intelligences, blur becomes more costly

Conclusion

Further reading