Enduring Skills

Every technology shift revalues skills. Compilers commoditized assembly fluency; spreadsheets commoditized manual bookkeeping arithmetic; and in each case the thinking layer above the commoditized layer became more valuable, not less. LLMs are running the same play on computational work — at unusual speed and unusual breadth. This page takes an explicit position on which CT skills appreciate, which commoditize, and what that means for how you spend your learning hours.

The sorting principle

One rule explains almost every entry below:

A skill commoditizes when machines can perform it and its output can be cheaply verified. A skill appreciates when it is needed to specify work, verify work, or carry responsibility for work. Production moved; judgment did not.

This is the generation–verification asymmetry from Verification Thinking turned into a career filter. Note the second clause: tasks machines do un-checkably do not commoditize cleanly — they become hazards until verification catches up.

What is being commoditized

Commoditized does not mean worthless — it means the market price of performing it trends toward the price of tokens. These were genuinely scarce skills for decades:

Syntax fluency and boilerplate production. Knowing the incantations — language grammar, framework wiring, config formats, CRUD scaffolding. The model types faster than you and knows more idioms.
Routine translation between representations. Spec to standard code, SQL to ORM calls, JSON to classes, one language to another, docs to summary. Pattern-dense, verifiable: ideal model territory.
Recall of standard algorithms and API surfaces. The interview-question layer — implementing known solutions to known problems, remembering signatures. Retrieval-shaped knowledge loses to systems built on retrieval.
First-draft production in general — code, prose, tests, diagrams, plans. The blank page is dead. Drafting was never the bottleneck people believed; deciding what the draft should say was.

An honest corollary from the ACM’s recent commoditization argument: even parts of mechanical decomposition and pattern application — the middle of the classical CT loop — are increasingly done competently by models. What the machine cannot do is covered next.

What matters more than before

Problem formulation. The entire value chain now starts from a human articulating what is wanted, precisely enough to delegate. Ambiguity used to be caught by the slow humans implementing; now it is baked into artifacts at machine speed. The best formulator in the room quietly sets the ceiling for everyone’s output. See Problem Formulation.

Evaluation and debugging — now of others’ work. The neglected fifth pillar becomes the daily main event: reviewing, testing, and diagnosing artifacts you did not write, produced by a collaborator whose failure modes are fluent and confident. Hypothesis-driven debugging skills transfer intact; the suspect list now includes “the model guessed.”

Abstraction and architecture. Models generate components far better than they hold systems. Choosing boundaries, interfaces, and layers — and knowing what lives beneath the abstractions when they leak — remains stubbornly human, and every delegated component increases the premium on the person who keeps the whole coherent.

Model thinking. A new entrant: an accurate mental model of the stochastic component now embedded in every workflow (Model Thinking). Those without it oscillate between credulity and dismissal; those with it design around known failure modes.

Judgment under responsibility. Deciding what should be built, weighing stakeholders, owning consequences, saying no. Accountability cannot be delegated to a system that cannot be fired, sued, or ashamed — so it concentrates on whoever signs.

Domain depth. Verification requires ground truth, and ground truth lives in domains. The clinician, accountant, or distributed-systems veteran who can check model output in their field holds the scarce complement to every generative tool.

The uncomfortable middle: skill-building work

Here is the tension the tidy two-list version hides: many commoditized activities were also the training regimen for the appreciating ones. You learn to smell wrong code by writing wrong code; you develop architectural taste through years of boilerplate consequences. Delegate 100% of the reps and the next generation of verifiers never develops the nose — the apprenticeship gap discussed in Human–AI Division of Labor.

The resolution is to treat some generation work explicitly as exercise, the way runners still run despite cars existing. Educators face the sharpest version of this: curricula built around producing what models now produce must shift toward specifying, critiquing, and verifying — without dropping the hands-on reps that make critique possible. Research on CT education in the LLM era converges on the same reframe: prompting, evaluating, and iterating are CT practice when taught deliberately, and mere output-collection when not.

Placing your bets

Practical guidance, by role:

Developers: shift learning hours from framework breadth toward systems, testing/verification craft, and one domain worth being the ground truth in. Keep writing some code by hand, on purpose.
Educators: grade the specification and the critique, not just the artifact; make students find the planted flaw in model output; teach model thinking explicitly alongside the classical pillars.
Team leads: hire and reward for formulation and review quality — the artifacts are increasingly the cheap part. Protect apprenticeship reps in the workflow.

The through-line of this entire section, one last time: the pillars Wing named in 2006 were never about producing code — they were about thinking such that an information-processing agent could execute. The agents got shockingly better. The thinking is now the job.

References

Model Thinking