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

There is something strange in many conversations about software development. A job post asks for React, Next.js, TypeScript, Node, PostgreSQL, AWS, Kubernetes, Docker, CI/CD, testing, architecture, advanced English, leadership ability, product experience and desirable certifications. A resume answers with another list. An ATS looks for matches. An interview confirms vocabulary. A technical test measures one small part of the craft.

Everything looks organized. Everything looks objective. Everything looks efficient.

But somewhere along the way, the central question gets lost.

We do not always ask whether the person understands real systems. Whether they can debug without panicking. Whether they can read legacy code without contempt. Whether they recognize when a modern solution is excessive. Whether they can explain a technical decision without hiding behind jargon. Whether they can anticipate consequences before production turns them into an emergency.

It is not that tools do not matter. They matter a lot. Every technology in a job post usually comes from a concrete need, an existing architecture or accumulated pain in a team. The problem appears when the list starts to operate as a substitute for something harder to measure: judgment.

When did we start measuring knowledge through keywords?

The question is not meant to idealize the past. The industry was not purer before, nor wiser, nor fairer. There was also improvisation, manual deployments, poor security, weak documentation and learning through painful mistakes. 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. That has allowed us to build extraordinary products. It has 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 thing.

Experience is not knowing how to name technologies. It is having faced enough real problems to recognize patterns, anticipate consequences and choose with judgment when no perfect recipe exists.

That distinction changes everything.

This is not an attack on frameworks, certifications, bootcamps, AI, specialization or fast content. All of that can be useful. Often it is necessary. The problem appears 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 those signals, by itself, proves that a person can sustain a decision when the system fails, when the business applies pressure, when documentation is incomplete or when two correct solutions have different costs.

Experience forms in that uncomfortable zone. Not when everything works in the happy path, but when you need to form a hypothesis, measure, make a mistake, correct, explain and take responsibility for the consequences.

That displacement becomes clearer if we look at what happened to signals of experience. The list grew, but its ability to explain judgment became more limited.

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

The list grew. The essential question remains the same:

Do you understand the problem well enough to choose, build, validate and answer 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, mark it up in HTML, adjust CSS for incompatible browsers, write PHP or ASP, create tables in MySQL, upload files through FTP, configure email, review logs and explain to the client why a form should not store passwords in plain text.

Seen from today, that world looks small. In many ways it was. Projects had fewer layers, less automation, lower availability expectations and fewer integrations with external systems. Complexity could fit, with difficulty, in one head.

But it should not be romanticized. There were fewer standards, weaker security, almost nonexistent accessibility, manual deployments, uncertain backups and a culture of “if it works, do not touch it” that could become dangerous. Many good practices today exist precisely because that way of working did not scale.

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

Whoever changed a query saw the effect on the server. Whoever uploaded files by FTP understood the risk of breaking production. Whoever handled 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 inside an operation, a business and an experience.

Nostalgia is not the point. What matters is recovering what that closeness between code, server, client and consequence used to teach.

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

How do we preserve system literacy when the work no longer fits inside one head?

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

The important thing is not to return to a more fragile way of building. It is to preserve the ability to read how parts connect: how a UI decision affects data, how a data decision affects performance, how deployment habits affect reliability and how a small assumption becomes operational debt.

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. That expansion made specialization inevitable.

Modern frontend did not appear as a whim. It exists because interfaces became more dynamic, accessible, measurable and complex. Backend became more professional because business logic, data, security and integrations demanded more rigor. DevOps and SRE appeared because manual deployment stopped being acceptable for systems that must operate all the time. UX, product, data, mobile, security, QA and platform grew because software stopped meaning only “make it work.”

Specialization gave us depth. Better interfaces. Better deployments. Better observability. Better accessibility. Better product design. Systems capable of operating at scales that once seemed impossible.

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

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

We gained depth by area. What remains difficult is connecting those areas without each one defending its border as if it were the whole world.

That displacement becomes clearer if we look at what happened to signals of experience. The list grew, but its ability to explain judgment became more limited.

We moved from “one person tries to understand everything” to “many people understand different parts.” That shift was necessary. But it requires a skill that rarely appears in a job post: translating between layers.

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

That kind of understanding is transversal. It lives in the ability to ask better questions across boundaries: what does this abstraction hide, what dependency does this create, what operation will maintain it, what user will pay for the complexity and what evidence will tell us whether the decision worked?

Every era of web development had a tool that promised to organize the chaos.

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

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

The pattern repeats: a tool appears that reduces friction, becomes a standard, enters job postings and eventually part of the industry starts confusing mastery of the tool with understanding of the principle that made it necessary.

That fascination with tools did not appear all at once. Each wave promised to reduce a real friction and, at the same time, moved the conversation toward a new layer of abstraction.

jQuery made an incompatible web more habitable. AngularJS looked for structure in complex client applications. React made interface composition central. Vue and Svelte reminded us that ergonomics is also an architecture decision. Next, Remix and Astro moved the conversation from UI framework to complete system: rendering, data, performance and deployment. The edge and server-first era mixed frontend, backend, infrastructure and experience again.

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

Learning the tool without the principle leaves you exposed to the next change in fashion. Learning the principle without the tool can leave you outside the conversation.

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

It has never been easier to start building software. That is good news.

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

But starting is not the same as understanding.

