AI Models and Software Engineering
One of the most important subjects in modern software engineering is the influence of Large Language Models, generative AI systems, and increasingly autonomous AI agents on the way software is designed, implemented, reviewed, tested, and operated.
For people entering this profession, one question appears almost immediately:
Does it still make sense to learn programming and software engineering if AI systems can already generate code?
This question is understandable.
The public discussion around AI is often dominated by extreme positions.
One side presents AI agents as systems that will replace almost every developer and engineer.
The other side treats them as useless toys that have no serious place in professional engineering.
I do not believe either position is useful.
AI systems are already capable of producing meaningful software, accelerating certain tasks, generating useful technical material, assisting with debugging, navigating repositories, writing tests, and automating parts of development workflows.
That capability should be taken seriously.
But generating code is not the same thing as owning an engineering problem.
Producing a locally correct implementation is not the same thing as designing, operating, evolving, and taking responsibility for a system over years.
That distinction is the starting point of this chapter.
Is Software Engineering Still Worth Learning?
Absolutely, YES.
But the reason is not that AI systems are weak or that they will stop improving. They will improve.
The reason is that software engineering has never been only about typing source code.
Code is one representation of a much larger process. A real engineering process may include:
- understanding incomplete requirements;
- identifying the actual problem;
- rejecting unnecessary complexity;
- designing system boundaries;
- selecting technologies;
- reasoning about failure;
- understanding security consequences;
- planning migrations;
- preserving compatibility;
- operating production systems;
- debugging behavior that was never expected;
- controlling cost;
- communicating across teams;
- making trade-offs;
- deciding what should not be built;
- taking responsibility for the final result.
An AI system may participate in many of these activities. That does not automatically make it the owner of those activities.
A useful mental model is:
Code generation ≠ Software engineering.
and:
Producing an answer ≠ Owning the consequences of that answer.
If your entire professional value is based on manually producing predictable boilerplate, then AI will place increasing pressure on that part of your work.
If your value comes from understanding systems, making decisions, solving unfamiliar problems, validating results, designing for change, and taking responsibility for technical consequences, then the profession remains much broader than code generation.
The correct response to AI is not to stop learning. The correct response is to learn more deeply.
AI Models, Infrastructure, and Intellectual Property
One of the biggest problems surrounding AI models is the violation of intellectual property.
If you give any AI agent access to your infrastructure, your network, or your source code base, then every later discussion about security, data protection, and intellectual property becomes largely pointless. The moment you give an AI model access, you have already allowed a third party into your infrastructure.
At that point, if an unwanted scenario happens, you cannot act as though that access appeared out of nowhere.
You gave it permission. You gave it access. And you accepted that risk yourself.
We have already seen situations where all kinds of things happen in environments like this:
- A problem suddenly appears and nobody inside the technical teams knows how to fix it.
- A part of a database disappears.
- Certain permissions suddenly exist even though nobody knows how they got there.
- A system is modified in a way nobody clearly remembers authorizing.
And then everyone starts asking:
How did this happen?
The better question is:
Why was a third-party agent given access to that part of the infrastructure in the first place?
Do not think that absolutely everyone, from every technical environment, is enthusiastic about AI models or willing to give them access.
That is simply not true.
Our environment, as well as the environments of the partners we work with, has strict rules and conventions written into agreements with technical personnel.
One of many such rules is that technical staff are strictly forbidden from using AI agents for writing code.
Giving any AI agent access to any part of company intellectual property is also treated extremely seriously.
We will see what happens when legal cases begin appearing around questions such as:
- who created what;
- how something was created;
- who owns a specific implementation;
- what part was written by a human;
- what part was generated by an AI system;
- what data was exposed during that process;
- who can prove the origin of the implementation.
And then another question appears. What happens when:
- the companies operating AI models start claiming that they have evidence showing that their system generated a certain implementation inside someone else’s infrastructure?
- arguments begin over intellectual property ownership because a third-party model participated in building part of a proprietary system?
- nobody can clearly prove where one part ends and another begins?
Think about that.
Intellectual property around generative AI is still an active legal and regulatory area.
The correct response is not to invent certainty where certainty does not yet exist. Training datasets can involve combinations of:
- publicly available material;
- licensed material;
- proprietary material;
- synthetic data;
- other sources depending on the provider.
There are ongoing legal disputes and policy questions concerning the use of copyrighted works in AI training.
The U.S. Copyright Office has published a multi-part AI study addressing copyrightability and generative AI training. In the European Union, obligations for providers of general-purpose AI models include maintaining a copyright compliance policy and publishing a sufficiently detailed summary of training content. The legal environment is therefore actively evolving.
For engineering organizations, this creates practical questions:
- Are we allowed to send this source code to this provider?
- What does our customer contract allow?
- What does the provider’s agreement say about submitted data?
- Can generated code contain material that creates licensing concerns?
- Can we prove which parts of a product were human-authored?
- Do we maintain provenance for important generated artifacts?
- Are we exposing trade secrets?
These are governance questions. They should be answered before an agent is connected to sensitive systems.
AI-Assisted Work and Copyright
Another point needs precision.
Using AI during development does not automatically mean that the resulting software has no copyright protection.
For example, the U.S. Copyright Office has stated that human-authored expressive contributions can remain protected even when AI is used as an assistive tool.
The difficult questions concern the amount and nature of human authorship, the provenance of generated material, training-data rights, and the contractual terms under which specific tools are used.
Therefore, organizations should not rely on simplistic statements such as:
AI touched the code
↓
nobody owns it
or:
AI wrote part of the code
↓
the AI provider owns part of the product
Those conclusions do not follow automatically. The responsible approach is:
- define company policy;
- understand provider terms;
- preserve provenance where important;
- protect confidential material;
- obtain legal advice where the risk justifies it.
Application Development and Technology Development
At the beginning of this discussion, we need to separate software development sharply into two different areas.
There is:
- application development
- technology development
Application development is the kind of development in which engineers use existing technologies to create new services and applications.
Technology development is the kind of development in which developers create new technologies and systems that engineers and other technical people will later use when building services and applications. A practical example of application development would be building infrastructure for aviation traffic.
Technology development made it possible to create things such as:
- different types of software communication systems;
- different programming languages;
- different database architectures;
- different mechanisms and standardized protocols;
- different security systems;
- different operating systems;
- different server models and runtime environments.
All of these are then used by the application layer under the hood. There are AI agents that can help in certain areas of application development.
That is not the problem. The point is that their role is that of an assisting tool.
They should not become the mechanism that a technical person depends on.
And they should not become the foundation of an engineering process where the person becomes incapable of functioning without them.
LLM and AI systems build their outputs from statistical patterns, metrics, and previously existing data.
A mechanism built around existing patterns can be useful when working with things that have a generic form or that contain relatively small automated processes. A simple informational website is a good example. In that kind of work, an AI agent can be extremely useful. It can generate layouts, components, basic backend logic, configuration, boilerplate, and repetitive structures very quickly. But only up to a certain point.
As complexity increases, as the number of features increases, and as the amount of required context grows, the system becomes harder and harder for the model to hold together coherently.
At some point, the agent stops being useful. After that point, it can become actively dysfunctional.
Then it can:
- starts losing track of earlier decisions.
- begins introducing contradictions.
- changes one part of the system without understanding what that change breaks somewhere else.
- starts inventing things that were never defined.
- begins presenting unverified assumptions as though they were facts.
- eventually, instead of reducing work, it starts generating additional work.
We started with the most basic possible form: A website. Now take a much larger infrastructure.
Imagine a platform containing many services and applications, built by many teams:
- Different teams are building different parts.
- Some teams operate in completely separate environments.
- Services depend on other services.
- Internal protocols exist.
- Different databases exist.
- Different security rules exist.
- bDifferent deployment environments exist.
- Different versions exist.
- Different migration paths exist.
Now the situation changes completely. At that point it becomes very obvious what an AI agent actually is:
A tool. It can be useful. It can be functional.
It can be extremely powerful in the right hands.
AI model is not the initiator, owner, or creator of the entire engineering process.
The context limit of an AI system represents a numerical limitation on how much information the system can actively process within a given interaction. Once the amount of relevant information becomes too large, the model begins losing parts of the conversation and system context.
The larger that problem becomes, the easier it is for the model to start hallucinating, contradicting earlier information, or writing things that were never verified and may never have existed in the first place. Now increase the size of the infrastructure. Think about:
- financial systems;
- stock exchanges;
- electrical power systems;
- security systems;
- operating systems;
- cloud infrastructure;
- distributed storage systems;
- large internal platforms.
The operational scope, complexity, number of dependencies, and long-term development of systems like these are far beyond what can be treated as one simple AI conversation. And in environments like these, some of the most important properties are:
- flexibility;
- modularity;
- scalability.
Only after that do we start talking about:
- performance;
- resource usage.
Large infrastructure has to be designed many steps ahead. Sometimes fifty steps. Sometimes a hundred. You have to think about what happens after:
- the next feature;
- the next service;
- the next migration;
- the next operating-system version;
- the next protocol change;
- the next security requirement;
- the next scaling problem;
- the next five years of development.
AI agents naturally tend to satisfy the current request. You give the system a problem. It attempts to produce something that works for that problem now. If the current context allows it, it generates a solution that appears correct at that moment.
That is a terrible way to design serious long-term infrastructure.
Infrastructure built to the highest technical standards does not work like that.
It requires:
- planning;
- sketching;
- designing;
- rejecting ideas;
- redesigning;
- thinking through future interactions;
- thinking through failure cases;
- considering changes that have not happened yet.
The problem is that an AI agent does not have an independent understanding of what will happen in future iterations of your system. It knows what you give it now. If every future update or upgrade requires large parts of the generated code to be rewritten, then the original design was not good. A system that constantly requires massive refactoring because every new feature breaks the previous assumptions was badly designed from the beginning.
That is not scalability. That is not modularity. That is not good engineering.
This becomes even more obvious in very large infrastructures and technical conglomerates. AI models can be strongly promoted internally. They can be introduced aggressively. They can be used everywhere people believe they may reduce cost or increase speed. But once the work reaches a certain level of complexity, teams very quickly discover the difference between:
Generating code and Understanding the entire system.
Those are not the same thing.
AI models begin losing the overall picture as the amount of code, dependencies, interaction, historical decisions, and system-specific knowledge grows.
Now imagine an infrastructure like ours.
Eighteen services. More than twenty thousand lines of code per service on average. A large number of interactions between those services.
Multiple factors on infrastructure level:
- Shared behavior.
- Dependencies.
- Protocols.
- Versioning.
- Deployment logic.
- Internal assumptions.
- Future development.
And that is still a relatively small infrastructure compared with the systems operated by the largest technology companies in the world. Now imagine what happens at that scale. The idea that one AI agent simply “understands the whole thing” because it can generate code inside one part of it is completely unrealistic. That is exactly where the distinction has to be made:
- AI can assist development.
- AI can automate repetitive work.
- AI can generate useful implementation.
- AI can help experienced engineers move faster.
But a tool that generates code should never be confused with the engineering system, the engineering process, or the people responsible for designing and owning the infrastructure.
The Mental Effect of Constant AI Dependency
Another subject that needs to be discussed much more openly is the effect that frequent AI use can have on technical people themselves.
Not only technically. Mentally as well.
AI models can be extremely useful for generating generic structures and reducing the amount of repetitive work that does not require much creativity, design, or deep technical reasoning.
That is useful, but there is another side to it.
The more frequently people delegate even basic technical thinking to AI systems, the easier it becomes to become mentally lazy about things that they previously would have solved themselves.
And if you become lazy about basic problems, you will not suddenly become disciplined when a truly difficult problem appears.
You gradually lose patience. You gradually lose tolerance for uncertainty.
You become less willing to sit with a problem for hours or days.
You become accustomed to receiving some form of result almost immediately.
That is completely incompatible with serious engineering.
No serious science, engineering discipline, or long-term technical development works on the assumption that every meaningful problem must produce a visible result within several hours.
Real work often does not behave like that.
Sometimes you will spend:
4 hours
and achieve almost nothing visible.
Sometimes:
3 days
Sometimes:
3 weeks
And sometimes you will work on a problem for months before the pieces finally connect into something functional.
That process develops:
- patience;
- endurance;
- analytical depth;
- problem decomposition;
- emotional stability;
- technical intuition;
- the ability to remain functional while the answer is still unknown.
If every difficult moment immediately becomes [Ask the AI].
you can slowly destroy your tolerance for exactly the kind of mental state that serious engineering requires.
There is also another effect.
People begin to feel less capable without the tool. They become less confident in their own ability to investigate.
They become less satisfied with their own work. They stop feeling productive unless something visible is generated quickly.
Anything that cannot be completed within a few hours or within a single working day starts to feel mentally heavy.
This is dangerous. You are conditioning yourself to expect immediate output. But immediate output does not automatically have:
- depth;
- quality;
- reliability;
- technical weight;
- maintainability;
- credibility.
A large amount of generated output can look impressive while containing very little actual engineering value.
This problem can become even more obvious in technical areas, ecosystems, or programming languages where there is less high-quality public information available.
AI systems are strongly dependent on the quality and quantity of the material from which they have learned and the context they are given.
Where the public technical ecosystem is weaker, narrower, poorly documented, or dominated by repetitive material, the quality of generated output may also degrade significantly.
That is another reason why you need your own technical judgment.
Do not measure yourself by how quickly an AI agent can produce something.
Measure yourself by whether you understand what was produced.
Whether you can verify it. Whether you can improve it. Whether you can repair it when it fails.
And whether you can continue working when the tool is removed.
If you cannot function without the AI system, then the AI system is no longer helping your engineering ability.
It has replaced part of it. That is dependency and dependency should never be confused with productivity.
Generation Is Not Verification
One of the biggest changes created by AI-assisted development is that generating code can become much faster than validating code.
Before widespread generative AI, one bottleneck was often: Writing the implementation.
With AI assistance, the bottleneck can move:
Understanding the requirement
↓
Reviewing generated code
↓
Testing
↓
Security verification
↓
Integration
↓
Operational validation
↓
Long-term maintenance
This gives us an important equation:
10× faster code generation ≠ 10× faster software engineering.
DORA’s 2026 analysis describes a similar tension: AI can reduce friction during initial code generation, while part of the time saved is later reallocated to auditing and verification.
That does not mean AI is ineffective.
It means that measuring only the speed of code production can be misleading.
The final unit of value is not:
How many lines were generated?
The useful questions are:
- Was the correct system built?
- How much review was required?
- How many defects were introduced?
- How maintainable is the result?
- How much operational risk was created?
- How easily can the system evolve?
- Can the team explain what was produced?
Context Windows Are Not System Understanding
Every LLM has a finite working context.
A context window defines how much information can be made available to the model during a particular interaction.
But one thing needs to be made absolutely clear:
Being able to receive information is not the same thing as understanding the entire system that information belongs to.
A model can technically accept a very large amount of text and still fail to correctly connect every relevant dependency, architectural decision, historical assumption, or interaction inside that material.
As the amount of information grows, the problem is no longer simply:
Can the model read this?
The real question becomes:
Can the model preserve the correct relationships between all relevant parts of the system?
Those are completely different problems.
A large context window does not automatically mean that the model has a complete and coherent understanding of everything inside it.
It may receive:
- source code;
- documentation;
- configuration;
- logs;
- database schemas;
- API definitions;
- architectural descriptions.
That still does not mean it understands all of the interactions between them correctly.
And the larger and more interconnected the system becomes, the harder that problem becomes.
Modern agents can partially compensate for this through:
- repository search;
- retrieval systems;
- code indexes;
- tools;
- subagents;
- summaries;
- external memory;
- iterative exploration.
That absolutely makes them more capable.
But none of those mechanisms change the fundamental problem.
A repository is not the same thing as a complete system.
And a complete system is not only source code. It is also:
source code
+
service dependencies
+
database behavior
+
deployment rules
+
network topology
+
security assumptions
+
historical decisions
+
production incidents
+
migration plans
+
internal conventions
+
future requirements
+
knowledge that exists only inside engineers' heads
That is the real context of a serious infrastructure.
So the deeper limitation is not simply the number of tokens that fit inside a context window.
The deeper limitation is system knowledge.
An AI agent may be able to inspect thousands of files. It may search them efficiently. It may summarize them. It may even make useful changes across many of them.
But that should never be confused with having complete ownership and understanding of the entire technical system. Those are not the same thing.
Large Systems Are Designed for Change
In large infrastructure, immediate functionality is only one requirement.
A system also needs to survive change. Some of the most important qualities are:
- modularity;
- clear boundaries;
- flexibility;
- scalability;
- observability;
- maintainability;
- recoverability;
- compatibility.
Performance and resource consumption matter as well, but optimizing those properties without preserving the ability to evolve can produce a system that is fast today and extremely expensive to change tomorrow. A locally functional implementation may still be a poor engineering decision. For example:
Requirement satisfied today
↓
but
↓
every future feature requires rewriting three services
That is not a good design. This is why experienced engineers frequently spend significant time on:
- diagrams;
- interfaces;
- data ownership;
- failure boundaries;
- migration paths;
- future extension points;
- operational behavior.
AI can assist with all of these, but it cannot know requirements that nobody has communicated to it.
It cannot reliably optimize for future constraints that the organization itself has not yet identified.
And it cannot take responsibility for strategic decisions that were never made explicit.
The Problem of Future Iterations
Engineering is rarely a single interaction. A production system may live for:
- 5 years
- 10 years
- 20 years
During that period:
- teams change;
- requirements change;
- dependencies change;
- security threats change;
- regulations change;
- traffic changes;
- hardware changes;
- business priorities change.
A design must therefore have some ability to absorb unknown future changes.
No human architect can predict every future requirement in 100% of the cases. AI cannot either.
The goal is not prediction. The goal is designing systems with boundaries and abstractions that make future change less destructive. That requires judgment. And judgment is built from:
- theory;
- implementation experience;
- failed designs;
- production incidents;
- migrations;
- performance problems;
- security failures;
- maintenance experience.
An AI system may encode patterns derived from enormous amounts of technical material.
But an engineering organization still needs people who can evaluate whether those patterns fit its actual environment.
Benchmarks Are Not Production
AI coding benchmarks are useful. They tell us something. They do not tell us everything. A benchmark normally defines:
- an input;
- a task;
- an evaluation method;
- a success condition.
Real software engineering often has none of those properties clearly defined. The specification may be incomplete. The tests may be wrong.
The correct behavior may depend on undocumented business knowledge. Two technically valid solutions may have completely different operational consequences. A system may pass every available test and still be unacceptable in production. A useful 2026 METR study examined AI-generated pull requests that had already passed the automated SWE-bench Verified grader. Maintainers reviewing those patches would reject roughly half of the test-passing AI pull requests in the studied sample. The researchers explicitly caution that this does not establish a fundamental capability limit, because real agents could iterate after code review feedback.
The important lesson is simpler:
Passing an automated benchmark is not equivalent to passing real engineering review.
That difference matters.
Developer Sentiment Is More Complicated Than the Marketing
The 2025 Stack Overflow Developer Survey provides another useful perspective.
AI adoption is very high. At the same time, trust is significantly lower than adoption.
Among respondents:
- 84% were using or planning to use AI tools in development;
- more developers reported distrusting AI output accuracy than trusting it;
- 66% identified “almost right” AI solutions as a major frustration;
- 45% reported that debugging AI-generated code could take more time;
- developers showed especially strong resistance to delegating high-responsibility areas such as deployment and monitoring.
This is a useful reminder: High adoption ≠ High trust.
A tool can be useful enough to use every day while still requiring constant verification.
AI Should Amplify Knowledge, Not Replace It
This is the rule I would strongly recommend during learning:
Never allow a tool to become the owner of a thought process that you are still supposed to be learning.
There is a major difference between these two scenarios.
Scenario A
An experienced engineer understands:
- the problem;
- the implementation;
- the failure modes;
- the architecture.
They ask an AI system to generate repetitive code.
The engineer reviews it, modifies it, tests it, and accepts responsibility for it.
AI reduced mechanical work.
Scenario B
A beginner does not understand:
- the problem;
- the implementation;
- the failure modes;
- the architecture.
They ask an AI system for the complete solution.
The code runs.
They move to the next task.
These two people may produce the same visible output today.
They are not building the same capability.
The first person automated something they already understood.
The second person may have automated the exact cognitive process that was supposed to develop their understanding.
This is where AI can become dangerous for learning.
Not because asking AI a question is bad.
Not because generated code is automatically bad.
The danger is dependency.
Cognitive Dependency
If every obstacle immediately becomes [Ask the model]
your tolerance for unresolved problems can gradually decrease.
You can become accustomed to: [question => immediate answer].
But serious engineering often looks like:
problem
↓
wrong hypothesis
↓
investigation
↓
new evidence
↓
another wrong hypothesis
↓
documentation
↓
experiment
↓
partial understanding
↓
more investigation
↓
solution
Sometimes that process takes twenty minutes. Sometimes it takes three days. Sometimes it takes months.
Your ability to remain calm inside an unresolved problem is part of your engineering ability.
If every unresolved state becomes psychologically uncomfortable because you are used to immediate generated answers, that can become a real weakness.
I am not presenting this as proof that AI necessarily makes engineers mentally weaker.
Research on the human effects of AI-assisted work is still developing, and some studies report positive effects on developer well-being and flow.
My point is narrower:
Using AI without discipline can remove exactly the friction from which some forms of technical ability are developed.
Use the tool. Do not surrender the learning process to it.
Ask Yourself One Question
When AI gives you an implementation, ask yourself:
Could I explain why this works without asking the model again?
Then go further:
- Can I explain every important dependency?
- Can I explain the failure paths?
- Can I modify it safely?
- Can I debug it when the model is unavailable?
- Can I recognize when the answer is wrong?
- Can I defend the architectural decision?
- Can I operate it in production?
If the answer is no, then the AI has probably moved faster than your understanding.
That may be acceptable for a temporary experiment. It is dangerous as a permanent engineering model.
AI-Generated Code Still Requires Ownership
Imagine that an agent generates:
- service
- database migration
- deployment configuration
- tests
- monitoring
Everything passes. Three months later, the migration fails under a production edge case and corrupts data.
Who owns the incident? Not the prompt. Not the token stream. Not the model. The engineering organization owns it.
Responsibility cannot be delegated simply by delegating implementation.
This is why high-responsibility environments require human verification.
NIST’s DevSecOps guidance explicitly recommends that AI-generated software content be monitored and validated by humans, with verifiable processes to prevent uncritical acceptance of insecure or non-functional code. That is exactly the right mental model.
AI Access Creates a New Trust Boundary
Another major issue is not code quality at all. It is access.
If you connect an AI system or agent to:
- private source code;
- production systems;
- databases;
- internal documentation;
- issue trackers;
- logs;
- credentials;
- deployment systems;
- customer data
you have created a new trust boundary.
That does not mean that you automatically lose ownership of your intellectual property.
It means that your threat model has changed.
You now need to understand:
- what information is transmitted;
- where it is processed;
- how long it is retained;
- whether it is used for training;
- which subprocessors can access it;
- which jurisdictions are involved;
- what contractual protections exist;
- what permissions the agent has;
- whether actions are logged;
- whether actions require approval;
- how secrets are protected;
- how access is revoked.
This should be treated like any other serious external dependency. The correct question is not:
Is AI secure?
That question is too vague.
The correct questions are:
Which model?
Which provider?
Which contract?
Which data?
Which permissions?
Which environment?
Which retention policy?
Which actions?
Which audit controls?
Least Privilege Applies to Agents Too
An AI agent should not receive more access merely because giving it broad access is convenient.
The same security principles used for human users and services should apply:
- least privilege;
- separation of duties;
- explicit authorization;
- environment isolation;
- secret management;
- audit logging;
- approval gates.
For example:
Read repository
does not automatically imply:
Write repository
and:
Write repository
does not automatically imply:
Deploy production
and:
Inspect database schema
does not automatically imply:
Modify production data
Tool capability should never be confused with appropriate permission.
AI Can Increase the Value of Strong Engineers
There is another side of this discussion that should not be ignored.
AI does not only help beginners.
A strong engineer can use AI as a multiplier.
Why?
Because the engineer already has the ability to:
- specify the problem precisely;
- recognize incorrect assumptions;
- review generated code quickly;
- reject poor architecture;
- test adversarial cases;
- ask better questions;
- integrate the result into a larger system.
The AI can therefore remove lower-value mechanical work while the engineer remains responsible for higher-value decisions.
This is one reason I do not see AI as an argument against learning fundamentals.
I see the opposite.
The better your fundamentals are, the more safely and effectively you can use increasingly powerful tools.
The Skill Moves Upward
As tools improve, the value distribution changes.
At one time, manually writing assembly code was a large part of programming.
Higher-level languages automated much of that work.
Compilers became better.
Frameworks automated recurring application structures.
Cloud platforms automated infrastructure primitives.
None of these changes eliminated the need for engineering.
They moved the abstraction boundary.
AI may do the same thing to a much larger portion of implementation work.
The consequence may be that more value moves toward:
- specification;
- architecture;
- integration;
- validation;
- security;
- systems thinking;
- domain knowledge;
- technical judgment.
That does not guarantee that every current job survives unchanged.
It means that learning only the easiest mechanical layer of development is an increasingly weak career strategy.
Do Not Become an AI Operator Who Cannot Engineer
There is a new failure mode that I believe students should take seriously.
A person can become highly skilled at:
- prompting;
- selecting models;
- running agents;
- copying generated patches;
- iterating until tests pass
while remaining unable to independently explain the system being produced.
That can create an illusion of rapid progress. The repository becomes larger. Features appear. Tests become green.
But the person’s internal technical model remains shallow.
Eventually something happens outside the patterns the agent can resolve immediately.
At that point, the apparent productivity collapses.
Your goal should be [Engineer using AI] not AI operator dependent on generated engineering.
The difference is ownership of understanding.
A Practical Rule for Learning
During the learning phase, I recommend dividing AI use into three categories.
Green — Usually Safe
AI can help you with:
- explaining terminology;
- generating additional examples;
- checking grammar;
- creating practice questions;
- comparing approaches after you have attempted the problem;
- explaining compiler errors;
- finding relevant documentation;
- producing boilerplate you already understand.
Yellow — Use Carefully
AI can help with:
- debugging;
- refactoring;
- test generation;
- architecture brainstorming;
- unfamiliar libraries;
- performance ideas.
But you should independently verify the result.
Red — Do Not Delegate Your Learning
Be very careful about asking AI to:
- solve every task before you try;
- design complete systems you do not understand;
- make security decisions for you;
- perform destructive operations without review;
- choose architecture only because the answer sounds convincing;
- write code that you cannot explain;
- replace your own investigation every time you become stuck.
The purpose of learning is not to produce the final file.
The purpose is to build the mind that can produce, understand, and repair the file.
What I Expect From You in This Task Library
Using AI while working through this Task Library is not automatically wrong.
But the purpose of the Task Library is to develop your own technical capability.
If you give every task to an agent and copy the result, you can technically complete hundreds of tasks while learning very little.
That defeats the entire purpose.
When you use AI, I want you to be able to answer:
- What did the model contribute?
- What did you contribute?
- What did you verify?
- What did you reject?
- What did you change?
- Why does the final implementation work?
- What would you do if the model were unavailable?
The final question is especially important.
If removing access to an AI tool completely removes your ability to continue working, you have created dependency rather than leverage.
The Goal Is Leverage Without Dependency
This is the balance I recommend:
Knowledge + Experience + Judgment + AI = Leverage
Not:
AI = Substitute for knowledge
AI should allow a capable engineer to explore more possibilities, automate repetitive work, access information faster, and reduce mechanical effort.
It should not remove the requirement to think.
Public Research: What the Evidence Currently Suggests
The current evidence is not consistent with either extreme claim:
AI does nothing useful.
or:
AI has already made software engineers obsolete.
Research currently shows a more complicated picture.
AI Can Substantially Accelerate Bounded Tasks
A controlled GitHub Copilot experiment reported a large speedup on a specific JavaScript HTTP-server implementation task.
This demonstrates that AI assistance can have very real productivity value.
AI Can Also Slow Experienced Engineers in Some Environments
METR’s early-2025 randomized study found experienced developers were slower with AI on the mature open-source repositories studied.
The same researchers later reported that newer tools probably improved productivity, but measurement became difficult because developers increasingly did not want to work without AI.
Benchmark Performance Can Overstate Production Usefulness
METR’s 2026 maintainer-review experiment found a substantial gap between automated SWE-bench success and whether maintainers would merge the resulting patches.
Agents Can Already Complete Some Substantial Long-Horizon Implementation Tasks
MirrorCode provides evidence that modern agents can autonomously perform some implementations estimated to require humans weeks.
This means we should expect capability to continue expanding.
Organizational Quality Still Matters
DORA’s research suggests AI behaves as an amplifier of the engineering environment around it.
Strong processes can capture more benefit.
Weak processes can produce more instability.
Developers Use AI Heavily but Do Not Blindly Trust It
The Stack Overflow 2025 survey shows widespread adoption together with substantial distrust of output accuracy and significant concern around AI-agent security and privacy.
These findings are not contradictory.
They describe a technology that is already extremely useful, improving rapidly, and still dependent on careful human integration.
Final Perspective
I do not recommend fearing AI. I also do not recommend worshipping it. Learn to use it.
Learn where it is strong. Learn where it is weak.
Learn how to verify it. Learn how to restrict it.
Learn how to measure whether it is actually helping you.
And most importantly:
build enough knowledge that you remain the engineer in the relationship.
The future of software engineering will almost certainly involve increasingly capable AI systems.
That makes deep understanding more valuable, not less.
The person who understands the system can use the tool.
The person who only understands the tool remains dependent on whatever the tool produces.
My recommendation is simple:
Use AI to increase the reach of your engineering ability.
Do not use AI to avoid developing engineering ability.
Public Research and References
The sources below are included because AI capability and AI-assisted development are changing rapidly. Results should always be interpreted in the context of the models, tools, tasks, and time period studied.
-
DORA — State of AI-assisted Software Development 2025
AI is described primarily as an amplifier of existing organizational strengths and weaknesses.
https://dora.dev/research/2025/dora-report/ -
DORA — Balancing AI Tensions: Moving from AI Adoption to Effective SDLC Use (2026)
Discusses the trade-off between faster generation and increased auditing and verification work.
https://dora.dev/insights/balancing-ai-tensions/ -
DORA — Impact of Generative AI in Software Development
Reports individual productivity and well-being benefits alongside software-delivery trade-offs.
https://dora.dev/ai/gen-ai-report/report/ -
METR — Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Randomized study in which experienced developers working on mature repositories took approximately 19% longer when AI tools were allowed.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ -
METR — We Are Changing Our Developer Productivity Experiment Design (2026)
Follow-up explaining why newer data suggests greater AI productivity benefits but cannot provide a clean estimate because of selection effects.
https://metr.org/blog/2026-02-24-uplift-update/ -
METR — Many SWE-bench-Passing PRs Would Not Be Merged into Main (2026)
Maintainer review showed a substantial gap between automated benchmark success and merge-quality code.
https://metr.org/notes/2026-03-10-many-swe-bench-passing-prs-would-not-be-merged-into-main/ -
Epoch AI / METR — MirrorCode: Evidence AI Can Already Do Some Weeks-Long Coding Tasks (2026)
Demonstrates that frontier agents can autonomously complete some substantial, checkable software reimplementation tasks.
https://epoch.ai/publications/mirrorcode-preliminary-results -
Stack Overflow — 2025 Developer Survey: AI
Reports widespread AI adoption alongside low trust, accuracy concerns, debugging friction, and security/privacy concerns.
https://survey.stackoverflow.co/2025/ai -
Peng, Kalliamvakou, Cihon, Demirer — The Impact of AI on Developer Productivity: Evidence from GitHub Copilot
Controlled experiment reporting a 55.8% completion-time improvement on a bounded JavaScript implementation task.
https://arxiv.org/abs/2302.06590 -
Liu et al. — Lost in the Middle: How Language Models Use Long Contexts
Research demonstrating that having a long context window does not guarantee equally reliable use of all information within it.
https://arxiv.org/abs/2307.03172 -
NIST — Secure Software Development, Security, and Operations Practices: The Role of AI in Software Development
Recommends human monitoring, validation, and scrutiny of AI-generated software content.
https://pages.nist.gov/nccoe-devsecops/introduction.html -
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
Provides a risk-management framework covering security, privacy, reliability, intellectual property, and other generative-AI risks.
https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence -
European Commission — General-Purpose AI Obligations Under the AI Act
Describes GPAI-provider obligations including copyright policies and publication of training-content summaries.
https://digital-strategy.ec.europa.eu/en/factpages/general-purpose-ai-obligations-under-ai-act -
U.S. Copyright Office — Artificial Intelligence Study
Public work covering AI-generated outputs, copyrightability, digital replicas, and generative-AI training.
https://www.copyright.gov/policy/artificial-intelligence/