The evolution of software development: experience, judgment and hiring in the age of AI

There's something strange about many conversations regarding software development. A job opening asks for React, Next.js, TypeScript, Node, PostgreSQL, AWS, Kubernetes, Docker, CI/CD, testing, architecture, advanced English, leadership skills, product experience, and desirable certifications. A CV responds with another list. An ATS looks for matches. An interview confirms vocabulary. A technical test measures a small portion of the craft.

Everything seems orderly. Everything seems objective. Everything seems efficient.

But at some point, the central question gets lost.

It's not always asked if the person understands real systems. If they know how to debug without panicking. If they can read legacy code without despising it. If they recognize when a modern solution is overkill. If they can explain a technical decision without hiding behind jargon. If they can anticipate consequences before production turns them into an urgency.

It's not that tools don't matter. They matter a lot. Each technology in a job opening usually comes from a specific need, an existing architecture, or accumulated pain within a team. The problem arises when the list starts to function as a substitute for something harder to measure: judgment.

At what point did we start measuring knowledge by keywords?

The question isn't meant to idealize the past. The industry wasn't purer before, nor wiser, nor fairer. There was also improvisation, manual deployments, poor security, bad documentation, and learning the hard way. But there was a shorter relationship between tool, decision, and consequence.

Today that distance has grown. We have more layers, more abstractions, better platforms, and more specialists. This allowed us to build extraordinary products. It also made it easier to confuse familiarity with experience.

Knowing how to name a technology can open a door. Understanding when to use it, when to avoid it, and what consequences it brings is still another matter.

Experience is not knowing how to name technologies. It's having faced enough real problems to recognize patterns, anticipate consequences, and choose with judgment when there isn't a perfect recipe.

That distinction changes everything.

It's not about attacking frameworks, certifications, bootcamps, AI, specialization, or quick content. All of that can be useful. Many times it's necessary. The problem arises when we turn partial signals into substitutes for understanding.

A tool says something. A certification says something. A repository says something. A stack says something. But none of these signals, on their own, prove that a person can uphold a decision when the system fails, when the business pressures, when documentation is incomplete, or when two correct solutions have different costs.

Experience is formed in that uncomfortable zone. Not when everything works on the happy path, but when you have to form a hypothesis, measure, make mistakes, correct, explain, and assume consequences.

This shift is better understood if we look at what happened with experience signals. The list grew, but its ability to explain criteria became more limited.

Before, a short list of technologies could suggest a good part of the work territory. PHP, MySQL, Apache, HTML, CSS, and JavaScript didn't explain everything, but the surrounding system was more limited. Today, a list can be enormous and still not say whether a person understands the product, data flow, operation, accessibility, technical debt, or the risk of a decision.

The list grew. The essential question remains the same:

Do you understand the problem well enough to choose, build, validate, and be accountable for the solution?

For a long time, web development had a more diffuse figure: webmaster, web programmer, designer-developer, improvised server administrator, occasional technical support, and translator between client, interface, and database.

The same person could design a screen, lay it out in HTML, adjust CSS for incompatible browsers, write PHP or ASP, create tables in MySQL, upload files via FTP, configure emails, review logs, and explain to the client why a form should not save passwords in plain text.

Viewed from today, that world seems small. And in many ways, it was. Projects had fewer layers, less automation, fewer availability expectations, and less integration with external systems. Complexity fit, with difficulty, into a single head.

But it's also not advisable to romanticize it. There were fewer standards, worse security, almost non-existent accessibility, manual deployments, uncertain backups, and a 'if it works, don't touch it' culture that could become dangerous. Many of today's good practices exist precisely because that way of working didn't scale.

What was valuable about that era was not its precariousness. It was the proximity.

Whoever changed a query saw the effect on the server. Whoever uploaded files via FTP understood the risk of breaking production. Whoever provided support heard the human consequence of a bad technical decision. The system was not fragmented into so many layers, and that closeness taught a basic idea: every line of code ends up living within an operation, a business, and an experience.

Nostalgia is not the point. The important thing is to rescue what that closeness between code, server, client, and consequence taught.

The past is not a model. But it does leave a useful question for the present:

How do we maintain system understanding when the work no longer fits into a single head?

That question matters because modern development can no longer depend on individual heroics. It needs specialization. But it also needs bridges.

The web stopped being a collection of linked documents and became a platform for commerce, communication, health, education, entertainment, finance, government, and internal company operations. This expansion made specialization inevitable.