The quick tutorial teaches a happy path. A bootcamp can open a door. A certification can organize vocabulary. A short video can unlock an idea. An AI assistant can explain an error. None of that should be dismissed.

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 breaks when conditions change or what it will cost to maintain it for years does not always grow with it.

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

Understanding requires friction that does not always fit the fast format: reading documentation, forming mental models, comparing alternatives, failing, debugging, reviewing past decisions and seeing consequences. It is less flashy. Less viral. Slower. It is also more resistant.

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

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

The problem is hierarchy. When the fast source fully replaces the primary source, knowledge becomes more fragile.

Official documentation, RFCs, specifications, source code and post-mortems are usually less attractive than a tutorial, but they teach something the 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 each other.

If job posts ask for lists of technologies, resumes fill with lists. If filters search for keywords, people optimize for keywords. If technical tests reward exercises disconnected from real work, candidates train for that kind of exercise. If certifications become symbolic requirements, a race to accumulate signals appears.

It is not the fault of one side. 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 does not need to abandon signals, but it does need to put them in their place: as incomplete clues, not as final proof of judgment.

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

A resume can say “Kubernetes.” It does not say whether the person knows when not to use Kubernetes. It can say “microservices.” It does not say whether they understand the cost of a distributed system. It can say “senior.” It does not say whether they can do a code review that improves the team without humiliating anyone.

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

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

Real work rarely looks like solving an isolated problem with one perfect answer. It looks more like moving through an incomplete system, with partial information and concrete consequences.

When the system rewards superficial signals, some abilities start losing visibility.

Patience for debugging erodes: forming hypotheses, isolating variables, testing, refuting, measuring and repeating. Deep documentation reading erodes, because a quick answer seems enough until it stops being enough. 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, separated teams or automations that work until they fail.

Something less technical also erodes: narrative responsibility. The ability to explain why a decision was made, which alternatives were rejected, which risks remain open and which signals would indicate that the direction needs to change.

This should not become a generational complaint. There are new people with admirable depth and people with many years who never developed judgment. The important division is not juniors versus seniors, or before versus now. It is superficial learning versus applied experience.

The system incentivizes the superficial because the superficial is easier to measure: badges, exact years, tool lists, polished repositories, fast answers. Depth requires more conversation, more evidence and more context.

The cost of measuring surface does not always appear immediately. Often it accumulates in decisions that seem reasonable until the system starts depending 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 may look reasonable in isolation. The problem appears when they all live together in production.

Technical debt rarely appears with the face of an obvious error. Often it is born as a plausible solution nobody understood well enough.

The balance matters. This article would make no 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 lets us understand systems that used to be black boxes. Cloud platforms reduce a huge amount of operational work. Automated tests, when well designed, 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 once would have seemed impossible.

We gained access. Today someone can learn from a modest connection, deploy a product, receive feedback, collaborate in open source and lean on AI to unblock parts of the path. That is not minor. The barrier to entry came down.

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

The question, then, is not how to go back. We should not go back.

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

Specialization works better when each part keeps sensitivity toward the others. Without that translation, depth becomes a border.

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 both accelerator and 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-bounded tasks, the speed improvement can be real.

But it also exposes a fragility: if a person does not understand what AI produces, speed becomes debt.

AI does not eliminate the need for experience. It makes it more visible.

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

The question is no longer only who wrote this code.

The question is who understands this solution well enough to be responsible for it.

Here this article speaks with AI without myths, but it does not repeat its topic. There, the center was the prompt and context. Here, the center is the craft. AI can change the speed, but it does not change the responsibility to understand.

In fact, it makes that responsibility more important. A tool that generates faster also allows us to make mistakes faster, integrate faster and multiply consequences faster.

AI changes the speed of work, but it does not remove the most uncomfortable professional question: who understands, validates and answers for what reaches production.

AI can generate. The human must validate. AI can suggest. The human must decide. AI can accelerate. The human must understand what is being accelerated, toward where and at what cost.

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

If the industry wants to measure experience better, it needs to look for 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 is modern,” but “I chose this option because of these conditions and rejected the others because of these costs.” Value learning new technologies deeply: not just installing, but breaking, repairing, comparing and understanding limits.

Value system 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 communication of 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 does not apply.

Technical maturity does not mean always using the most advanced option. Often it means choosing a boring solution because the problem does not deserve more complexity.

To measure experience more fairly, it helps to distinguish between signals that are easy to read 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 self-owned problem that was solved, documented and reviewed carries more weight.

• A quick AI response accelerates the draft. What matters is human validation: tests, limits and judgment before accepting the solution.

• A generic best practice can orient, but evidence appears when someone can situate the trade-off: who it applies to, when it is useful and at what cost.

None of this is perfect. Experience is not easy to measure either. But if we do not try to measure it better, we will keep hiring signals and expecting results.

The industry does not need to return to the past. The webmaster of 2003 is not the model. That role had its own limits: less security, less accessibility, less scale, less specialization and too much improvisation.

But that era left a lesson we should not lose: knowing tools is not the same as understanding problems.

That distinction cannot be certified simply. It does not fit completely in an ATS. It does not summarize well in a keyword list. It is demonstrated in decisions, post-mortems, code reviews, honest documentation, maintainable systems, difficult conversations and the ability to take responsibility for consequences.

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

That is why this article belongs to About Me Platform. This portfolio is not only about showing finished projects, polished screens or technologies used. It is also about documenting a way of working: looking at whole 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 in 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: turning ambiguous problems into systems someone can use, maintain and explain.

This is 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 answer for what is built.