Recently, while using Codex to assist with development, I did something that seemed ordinary.

I organized the development constraints, design habits, and engineering conventions I use most often into a Skill, allowing Codex to follow them automatically while executing tasks.

It began as a simple cleanup exercise.

Halfway through, I suddenly realized:

Perhaps the most important production activity in future software engineering will no longer be writing code, but extracting rules.

The industrial era produced products.

The software era produced code.

What will the AI era produce?

The Industrial Era Produced Products; the Software Era Produced Code

For the past several decades, software engineering has revolved around code.

Requirements analysis, architecture, development, testing, continuous integration—every stage eventually converged on one central artifact:

Code.

The most important capability of a strong engineer was therefore often framed as:

The ability to write better code.

AI agents are quietly changing this.

Today, when I hand a requirement to Codex, I rarely write much of the code myself.

More often, I am:

  • defining conventions,
  • supplying context,
  • designing constraints,
  • validating results, and
  • correcting behavior that has moved off course.

The code itself has become the final output rather than the central activity.

This raises an interesting question:

If an agent can generate the code, what are engineers actually producing?

The answer may be:

Rules.

The Value of a Strong Engineer Is Migrating

In the past, we evaluated engineers by looking at:

  • algorithmic ability,
  • coding skill,
  • technical depth, and
  • problem-solving ability.

In the agent era, other capabilities are becoming increasingly important:

  • how to describe a problem,
  • how to define boundaries,
  • how to design constraints,
  • how to build durable context, and
  • how to coordinate multiple agents.

In other words:

The old core competency was coding.

The future core competency may be governance.

A Skill Is Not a Prompt; It Is Engineered Experience

Many people understand a Skill as a prompt.

I increasingly believe they are different things.

A prompt is closer to one-time communication.

A Skill is a way to preserve organizational experience.

A senior frontend architect, for example, may carry rules like these for years:

  • how page directories should be organized,
  • how APIs should be wrapped,
  • how state management should be designed,
  • how tables should be implemented consistently,
  • how errors should be handled, and
  • how permissions should be controlled.

In the past, this experience could exist only in a person’s mind.

A new team member might need years to absorb it gradually.

Today, we are beginning to write such experience down as:

  • Skills,
  • SOPs,
  • Specs,
  • Rules, and
  • Workflows.

Once read by an agent, these materials can participate directly in production.

We are turning tacit experience into executable knowledge.

The Object of Architectural Governance Is Changing

Architects traditionally governed:

  • databases,
  • microservices,
  • caches,
  • message queues, and
  • Kubernetes clusters.

Their concern was:

How can the system keep running reliably?

Today, a new set of problems is emerging:

  • an agent misunderstands a requirement,
  • an agent changes more than its assigned scope,
  • an agent forgets context,
  • an agent introduces technical debt,
  • an agent reinvents an existing solution, or
  • an agent violates team conventions.

These are no longer purely traditional software problems.

They resemble organizational-management problems because agents now possess a degree of autonomy.

This introduces a new question:

How do we govern agents?

Future Software Teams May Be Hybrid Organizations of Humans and Agents

A development team today is usually composed of:

  • product managers,
  • architects,
  • frontend engineers,
  • backend engineers, and
  • testers.

In the future it may include:

  • product managers,
  • architects,
  • frontend engineers,
  • backend engineers,
  • test engineers, and
  • multiple specialized agents.

In some situations:

A five-person team working with agents may produce what once required a dozen people.

The decisive question will no longer be:

Can the agent write code?

It will be:

Can the agent produce correct results reliably?

That is fundamentally a governance problem.

Code Will Become a Byproduct

I increasingly believe that:

Future software assets will not consist only of code.

The artifacts of real value will gradually become:

  • Skills
  • Specs
  • Rules
  • Context
  • Memory
  • Quality Systems

Together, these form a team’s cognitive assets.

Code is the natural result produced when those cognitive assets are executed.

In the age of assembly lines, the core asset was not the product itself, but the production process.

Likewise, the most important asset in the AI era may no longer be the code repository.

It may be the team’s ability to reproduce its own experience and judgment continuously.

Conclusion

Many people believe AI will replace programmers.

I do not.

I prefer a different interpretation:

Programmers will not disappear.

But the content of their work will change.

In the past, we were primarily responsible for producing code.

In the future, we may spend more time:

  • defining rules,
  • designing constraints,
  • maintaining context,
  • validating results, and
  • governing agents.

Software engineering is not ending. It is entering a new stage.

The most important capability of a future architect may no longer be writing the most sophisticated code.

It may be enabling a hybrid organization of people and agents to produce high-quality results continuously and reliably.

That may become software engineering’s most profound new question in the AI era.