When implementation becomes abundant, selection becomes the work.
For the better part of a decade, I operated under a straightforward framework for career growth as a developer.
Study the docs. Master Angular. Get comfortable with RxJS, dependency injection, change detection, testing, state management, and architecture. Observe how peers tackle challenges. Accumulate enough mistakes to appreciate why a particular approach wins over another.
That framework wasn't flawless, but it was straightforward: greater understanding meant greater autonomy, and faster paths to solid solutions were the mark of a better engineer.
Then AI arrived, and it made a significant chunk of what I had invested in remarkably inexpensive.
It can produce the implementation in moments. It can discover a library I've never encountered, consume its docs, weigh multiple strategies, and offer a viable starting point before I've gotten through the first API page.
This isn't another piece on AI replacing developers. I don't know how that narrative unfolds. My interest lies in a more immediate and unsettling query.
If code became cheap, what happened to the worth of my accumulated knowledge?
The Nature of the Cost Decline
I no longer feel the need to memorize a specific API. I don't require every RxJS operator to be at my fingertips. I can instruct an agent to explore a package, find its documentation, and kick off an implementation.
It would be false to claim nothing has shifted. A portion of my expertise has depreciated in market value: the ability to recall syntax and recreate standard solutions is less unique than it once was.
However, scarcity isn't equivalent to utility.
AI might not have devalued my knowledge; it may have simply ended my exclusive access to applying it.
This difference is significant because creating an answer and deciding if it fits into a real system are distinct tasks. The first is becoming vastly cheaper. The second still hinges on context: the specific product, the existing codebase, the team dynamics, the potential cost of failure, and the likely future changes.
The real-world productivity evidence is messier than what demos suggest. A 2025 randomized trial by METR showed that seasoned open-source maintainers, operating in codebases they knew intimately, were 19% slower when using early-2025 AI tools. The researchers were careful to limit that conclusion to their specific tools, participants, and tasks. Later METR experiments with newer agents indicated modest productivity gains instead. The outcome can flip depending on the model and the assignment. METR’s 2025 study isn't proof that AI slows down developers across the board, just as a two-hour app demo doesn't prove that production software has become easy.
In this scenario, access to early-2025 AI tools led to a 19% increase in completion time. The study observed 16 skilled open-source developers resolving 246 issues in well-known repositories.
Perhaps "Does AI make us faster?" is already too broad a question.
Faster at what exactly?
Frameworks vs. Real-World Problems
There was a related pitfall in our field long before generative AI came along.
When I first started, it was all too common to mistake a domain for a technology. Frontend was synonymous with Angular or React. Backend was Java, .NET, or Node. We labeled ourselves Angular devs, React devs, Java devs.
I'm an Angular developer myself. For years, that specialization gave my career direction. It also made it tempting to look for tools before identifying the problem.
Need state? There's a library for that.
Validation? Also a library.
Caching? A library.
Component communication? Surely another library exists.
Eventually, I started trying to flip that sequence. What is the actual problem? Is it a recognized type of problem? Are we dealing with something like an observer, a queue, a cache, a state machine, a concurrency issue, or an ownership concern? Only then do I ask: which Angular feature or library, if any, is the right fit?
That sequence is even more crucial now. AI excels at answering, "How do I implement this in Angular?"
The more difficult query is, "Should we implement it this way in the first place?"
Lessons from Angular Beyond Its APIs
If a model has a broader knowledge of Angular APIs than I do, does my Angular expertise still hold value?
I believe it does, though for a different reason than I initially thought.
RxJS taught me to reason about time, streams, and concurrency. Consider switchMap, concatMap, mergeMap, and exhaustMap. An agent can list their behaviors and generate code using any of them. The choice, however, remains a product decision expressed as code. Should a new request cancel the previous one? Queue behind it? Execute concurrently? Be disregarded if another is active?
There’s no inherently correct operator until the desired behavior is defined.
Dependency injection taught me to identify dependencies and understand inversion of control. Angular's documentation defines DI as providing a class with its dependencies rather than having it create them internally. The API is Angular-specific. The questions of who creates, owns, and can swap a dependency are universal principles. Angular’s DI guide.
State-management libraries forced me to consider where state should reside, who has the authority to alter it, and how widely it should be propagated. Components taught me about separation of responsibilities. The router demonstrated that navigation is a form of state. Tests taught me to articulate my expectations before trusting an implementation.
Even signals are more than just a function syntax. Angular presents them as a system for tracking where state is used to enable efficient updates. Knowing the API is helpful. Understanding dependencies, derived state, and reactive context is invaluable when the generated implementation behaves unexpectedly. Angular’s Signals guide.
Perhaps the true value of eight years with a framework isn't the API knowledge I can recall. It's the set of problems I learned to recognize through it.
That set makes AI more useful, not less.
Rethinking Verification
As AI writes more code, two polarizing viewpoints continue to surface.
On one side is outcome-first development. Describe the task, let the agent handle the implementation, run the app, verify the result, and accept the change. Don't spend time reviewing every line if the behavior is correct.
On the other side is code-first craftsmanship. AI might type the implementation, but a developer should still grasp the structure, inspect critical details, and ensure the codebase remains maintainable.
The source material for this article described three points on this spectrum: judging the outcome, defining the contract and constraints, or meticulously reviewing the generated code. I don't believe any single one is universally superior.
The more relevant question isn't, "Should I read AI-generated code?"
It's, "How will I establish sufficient trust in this change?"
For a one-off script that renames a few local files, I might check the inputs, run tests on copies, and compare outputs. Reading every line may offer little value.
For a prototype that's due to be discarded next week, a quick smoke test might be sufficient evidence.
For authentication, billing, user data, or a core system the team will maintain for years, "it seems to work" is nowhere near adequate.
The code generation is cheap in all three scenarios. The cost of failure is not.
The Role of Verification in Programming
Verification isn't limited to reading code. It can involve:
- a well-scoped change with explicit acceptance criteria
- type checking, linting, and static analysis
- unit, integration, and end-to-end tests
- security audits and dependency review
- another human or agent challenging the proposed solution
- monitoring in production
- a phased rollout with a solid rollback plan
None of these are silver bullets. Tests can validate the wrong requirements. A reviewer might overlook a subtle bug. Types can't prove a business rule is correct. Observability can only report damage after it's deployed.
Trust is built by combining evidence that matches the level of risk.
I find it helpful to consider five characteristics of a change:
Verification should be proportional to the cost and reversibility of failure.
Being targeted is key. Experience doesn't always mean reviewing everything. Sometimes it's about knowing exactly where to focus your attention.
This aligns with current developer survey data. In Stack Overflow's 2025 survey, more respondents distrusted AI accuracy than trusted it, and the most common complaint was an answer that was almost correct. Developers are already recognizing that generation and acceptance are distinct tasks. Stack Overflow Developer Survey 2025
DORA’s 2025 report characterizes AI as an amplifier of the surrounding engineering system. Faster generation is most beneficial when teams also have swift, reliable feedback loops. If a team already struggles to review, test, and deploy small changes, producing more code can exacerbate those weaknesses. DORA 2025.
The bottleneck may be shifting from code generation to evaluation.
However, that doesn't make the evaluator passive. Designing the evidence-gathering process is now a core part of the implementation work.
Experience as the Art of Choosing
An experienced developer has typically witnessed abstractions that promised simplicity but ultimately made things more complex.
- Global state adopted prematurely.
- A library that became impossible to remove.
- A framework applied to a problem that required a simple function.
- An elegant local design that clashed with the broader system.
- This insight is hard to translate into API knowledge. It represents a collection of learned consequences.
AI can present five architecturally sound solutions. My experience may alert me that one is too foreign for the team, another creates a lasting dependency for a short-term issue, and a third assumes a scale we'll never reach.
That doesn't mean the senior developer should cling to familiar solutions. AI can explore a broader space than I can, exposing me to unfamiliar patterns and challenging assumptions I've stopped noticing.
The value isn't in being perpetually correct. It's in questioning what each alternative optimizes for, which constraints are relevant here, and what evidence would show the choice to be wrong.
Experience is less about owning the implementation and more about owning the decision.
Is Fundamental Programming Education Still Necessary?
This gets more complicated for newcomers to the field.
If an agent can generate an application, should a junior still invest in fundamentals?
I think yes, but the rationale has shifted. The objective isn't to reproduce every implementation from memory. It's to form a mental model of how the system operates.
What happens when a request begins? Where is state stored? How does the system behave if the same event fires twice? What does cancellation entail? Why does the view re-render? What does a cache return after its source changes? Where do errors propagate?
Without that model, it's tough to tell a working result from one that only works under ideal conditions.
There's a genuine paradox here. AI can make programming easier to learn by explaining unfamiliar code, providing examples, and giving instant feedback. It can also make it easy to bypass the very friction that helps build a useful mental model.
We lack strong long-term evidence on how constant agent usage will affect junior developers. So, I don't want to treat this concern as an established fact.
However, I wouldn't equate completing more exercises with understanding more systems.
Genuine Adaptation versus FOMO
Developers have always experienced fear of missing out.
Learn React. Angular is dead. Try Vue. Use the new state library. Rebuild everything with the latest pattern.
AI has multiplied this pressure: a new model, agent, editor, MCP server, skill, subagent, context technique, or software factory appears weekly. Some claim they've deleted their IDE. Others say they no longer read code. A third person built an application in just two hours.
It's tempting to believe my current working style is already outdated.
I try to distinguish adaptation from FOMO using a simple test.
Adaptation starts with a problem and seeks a tool that improves the outcome.
FOMO starts with a tool and hunts for a problem that makes using it seem justifiable.
This is the same trap we fell into with libraries, just at a faster pace. Yesterday, we wanted a library for everything. Today, we might want an agent for everything. The vocabulary has changed, but the underlying thinking hasn't.
I do need to evolve my workflow. AI is more than just a more advanced autocomplete, and some skills I honed for years will be less critical. Denying that would be nostalgia.
But adapting doesn't mean copying the habits of someone building disposable side projects when I'm modifying a decade-old system. Context isn't resistance to change; it's the foundation upon which engineering is built.
The Real Cost of a Sound Decision
So, what holds value when code is cheap?
Identifying the problem. Establishing constraints. Choosing tools. Grasping trade-offs. Defining what "correct" means. Creating evidence. Troubleshooting what the agent missed. Understanding the product. Simplifying. Knowing the cost of failure. Deciding that something doesn't need to be built.
And accepting responsibility for the final result, even when I didn't write the code myself.
AI has cut the cost of generating code. It hasn't necessarily reduced the cost of making a good decision.
Reflecting on eight years of learning Angular and software development, I no longer see that time as wasted. I may have just been describing the objective poorly.
I thought I was learning to write progressively better code.
In many ways, I was learning to identify problems, anticipate consequences, and remember solutions that once seemed clever before failing later.
Today, I'm learning when to let AI write the code, when to review it, how to verify it, and when the best choice is not to generate anything at all.
Perhaps that's still what it means to learn programming.
Programming just no longer solely means writing code.