Modern frontend doesn't exist by whim. It exists because interfaces became more dynamic, accessible, measurable, and complex. Backend professionalized because business logic, data, security, and integrations demanded more rigor. DevOps and SRE appeared because manual deployment ceased to be acceptable for systems that needed to operate all the time. UX, product, data, mobile, security, QA, and platform grew because software stopped being just “make it work”.

Specialization gave us depth. Better interfaces. Better deployments. Better observability. Better accessibility. Better product design. Systems capable of operating at previously unthinkable scales.

The problem is not specialization. The problem arises when the part replaces the understanding of the system.

A frontend that doesn't understand how its decisions affect the backend can produce invisible costs. A backend that doesn't understand user experience can design technically correct but clumsy APIs for the product. An infrastructure team that doesn't understand the domain can build elegant platforms for problems that don't need them. A product team that doesn't understand technical debt can confuse apparent speed with real progress.

We gained depth in parcels. What is still difficult is connecting these parcels without each one defending its border as if it were the whole world.

Specialization works best when each part maintains sensitivity to the others. Without that translation, depth becomes a border.

We went from “one person tries to understand everything” to “many people understand different parts”. This change was necessary. But it demands a skill that rarely appears in a job opening: translating between layers.

Mature experience is not about knowing everything. It's about knowing how the parts connect, where the limits are, and when a local decision can become a systemic problem.

Every era of web development had a tool that promised to bring order to chaos.

jQuery made DOM manipulation bearable in a world broken by browser differences. AngularJS brought structure to increasingly ambitious client-side applications. React shifted the conversation towards components, state, and composition. Vue proposed gradual adoption. Svelte moved part of the work to the compiler. Next.js turned rendering, routing, data, and deployment into a more integrated experience. Then came Remix, Astro, server components, edge runtimes, and a constellation of tools that continue to redefine the craft.

Each wave solved real problems. It also brought its learning curve, its conventions, its opinion wars, and its inevitable migrations.

The pattern repeats: a tool appears that reduces friction, becomes standard, enters job vacancies, and finally, part of the industry begins to confuse mastery of the tool with understanding the principle that made it necessary.

That fascination with tools didn't appear overnight. Each wave promised to reduce real friction and, at the same time, shifted the conversation towards a new layer of abstraction.

jQuery made an incompatible web more livable. AngularJS sought structure for complex client-side applications. React made interface composition central. Vue y Svelte reminded that ergonomics is also an architectural decision. Next, Remix y Astroshifted the conversation from the UI framework to the complete system: rendering, data, performance, and deployment.The edge and server-first eraonce again mixed frontend, backend, infrastructure, and experience.

The question is not which tool won. The question is how much of what was learned about state, network, rendering, cache, accessibility, composition, and limits of responsibility survives when the framework changes.

Learning the tool without the principle leaves you exposed to the next trendy change. Learning the principle without the tool can leave you out of the conversation.

That tension is real. The industry needs concrete tools. But it should better measure the principles that survive them.

It has never been so easy to start building software. That's good news.

A local environment is created in minutes. A deployment can happen in seconds. Documentation is clearer. There are courses, videos, communities, repositories, AI assistants, and examples for almost anything. Entry has been democratized, and that changed who can build.

But starting is not the same as understanding.

The quick tutorial teaches a happy path. The bootcamp can open a door. Certification can organize vocabulary. The short video can unlock an idea. The AI assistant can explain an error. None of that is negligible.

The risk appears when learning becomes a checklist.

I learned React. I learned GraphQL. I learned Kubernetes. I learned AI.

The list grows, but the ability to explain why a decision works, what fails when conditions change, or what cost it will have to maintain it for years does not always grow.

A certification can demonstrate exposure. Experience demonstrates application under real conditions.

Understanding demands a friction that doesn't always fit into the fast format: reading documentation, forming mental models, comparing alternatives, failing, debugging, reviewing past decisions, and seeing consequences. It's less flashy. Less viral. Slower. It's also more resilient.

Quick access to knowledge opened important doors. The question is what happens when that speed completely replaces the sources that explain the why.

Industry surveys show something expected: developers are increasingly learning by combining documentation, communities, courses, videos, and AI-assisted tools. That mix is not the problem.

The problem is hierarchy. When the quick source completely replaces the primary source, knowledge becomes more fragile.

