Last night, I let Codex run for seven hours.
When I woke up and looked at the result, it seemed to have worked: an old project that had not been touched for a long time had gone through a round of upgrades.
That hit me harder than I expected. We had done similar work before. Back then, it took roughly three engineers a full month. This kind of work is not like building a small demo or adding a new page. It deals with an old project that already carries history, dependencies, hidden constraints, and unspoken assumptions. You have to understand it again before you can move it forward.
This used to be the most expensive kind of engineering work.
New projects are easier. Everything can be rebuilt around the latest patterns. Old projects are different. They contain years, sometimes more than a decade, of choices, compromises, business logic, edge cases, code nobody dares to delete, and configuration nobody remembers creating. An old project is not just a pile of files. It is a system sedimented by time.
And because of that, old projects are often far more valuable than new ones.
The problem is that, before AI, the cost of maintaining old projects was too high for humans. Projects decay. Dependencies expire. Documentation drifts away from reality. People leave. Knowledge breaks. In the end, a project may still have value, but because nobody dares to touch it, and nobody can afford to touch it, it slowly turns into a technical fossil.
AI does not only make writing code faster. It also makes reviving code faster. Because we can refactor and optimize code more quickly, many projects that were once abandoned because their maintenance cost was too high now have a chance to be brought back to life.
If the context windows of tools like Codex keep expanding, perhaps to the 1M-token level, many things will become even harder to imagine. In the past, an engineer could only understand part of a system at a time. With enough context, AI may be able to read the code, logs, documentation, tests, and historical migrations together. An old project would no longer be just a "repository." It could become an asset that can be understood again, discussed again, and activated again.
So the skill shift for programmers in the AI era cannot be reduced to the question, "Do we still need to write code?" Of course we still need to write code. But writing code is no longer the whole center of the job.
That means we need to change our working skills. Here are my reflections after using AI on real projects over the past two years.
Skill 1: Parallel Execution
In the past, the core working mode of a programmer was basically single-threaded.
You opened an editor, read a piece of code, changed one bit of logic, ran a round of tests, and then moved on to the next problem. At most, you kept a few branches in your head, but the actual execution still happened one step at a time.
The AI era is different.
You can dispatch several things at once: one agent upgrades dependencies, one agent adds tests, one agent reads historical documentation, one agent investigates a production error, and one agent tries a migration plan. You are no longer only doing the work yourself. You begin to own the ability to orchestrate work.
But this is also where the threshold appears.
Parallel execution does not mean throwing tasks out randomly. It means knowing which tasks can be split apart and which cannot; which tasks depend on each other and which can run at the same time; which results can be automatically verified and which must be reviewed by a human.
Someone who does not know how to work in parallel will still use AI in a single-threaded way. They simply replace "I write the code" with "AI writes the code for me." That improves efficiency, but the ceiling is limited.
Someone who understands parallel work treats AI as a group of engineers who can work at the same time. Their most important actions are no longer typing code. They are dispatching, waiting, reviewing, merging, and dispatching again.
This is very similar to moving from engineer to tech lead. The difference is that part of the team you lead is made of AI.
Skill 2: Writing Goals
Many people describe collaboration with AI as "writing prompts." I think that phrase is too light.
The real key is not the prompt. It is the goal.
A prompt often describes what you want. A goal defines how AI knows it is done. It is not a sentence like "help me upgrade this project." It is an executable, verifiable, convergent task boundary.
A good goal should answer at least several questions:
- What should change in this task, and what should not change?
- What is the success criterion?
- Which checks can AI run by itself?
- Which files, interfaces, or behaviors must not be broken?
- When a failure happens, should AI keep trying or stop and report back?
- What should the final deliverable look like?
This is why the ability to write goals will become increasingly important.
The longer AI runs, the more it needs standards. Without standards, the longer AI runs, the further it may drift. With standards, AI can inspect itself, correct itself, and push a task from "started" to "ready for review."
In other words, one of the core skills of future programmers is the ability to let AI run for longer in a reasonable way.
That sounds a little counterintuitive. In the past, we always wanted programs to run faster and tasks to be shorter. Now the opposite is sometimes true. Some complex tasks require AI to explore, try, fail, repair, and verify over a long period of time. Your job is not to stare at it every second. Your job is to write a good enough goal so it can run for a long time, run steadily, and come back with results that can be reviewed.
With a good goal, one night can move an old project forward.
With a poor goal, seven hours may produce only a pile of noisy changes that look busy but cannot be merged.
Skill 3: Communication
In the AI era, communication is not a soft skill. It becomes a hard skill.
Part of that communication is with people.
Why are old projects hard? Often, the hard part is not the code. It is the context. The real requirement lives in the business team's words. The real constraint lives in an old colleague's memory. The real risk lives in operational habits. The real history may be buried in an incident report nobody has opened for years. If you cannot ask for, organize, and confirm this information, the input given to AI will be incomplete.
Incomplete input only produces incomplete output.
The other part of communication is with AI.
Communicating with AI is not about politeness, and it is not about saying "please help me." It is more like creating a workspace for a very diligent, very capable collaborator who does not carry project responsibility by default.
You need to explain the background, boundaries, verification methods, and failure strategy. You need to understand its intermediate results. You need to pull it back when it drifts. You need to turn vague human intent into structured goals that AI can keep executing.
In the past, weak communication might only mean slower requirement understanding. Now weak communication can directly become engineering risk, because AI can amplify one misunderstanding into hundreds of lines of code very quickly.
Skill 4: Self-Learning
The stronger AI becomes, the more programmers must keep learning fundamentals.
This is also the easiest point to misunderstand.
Many people think that if AI can write code, perhaps they no longer need to learn so many low-level details. I think the opposite is true. Once AI can write code, humans need even more ability to know what is correct, what is wrong, and what merely appears to run.
Because without understanding the fundamentals, you cannot review the result.
If you do not understand databases, you cannot see why a query may eventually drag down the system. If you do not understand concurrency, you cannot see why a fix introduces a race condition. If you do not understand networks, you cannot see why a timeout handler only hides the problem deeper. If you do not understand engineering structure, you cannot tell whether AI is improving the project or creating the next generation of debt. More practically, if you do not understand the terminology and basic concepts in a domain, it is hard to even describe the problem clearly to AI, and AI will struggle to understand you accurately. AI is not omnipotent. Sometimes it gets stuck in a wrong path, and a human still needs to point out the problem and bring the direction back.
AI can suppress a person's desire to learn. It is too convenient. Convenient enough that it becomes easy to skip understanding and take the answer directly.
But the more convenient AI becomes, the more important it is to keep learning fundamentals. The most valuable people in the AI era are not those who memorize the most APIs. They are the people who can judge the quality of AI's output.
Judgment comes from fundamentals.
Without fundamentals, you can only trust AI.
With fundamentals, you can use AI.
Old Projects Will Become a New Battlefield
When these four skills are put together, an interesting change appears: programmers in the AI era are not becoming lighter. They are becoming heavier.
What becomes lighter is repetitive manual work. What becomes heavier is your understanding of systems, your definition of goals, your judgment of risk, and your orchestration of multiple execution threads.
In the past, when a company wanted to upgrade an old project, the biggest concern was return on investment. Three people, one month, and in the end the project only moved from an old state to a slightly less old state. It was hard for a boss to approve that.
But if AI can compress that work into one night, the economics of old projects change.
Many things that used to be "worth doing but too expensive" will become worth doing again. Legacy system upgrades, test recovery, dependency migration, documentation restoration, architecture cleanup, performance investigation, and knowledge preservation were once the easiest things to postpone. They may gradually become the places where AI is most useful.
So I increasingly feel that without AI, human projects decay faster; with AI, many projects may be revived.
But the prerequisite is that the people using AI must upgrade too.
If programmers still define themselves only as "people who write code," they will compete with AI for the same task. That position will become more crowded.
If programmers upgrade themselves into people who define goals, orchestrate parallel work, communicate context, and review results, then AI is not a competitor. It is leverage.
Closing
In the AI era, the programmer's skill stack is shifting gears.
In the past, the most important question was: can I write the code?
The next, more important question is: can I break a complex objective into multiple executable goals, dispatch them to AI, allow them to run for a long time, and then review, merge, and turn the results into project assets?
These four skills will become increasingly important:
- Parallel execution: dispatching and reviewing multiple tasks at the same time.
- Writing goals: giving AI standards it can use to verify its own work.
- Communication: obtaining real context from people and building clear work boundaries with AI.
- Self-learning: continuing to learn fundamentals under the pressure of AI, so judgment does not disappear.
Programmers will not disappear because of AI.
But programmers will diverge.
One group will continue to see themselves as single-threaded code writers and compete with AI on speed. Another group will begin to see themselves as owners of complex systems and learn how to make AI run longer, run more steadily, and produce results that can actually be reviewed.
The latter group will be the programmers who truly become stronger in the AI era.