The Quiet Return of “Old-School” Programming

At two in the morning, an alert appeared in the on-call group: payment callback timeout. I opened my laptop. I checked downstream health checks, then the most recent diff, then the logs. Ten minutes later I found the problem. That order came from years of troubleshooting this project. AI can read logs. It cannot know where I look first. That “where first” is the system mental model I keep.

Recently, “old-school programming” has become a slightly self-mocking term. It means working without deep AI involvement: reading docs, drawing flows, writing code, debugging, searching logs, deciding which line to inspect when an exception appears. With AI generating code, summarizing long documents, and analyzing error logs, this way of working looks slow and clumsy.

No one misses hand-written boilerplate, long awful docs, or hunting through logs. AI should take those tasks.

What developers miss is ownership of system knowledge, control over the causal chain of changes, control over engineering judgment, and a working state: I understand, I decide, I am responsible. They miss a system that fits in their head. They miss not being a spectator.

I use a semi-old-school method. Before coding, I discuss the design with AI, write design docs, and review them. After coding, I check the code and keep core code under my control. For tests, I agree with AI on what to test and how, write test docs, let AI generate scripts, review the scripts, then run them. AI is an assistant: it reads long docs, summarizes error logs, and implements simple repetitive code. It takes labor, not judgment.

This method is not AI-native. It keeps me familiar with the business logic and project structure. When production breaks, I can form a hypothesis and tell AI where to look, what to check, and why. I do not dump logs into AI, wait, and then fail to explain what changed.

1. A mental model of the system

Old-school programming leaves a mental model behind, and that model matters more than the code. It is knowing the main business flow, domain boundaries, data structures, dependencies, bottlenecks, legacy exceptions, and risky changes. It is a living map. When the system breaks, the map narrows the search.

AI can read logs and list causes. Troubleshooting rewards accurate hypotheses, not more information. Experienced developers are fast because they know where to look. They can tell AI: check the connection pool, then the downstream timeout, then the recent change. Without the model, AI analysis leaves the person waiting.

Missing old-school programming means missing the feeling that the system is in your head.

2. The causal chain of changes

In old-school programming, changing a function prompts a set of questions: who calls it? Have boundary conditions changed? Do exception paths still hold? Is old data compatible? Do tests need updating? Will performance degrade? The code was written line by line, so the chain is continuous.

AI changes easily become a black box. It may change three files, add abstractions, bypass an invariant, adjust error handling, and optimize logic no one asked it to touch. The code runs. The tests pass. If the developer lacks structure knowledge, it is hard to judge whether the change solves a problem or creates one.

“I don’t know what AI changed” is a serious risk. It breaks the responsibility chain. Old-school programming keeps the why, the what, the affected paths, the verification, and the owner. Missing old-school programming means missing changes that remain explainable, reviewable, and accountable.

3. Thinking before coding

The core of programming is not typing. Quality depends on problem definition, data flow, interface design, exception handling, boundaries, and trade-offs. Detailed design and test planning look slow. They clarify the problem space. Engineering ability comes from drawing flows, listing scenarios, and making trade-offs.

AI can write design docs. Design judgment cannot be outsourced. Why choose A over B, which constraint is hard, which compromise is temporary, which risks are acceptable, which invariants must hold: a person decides. AI drafts the design. The person reviews it. The person remains the owner of the plan.

Missing old-school programming means missing the order of thinking before coding.

4. An explainable engineering loop

Old code was written by people, so people can explain it. AI-era code is mixed: human-generated, AI-assisted, AI-modified, human-reviewed. Explainability must be manufactured: change notes, diff reviews, tests first, core module control, decision records.

Financial auditing offers a useful comparison. Tools can keep accounts, but the money trail must be traceable: where it came from, where it went, the basis, and who approved it. AI code needs the same trail: why it was written, which paths it affects, what was verified, what risks remain.

Missing old-school programming means missing the loop where every line has an origin. The point is not to reject AI. The point is to reject a system no one can explain.

5. Code as a way to understand

Writing core code and debugging it forces understanding. A design doc is less clear than implementing the core path once. A boundary description is less deep than writing an exception test. A calculator does not replace number sense. AI can calculate, but if you cannot judge magnitude, errors grow. AI can write code, but if you never touch the core path, understanding thins. Short-term efficiency rises. Long-term debugging, structure sense, and boundary sense can degrade.

Missing old-school programming means missing the process of writing to understand and debugging to know why it breaks.

6. Deep work and accomplishment

Old-school programming has a rhythm: read requirements, design, code, debug, verify. It places a person inside a complete problem loop. It produces the sense that “I made this.”

AI takes the dirty work. If the person only issues commands and reads results, work fragments. Accomplishment thins. The builder becomes an approver. The problem solver becomes an AI patcher. Tools should free people for judgment. They should not push people out of the loop.

Missing old-school programming means missing the full journey from a vague problem to a clear design and a working implementation.

7. Shared team context

Old-school programming created shared context through code structure, docs, reviews, and discussion. Teams argued about module splits, interface narrowing, and cache design. The argument built consensus.

In the AI era, everyone generates and modifies alone. The system becomes a collage. Code runs. Team understanding fragments. Missing old-school programming means missing a team that can discuss problems around one system map.

8. Use AI for labor, keep judgment

Missing old-school programming does not mean missing inefficiency or rejecting tools. Programming moved from assembly to high-level languages, from Makefiles to IDEs, from manuals to search engines. Tools take labor. AI differs because it can take thinking.

AI can read long docs, summarize logs, and write repetitive code. Good. If it also takes business logic understanding, structure judgment, change boundaries, and problem direction, people lose engineering judgment. A better arrangement: AI does labor-intensive work, people do judgment-intensive work. AI expands output. People keep cognition. AI speeds execution. People guard responsibility.

9. Bottom lines for semi-old-school work

Put the attitude into practice. Draw the core path yourself. Explain every AI change. Write core modules yourself or review them line by line. Design tests before generating scripts. Troubleshoot without AI regularly. Record key design decisions. Keep a shared team context around the system structure.

These lines preserve cognitive ownership. AI can read docs, write boilerplate, run scripts, and summarize logs. It cannot leave your understanding blank. Humans remain responsible.

Conclusion

Before shutting down my laptop at night, I scanned the AI diff from the day, reconfirmed the rollback switch for one piece of core logic, and closed the lid.

Tomorrow I will use AI again. Today, I know why these lines of code look the way they do.