Official documentation, RFCs, specifications, source code, and post-mortems are often less appealing than a tutorial, but they teach something a tutorial almost never teaches: why a decision exists, what problem it solves, and what trade-offs it accepts.

The way we learn and the way we hire feed into each other.

If job openings ask for lists of technologies, CVs fill up with lists. If filters look for keywords, people optimize for keywords. If technical tests reward exercises disconnected from real work, candidates train for that type of exercise. If certifications become a symbolic requirement, a race to accumulate signals appears.

It's not one party's fault. Companies need to filter volume. Recruiters need signals. Candidates need to pass barriers. Technical teams need to reduce uncertainty.

The problem is that the system ends up measuring what it can measure, not necessarily what matters most.

Technical hiring doesn't need to abandon signals, but it does need to put them in their place: as incomplete clues, not as final proof of criteria.

A conversation about real projects can reveal a lot: what decisions a person made, what failed, what they learned, what they would have done differently. That kind of evidence still exists, but often arrives late, after filters that don't know how to read context.

A CV might say “Kubernetes”. It doesn't say if the person knows when not to use Kubernetes. It might say “microservices”. It doesn't say if they understand the cost of a distributed system. It might say “senior”. It doesn't say if they know how to do a code review that improves the team without humiliating anyone.

Technical hiring has a huge opportunity there: stop asking only “what can you name” and start asking “what can you sustain”.

It's not about eliminating technical tests. It's about bringing them closer to real work: reading a system, diagnosing a bug, explaining a trade-off, designing a migration, reviewing a decision, communicating uncertainty, prioritizing under constraints.

Because real work rarely resembles solving an isolated problem with a perfect answer. It's more like navigating an incomplete system, with partial information and concrete consequences.

When the system rewards superficial signals, some skills begin to lose visibility.

Patience for debugging erodes: formulating hypotheses, isolating variables, testing, refuting, measuring, and repeating. The reading of deep documentation erodes, because a quick answer seems sufficient until it isn't. Architectural judgment erodes, because “best practice” sounds more convincing than “it depends, and these are the conditions.” Experience operating systems erodes, because many consequences remain hidden behind platforms, separate teams, or automations that work until they fail.

Something less technical also erodes: narrative responsibility. The ability to explain why a decision was made, what alternatives were discarded, what risks remained open, and what signals would indicate a change of course.

It's not advisable to turn this into a generational complaint. There are new people with admirable depth and people with many years who never developed judgment. The important division is not between juniors and seniors, nor between then and now. It is between superficial learning and applied experience.

The system incentivizes the superficial because the superficial is easier to measure. Badges, exact years, tool lists, flashy repositories, quick answers. The profound demands more conversation, more evidence, and more context.

The cost of measuring the surface doesn't always appear immediately. Often it accumulates in decisions that seem reasonable until the system starts to depend on them.

A team can use an ORM without looking at the SQL it generates. It can deploy microservices without understanding their operational cost. It can accept an AI-generated solution without reviewing edge cases. It can add cache without asking about invalidation.

Each decision can seem reasonable in isolation. The problem appears when they all coexist in production.

Technical debt rarely arises as an obvious error. Often it arises as a plausible solution that no one understood well enough.

Balance matters. This article wouldn't make sense if it only looked at loss.

We gained better tools. TypeScript prevents errors that used to appear late. Design systems organize interfaces. CI/CD pipelines make delivery safer. Observability allows us to understand systems that were previously black boxes. Cloud platforms reduce an enormous amount of operational work. Automated tests, when well-thought-out, provide real confidence.

We gained community. Stack Overflow, GitHub, interactive documentation, newsletters, Discords, remote conferences, open repositories, and technical blogs made knowledge circulate at a speed that would have seemed impossible before.

We gained access. Today, someone can learn from a modest connection, deploy a product, receive feedback, collaborate on open source, and rely on AI to unlock parts of the journey. That's not insignificant. The barrier to entry has lowered.

We gained better practices. Hexagonal architecture, DDD, accessibility, observability, supply chain security, design systems, platform engineering, living documentation. Not everything always applies, but the professional vocabulary is richer.

The question, then, is not how to go back. We don't have to go back.

The question is how to prevent the abundance of tools from making us lose the ability to think.

The abundance of tools is not the problem. The tension arises when creating becomes easier than understanding what has just been created.

Before, starting was difficult and understanding was almost mandatory. Today, starting is easier, but understanding can seem optional for longer.

