For years, learning to program meant, to a large extent, learning to write code.

Syntax. Frameworks. APIs. Patterns. Libraries. Debugging.

Artificial intelligence is breaking that equivalence.

Today a good coding agent can produce in minutes an amount of software that once required hours or days of manual work. It can create an API, build a frontend, write tests, modify dozens of files, run commands, and fix errors without a person writing every line.

That has revived an uncomfortable question:

If AI can already write the code, what should a developer study?

A recent video, “El código está resuelto… ¿y ahora qué estudias? (mi posición real)”, proposes an answer worth taking seriously.

The central idea can be summarized like this:

Code generation is close to becoming a commodity for many common applications. Software development, by contrast, is far from solved.

That distinction completely changes where it makes sense to invest learning time.

Writing code is not the same as developing software

For a long time, the two activities were so tightly coupled that they looked like the same thing.

To build an application, someone had to write code manually. That is why a large part of a developer’s practical value was directly related to their ability to turn an idea into instructions a computer could execute.

AI is decoupling those two things.

Now we can have:

goal
→ specification
→ agent
→ code
→ tests
→ execution

The person no longer needs to participate in every microscopic transformation.

But that does not mean the complete problem has disappeared.

Someone still has to decide:

  • what should be built;
  • how to decompose the problem;
  • which architecture to use;
  • which constraints must be respected;
  • how to prove the system works;
  • which risks are acceptable;
  • when a solution is truly ready for production.

AI can write one function.

It can write thousands.

But a production system is not simply a collection of functions.

The compiler test

The video proposes a useful way to test the claim that “code is solved.”

Do not ask AI for another CRUD application.

Ask it for something like:

a compiler
an interpreter
an operating system
a runtime
a database engine
a low-level distributed system

The difference appears quickly.

Conventional web applications exist inside extremely well-known spaces. There are millions of examples, mature patterns, abundant frameworks, and enormous amounts of similar code in the data on which models were trained.

That makes much of implementation increasingly automatable.

But as technical depth, constraints, invariants, and the need to preserve coherence across thousands of decisions increase, the challenge stops being simply generating correct syntax.

The problem becomes engineering.

So perhaps the most useful statement is not “code is solved.”

It is closer to:

An increasing share of code writing is being automated.

And that forces us to move higher in the abstraction stack.

1. Planning: turning intent into executable work

The first skill that gains importance is surprisingly unglamorous: planning.

When writing code was expensive, many people could improvise directly in the editor.

Implementation cost naturally limited the size of each iteration.

With agents, the opposite happens.

An agent can produce a huge amount very quickly.

That means bad direction can also produce a huge amount of incorrect work very quickly.

Planning therefore stops being bureaucratic documentation and becomes an interface between intent and execution.

A modern flow can look like this:

large objective
→ constraints
→ initial architecture
→ milestones
→ issues
→ small tasks
→ acceptance criteria
→ agents execute

The more capable the agent, the more important it becomes to give it a sufficiently precise structure of work.

The valuable capability is no longer only “I know how to implement this.”

It is also:

I know how to turn an ambiguous problem into a sequence of decisions and tasks that can be executed and verified.

This skill connects directly with what we have previously described at Capital de Tokens as agentic engineering: the human moves from writing every file toward designing the system that produces the change.

2. Orchestration: programming teams of agents

The second area is agent orchestration.

It is not an entirely new idea.

For decades, companies have divided work among specialists:

product manager
→ architect
→ backend
→ frontend
→ reviewer
→ QA
→ operations

Agents let us represent part of that structure in software.

For example:

Specifier
→ defines requirements

Developer
→ implements

Reviewer
→ looks for defects

QA
→ validates behavior

The difference matters.

In the past, increasing project parallelism usually required hiring and coordinating more people.

Now part of that parallelism can come from specialized agents.

This introduces a new discipline: designing how agents collaborate.

There are several possible layers.

Orchestration between models

A system can choose different models depending on the task.

One may be better at planning, another at generating code, another at review, or at executing fast and inexpensive tasks.

Orchestration inside a harness

Modern agent harnesses can offer a main agent, subagents, tools, sessions, permissions, and different execution loops.

In our analysis of DeepSeek Harness we saw precisely this direction: the model stops being the whole product and becomes part of a larger infrastructure that manages tools, context, state, and execution.

Orchestration above multiple agents

There can also be control systems that assign complete tasks to different agents or harnesses and later collect their results.

At that point, the developer is no longer only programming an application.

They are programming a software organization.

3. Testing: when generation is cheap, verification becomes expensive

If there is one skill likely to increase in value with AI, it is testing.

There is a simple economic reason.

When generating code is expensive, writing more code is the bottleneck.

When generating code becomes cheap, the bottleneck changes:

How do we know all that code is correct?

An agent can modify twenty files in seconds.

It can run the program and claim it works.

But without an independent verification mechanism, we are still depending on trust.

That is especially dangerous because models can produce plausible solutions even when they are wrong.

That is why practices known for years gain a new strategic function:

  • unit tests;
  • integration tests;
  • end-to-end tests;
  • property-based testing;
  • TDD;
  • BDD;
  • contract validation;
  • regression tests.

