1024 Programmer’s Day: Why We Still Need Programmers in the AI Era

October 24 is Programmer’s Day. 2 to the 10th power, a cornerstone of the binary world.

But this year’s holiday mood is a bit awkward: AI is already quite skilled at writing code. So people ask: is this holiday still for programmers?

Conclusion first: yes, and more than ever. What AI truly replaces is never the identity of “programmer”, but the parts of a programmer’s schedule that aren’t worth remembering. When the threshold for “writing” is flattened, the threshold for “thinking clearly” is raised. That is worth unpacking on 1024.

The automatic transmission metaphor: control was never in the gearshift

The current state of AI programming is that output is getting faster and larger. It is like an automatic transmission in a car: it takes over repetitive operations like pressing the clutch and shifting gears; but where to go, which route to take, and whether to brake at this intersection are still in the driver’s hands.

Automatic transmission did not replace drivers; it just gave drivers their attention back to the road.

This metaphor is often read as “comfort”, but it is closer to a factual description. After automatic transmission became common, drivers did not become fewer; there were more of them, because driving became easier and more people were willing to get on the road. At the same time, accident responsibility still falls 100% on the person holding the wheel: no one is excused because “the car shifted gears by itself.”

The same is true of AI programming. It downgrades “I haven’t learned this language” from a wall to a speed bump; it compresses a prototype from three weeks to three days. But it also means a person can merge code into the main branch without understanding every detail of it, which exactly enlarges the blast radius of a bad judgment call.

So don’t rush to calculate “what percentage of programmers AI can replace.” The more useful question is: which part has AI taken over, and which part have humans been pushed to?

History has answered this several times. When calculators appeared, people said accountants would disappear; instead there were more accountants, because when the cost of bookkeeping fell, more people were willing to do accounts. When compilers appeared, people said assembly engineers would disappear; instead the software industry expanded tenfold. Every tool leap cuts the “barrier to execution” and raises the “value of intent.” The only difference is that this time, the skills being cut happen to be the identity labels many people rely on for a living.

The bottleneck has moved from the keyboard to judgment

This isn’t just a metaphor. Research by Harvard University and Jellyfish shows that after AI involvement, code output rose noticeably, but the number of delivered software releases did not grow at the same pace.

In plain terms: code gets written faster, but deciding “what to write” and judging “whether what was written is correct” has become more expensive.

There is a plain explanation for this gap: software delivery has never been a “write code” assembly line; it is a long chain of “understand the problem → design the solution → implement → verify → launch → operate.” AI speeds up the middle link, while the links on both ends stay motionless. So the whole chain’s pace is set by the slowest link, and that link is now judgment.

It can be broken into three concrete things AI cannot take over:

Requirements translation. When a business side says “we want a smarter report,” three completely different systems could be behind it. Translating a vague pain point into executable constraints depends on understanding people, not understanding syntax.

System design. AI is very good at writing code correctly within a given structure, but not good at deciding whether the structure should exist at all. A wrong split brings half a year of technical debt, and AI won’t lose sleep over it.

Risk identification. Will this code deadlock under tens of millions of concurrent requests? Will this permission check fail under boundary conditions? AI can give answers that look correct, but “looks correct” is exactly the most dangerous state.

The bottleneck has shifted from the keyboard to judgment: requirements translation, system design, and risk identification, the parts AI cannot take over, are becoming scarce new capabilities.

There is another easily overlooked detail: when output gets faster, verification workload rises with it. In the past, writing a thousand lines over ten days gave you ten days to get familiar with them; now generating a thousand lines in a day leaves you only one day to understand them. The “reading load” of code has not fallen with generation speed; it has been compressed into a shorter time window. That is why many teams using AI feel “more tired” first, not “relaxed”: what is saved is typing time, what is added is review time, and the latter consumes more mental energy than the former.

What leading teams do: let AI produce, let humans vet

Interestingly, the teams that use AI most deeply are strikingly consistent in their approach: let AI produce, let humans vet.

Concretely, three things:

First, the focus of code review has changed. In the past, review looked at syntax, style, and whether a null pointer was missed; now AI can get past those on its own, and review’s gaze moves up to three questions: what does this code intend to do (intent), under what conditions will it fail (boundary), and how much damage will it cause if it fails (risk). From “hunting for errors line by line” to “signing off on the whole,” review has changed from manual labor to judgment work.

Second, testing remains the bottom line. The faster AI generates code, the more valuable verifiability becomes. Testing is not a coverage number to show leadership; it is the only way a human reaches into the black box to confirm “it really does what I said.” AI-written tests and AI-written code mirror each other, so they can easily fail together; verification of critical paths still has to be designed by humans.

Third, treat AI output as a draft, not an answer. A draft means: by default it needs to be changed. This mindset makes a big difference: people who treat AI as an answer stop thinking the moment the first run passes; people who treat AI as a draft keep asking “why did it pass” after it passes.

AI covers the page with drafts; humans sign off on it. Signing off hasn’t gotten cheaper; it has gotten more expensive, because there is more to sign, and every page has to actually be read.

Can judgment be trained?

If judgment is the new scarce resource, it shouldn’t be treated as “talent” and put on a pedestal. It can be deliberately practiced:

• Ask “why” one more time. After AI gives a solution, force yourself to restate why it was written that way. The part you can’t restate is exactly the part you didn’t understand.

• Write tests first, then let AI write the implementation. Define “what correct means” on the human side, hand “how to implement it” to the machine; that is the cheapest way to keep control.

• Keep handwritten moments. Write the first version of core algorithms yourself, even if slow. Handwriting is how intuition gets built, and intuition is the raw material of judgment.

• Reading other people’s postmortems is more useful than reading their best practices. Judgment mostly grows from “this is how it breaks,” not from “this is what works best.”

None of these four can be done by “generating more code.” Each one requires a person to sit down and think quietly for a while.

Our own practice: give the saved time back to “thinking clearly”

We have our own practice on this road. In the Codigger cloud workstation, AI and developers share the same workbench: the environment is ready as soon as you turn it on, AI produces drafts, and humans make decisions and do the vetting.

“Environment ready on startup” sounds like an engineering detail, but it points directly at the judgment problem above. The most fragmented, least remembered, least fulfilling time in a developer’s day is largely spent on configuring environments, matching versions, fixing dependencies, and explaining “it works on my machine.” This time isn’t wasted on hard problems; it’s wasted on the threshold in front of hard problems.

Our goal is not to have AI finish everything for people, but to save the time spent on “setting up environments and nitpicking syntax” and give it back to “thinking the problem through clearly.”

This statement also works in reverse: if the saved time is used to generate even more code nobody reads, AI has only made waste faster. The value of a tool is not how many lines it produces, but where it moves human attention.

Back to 1024: 0s and 1s are written by people, and so is the world

The reason 1024 was chosen is that it is a cornerstone of the binary world. But binary itself doesn’t think; it only executes faithfully.

The foundation of the binary world is 0s and 1s, but it has always been humans who turn 0s and 1s into the world.

Judgment grows in people, and the holiday is a people’s holiday. This is not a self-comforting slogan. When an industry’s core capability shifts from “proficiency” to “judgment,” its demands on people don’t decrease; they increase: you need to know more to judge whether AI is right; you need to think more to see what it didn’t think of. AI makes “knowing how to write code” cheap, and at the same time makes “knowing what code to write” expensive.

So the holiday is not only still for programmers; its meaning is quietly changing. It no longer just commemorates a group of people who can type; it commemorates a group of people who are still willing to take responsibility for outcomes.

Happy 1024 Programmer’s Day. What was your first line of code? Hand over your factory settings in the comments.