That is a victory and a risk at the same time.

The democratization of creation does not guarantee the democratization of understanding. That gap—creating without fully understanding—is one of the central tensions of contemporary development.

AI enters this story as an accelerator and as a mirror.

It can write code, explain errors, generate tests, summarize documentation, propose refactors, translate between languages, detect repetitive patterns, and act as a kind of always-available coworker. In well-defined tasks, the speed improvement can be real.

But it also exposes a fragility: if a person doesn't understand what AI produces, speed becomes a liability.

AI doesn't eliminate the need for expertise. It makes it more visible.

A discerning profile can use it to explore alternatives, review assumptions, accelerate mechanical tasks, and document better. A profile without sufficient understanding may accept plausible code, weak tests, out-of-context architecture, or solutions that pass a demo but fail in production.

The question is no longer just who wrote this code.

The question is who understands this solution enough to take responsibility for it.

Here this article converses with IA sin mitos, but does not repeat its theme. There the focus was the prompt and the context. Here the focus is the craft. AI can change speed, but it does not change the responsibility of understanding.

In reality, it makes it more important. Because a tool that generates faster also allows for making mistakes faster, integrating faster, and multiplying consequences faster.

AI changes the speed of work, but it doesn't eliminate the most uncomfortable professional question: who understands, validates, and is responsible for what goes into production.

AI can generate. Humans must validate. AI can suggest. Humans must decide. AI can accelerate. Humans must understand what is being accelerated, in what direction, and at what cost.

That shift changes professional value. The scarce skill is no longer just producing lines of code. It's knowing what to ask for, what to review, what to reject, what to document, and when an apparently correct answer is still insufficient.

If the industry wants to better measure experience, it needs to look at evidence closer to real work.

Value solving real problems: not just completing a tutorial, but diagnosing a failure with constraints, affected users, and consequences. Value explaining decisions: not "I used this tool because it's modern," but "I chose this option due to these conditions and discarded these others due to these costs." Value learning new technologies in depth: not just installing, but breaking, repairing, comparing, and understanding limits.

Value systems thinking: seeing how an interface decision affects an API, how a query affects a database, how a queue changes product semantics, how a dependency introduces risk. Value communicating trade-offs: explaining uncertainty without hiding it behind jargon. Value validation: tests, metrics, observability, human review, and explicit criteria.

And value something that is almost never rewarded enough: knowing when a tool doesn't apply.

Technical maturity is not about always using the most advanced. Many times it consists of choosing a boring solution because the problem doesn't warrant more complexity.

To measure experience more fairly, it's advisable to distinguish between easy-to-read signals and evidence closer to real work.

• An extensive list of technologies can open a conversation. Real evidence appears when a person explains decisions with context and consequences.

• An isolated certification demonstrates exposure to a topic. Experience appears when that knowledge is applied under real constraints.

• A tutorial project teaches a known path. A solved, documented, and reviewed self-made problem carries more weight.

• A quick AI response speeds up the draft. What's important is human validation: tests, limits, and judgment before accepting the solution.

None of this is perfect. Experience isn't easy to measure either. But if we don't try to measure it better, we'll keep hiring signals and expecting results.

The industry doesn't need to go back to the past. The 2003 webmaster is not the model. They had their own limits: less security, less accessibility, less scale, less specialization, and too much improvisation.

But that era left a lesson worth not losing: knowing tools is not the same as understanding problems.

That distinction is not simply certified. It doesn't fit entirely in an ATS. It doesn't summarize well in a list of keywords. It's demonstrated in decisions, post-mortems, code reviews, honest documentation, maintainable systems, difficult conversations, and the ability to assume consequences.

The tool changed. The question remains the same: do you understand what you build?

That's why this article belongs to About Me Platform. Because this portfolio is not just about showing finished projects, pretty screens, or technologies used. It's also about documenting a way of working: looking at complete systems, connecting design and development, understanding tools without idolizing them, using AI without delegating judgment, and building evidence around real decisions.

My work lives precisely at that intersection. CMS, frontend, design, automation, structured content, tool integration, AI, and editorial experience are not separate pieces. They are layers of the same craft: converting ambiguous problems into systems that someone can use, maintain, and explain.

That's the final point of the series. Invisible technology showed that the interface is no longer always on the screen. AI without myths showed that value is not in a secret phrase, but in designing context. This article closes the circle from the profession: tools change, but judgment remains the part that must account for what has been built.