The Modern Developer Resembles a Child with a LEGO Box More Than an Expert with a Perfect Blueprint

A box of building bricks does more than offer a model to copy. It gives you pieces, a few rules for putting them together, and room to try something else. You build, see what holds, take part of it apart, and start again with a better sense of what works.

Software development increasingly follows the same pattern. Not because the work has become child’s play, but because our ability to build depends on choosing and assembling things we did not write ourselves. Code still matters. Understanding the system around that code matters even more.

Development was never a blank page

Even before AI assistants, a project was already made of building blocks: a framework, a library, a payment API, a database, an authentication system, a cache service, or a design system. The skill was not only knowing how to create those parts. It was knowing which ones fit the problem, how to integrate them, and what their presence would mean for the project.

Today’s ecosystem makes that reality easier to see. In a few hours, you can start a Next.js application, connect PostgreSQL, add authentication, or wire up an API. That is useful. But having more building blocks does not guarantee a better structure.

You can stack components until you have something that works in a demo. The harder problems appear later: incompatible dependencies, a data model that does not fit, security considered too late, missing tests, or behavior no one can diagnose. In software, the equivalent of a block tower collapsing is often a feature that seemed finished but no one dares to change.

So the question is not only, “Does it work?” It is also, “What happens when the need changes?”

Moving fast is not the same as working at random

A prototype that quickly disproves a bad assumption can be more valuable than a solution theorized for weeks and delivered too late. An integration tested in staging can prevent an incident. Removing a feature that has become too costly to maintain can be better than continuing to add to it.

It depends on how the experiment is run. Breaking something in production with no logs, no tests, and no way back is not iteration. It transfers the risk to users and the team. An experiment in a controlled environment, with a clear hypothesis and validation criteria, helps the team learn before release.

Iteration is not the absence of a method. It is a method that recognizes we do not always understand a complex problem until a first solution meets reality. We observe what happens, narrow the problem, check our assumptions, and rebuild on firmer ground.

AI can make the pieces. It does not own the whole structure.

An AI assistant can generate a component skeleton, a SQL migration, tests, or a first integration. It lowers the cost of exploration and helps us move faster from an idea to something we can inspect.

But it does not automatically know all the constraints that keep a project together: business rules missing from the ticket, data-model invariants, flows that must remain idempotent, dependencies that are already fragile, or trade-offs the team has made. It can produce a convincing piece without knowing whether it fits the existing structure.

That is where generation speed can mislead us. Producing code quickly is not the same as delivering quickly. The code still has to be understood, tested, secured, integrated, and made maintainable six months from now.

The simple opposition between “coding by hand” and “having AI code” does not help me much. In either case, the useful question is the same: what are we trying to build, and do we understand the pieces well enough to make the whole thing hold? AI speeds up people who know how to frame and verify the work. Without that discipline, it mainly speeds up the production of decisions no one made deliberately.

A plan gives direction, not certainty

Before building, we need to clarify the goal, the constraints, the responsibilities, and the parts that must stay stable. That is what design and planning are for: avoiding a pile of components with no clear destination.

But a plan is not a promise that everything is known in advance. The first prototype may show that an API does not meet the need, that users misunderstand a workflow, or that performance falls apart with real data. The right response is not to defend the original plan. It is to update it based on what we have learned.

A plan that never changes is not necessarily a sign of control. It may simply never have met the real world. A plan is useful when it guides experiments and makes decisions visible, then changes when the evidence calls for it.

Building for the long term means making change possible

A feature is not finished in the sense that it will never change. Usage evolves, business constraints become clearer, and technical choices age. Building for the long term mostly means being able to change one part of a system without rebuilding everything around it.

That is why fundamentals still matter: clear boundaries between responsibilities, an understandable architecture, tests that protect essential behavior, useful logs, documentation that explains important decisions, and deployments that can be rolled back. These things are rarely the most visible part of a demo, but they determine what the team can change next.

The most useful code is not always the code that looks impressive at first glance. Often, it is the code another person can read, evolve, and deploy without worrying about triggering a chain reaction.

The work is shifting toward judgment

Developers will probably write less repetitive code than they did ten years ago. In return, they need to make more decisions: which component to reuse, what to automate, which trade-off to accept, which risk to contain, and when to stop iterating and ship.

Communication matters more too. When a first version can appear very quickly, value shifts toward clarifying a vague request, making choices explicit, and sharing understanding across the people, tools, and systems involved.

This is not the end of the profession. It is a change in its responsibilities. The pieces are more accessible, the structures more ambitious, and the consequences of a mistake sometimes greater. The work is still to understand the problem, choose a first shape, try it, and learn from what does not hold yet.

Build better with every attempt

Software development is not a race to produce as much code as possible. It is continuous construction: reuse what exists when it fits, create what is missing, check the connections between parts, and start again when reality points to a better route.

AI shortens the loop between an idea and a first result. It does not remove the need to understand, to choose, or to take responsibility for what goes into production. A good developer is not someone who never breaks anything. It is someone who knows where to experiment, what to protect, and how to leave the project stronger after each attempt.

Like working from a big box of building bricks, the question is not whether we have enough pieces. We need to know what we want to build, understand what will make it hold, and be willing to rebuild when the first attempts are not enough.