Tests stop being only protection for code written by humans.

They become the objective boundary between the agent and reality.

We can imagine the loop like this:

agent implements
→ tests fail
→ agent fixes
→ tests pass
→ reviewer inspects
→ new tests try to break it
→ QA validates acceptance criteria

The more autonomous implementation becomes, the more we need independent mechanisms capable of saying no.

Adversarial review: agents trying to prove another agent wrong

The video also highlights a particularly interesting variation: adversarial review.

Instead of trusting a single agent:

agent A
→ writes code

we can build something like:

agent A
→ implements

agent B
→ tries to find defects

agent C
→ challenges assumptions and edge cases

automated suite
→ validates behavior

That consumes more tokens and compute.

But it introduces diversity into evaluation.

The logic is similar to a classic engineering practice: the person who implements a solution should not be the only source of evidence that it works.

AI makes it possible to automate much of that productive disagreement.

An interesting paradox appears:

The cheaper software becomes to generate, the more profitable it may become to spend resources trying to destroy it before deployment.

4. System design: choosing before implementing

The fourth skill is probably the hardest to automate completely: system design.

Not because an AI cannot generate architectures.

It can.

It can propose databases, queues, caches, APIs, load balancers, cloud services, workers, and complete pipelines.

The problem is that there is almost never one correct architecture.

There are trade-offs.

For example:

PostgreSQL or DynamoDB

monolith or microservices

queue or synchronous call

strong or eventual consistency

serverless or dedicated capacity

build or buy

The answer depends on context:

  • expected volume;
  • budget;
  • latency;
  • available team;
  • regulatory requirements;
  • fault tolerance;
  • operational complexity;
  • product time horizon.

An AI can produce a technically reasonable recommendation that is still a bad decision for a specific company.

That is where a form of human value appears that is difficult to reduce to syntax:

judgment.

The engineer must be able to evaluate not only whether something works, but whether it is the right solution under the real constraints.

Code knowledge still matters

None of this means we should stop learning programming.

There is an enormous difference between:

not manually writing all the code

and:

not understanding the code

A developer who does not understand programming will have enormous difficulty:

  • detecting a wrong abstraction;
  • evaluating complexity;
  • reading a stack trace;
  • distinguishing an elegant solution from a fragile one;
  • reviewing concurrency;
  • finding performance problems;
  • interpreting a large diff;
  • deciding whether an agent invented an API;
  • designing good tests.

Syntax may lose relative value.

Fundamentals do not.

In fact, AI can increase the return on understanding them because a technically strong person can direct a much larger amount of implementation.

Security and cloud move up a level too

The video mentions two additional areas that deserve attention: security and cloud computing.

Modern coding agents no longer merely suggest text.

They may have access to:

filesystem
shell
GitHub
cloud CLIs
databases
APIs
credentials
CI/CD systems

That makes security even more important.

A useful agent needs capabilities.

But every capability also increases the blast radius of an incorrect decision.

That is why concepts such as these become more important:

  • least privilege;
  • sandboxes;
  • approval gates;
  • isolation;
  • secret management;
  • auditing;
  • traceability;
  • execution policies.

The question is no longer only whether the agent knows how to program.

It is also what we allow it to do.

The new bottleneck: deciding, coordinating, and verifying

We can summarize the transition this way:

BEFORE

idea
→ human designs
→ human writes code
→ human tests
→ human fixes

NOW

idea
→ human defines objective and constraints
→ agents plan / implement
→ tools verify
→ other agents review
→ human decides and remains accountable for outcome

Code does not disappear.

It progressively becomes a more automated layer of the process.

And when one layer is automated, value moves toward the problems around it.

That is why four areas stand out in particular:

PLANNING
knowing how to decompose the problem correctly

ORCHESTRATION
knowing how to coordinate agents, models, and tools

TESTING
knowing how to prove the result works

SYSTEM DESIGN
knowing how to choose the right architecture and trade-offs

They are not new skills.

What is new is their relative weight.

From programmers to designers of software factories

Perhaps the best way to understand the change is this:

We used to design software.

Now we are also starting to design systems that design and produce software.

An agentic software factory can contain:

specifications
+ specialized agents
+ harnesses
+ tools
+ tests
+ reviewers
+ policies
+ memory
+ CI/CD
+ observability

The engineer’s intellectual product stops being only the final code.

It is also the machinery that can produce correct code repeatedly.

That connects two trends we have followed closely at Capital de Tokens: the rise of agentic engineering and the emergence of the agent harness as a new foundational layer of the development stack.

So what should you study today?

If someone is starting a software career, the answer probably is not to abandon programming because an AI can write Python or TypeScript.

The answer may be the exact opposite: use cheaper implementation to move faster toward higher-level problems.

Learn code.

But also learn to:

model problems
→ design systems
→ decompose work
→ write specifications
→ create strong tests
→ evaluate trade-offs
→ review results
→ operate infrastructure
→ secure systems
→ coordinate agents

Because even if we reach a world where generating a conventional application is almost instantaneous, a much harder question remains:

Who knows which application we should build, how it should behave, and how we prove we can trust it?

That is where engineering still lives.