Abstraction: The core foundation for AI assisted coding and reskilling for AI

Reskilling for AI for nondevelopers will be a key challenge 2026 and beyond.

Here, we propose that AI reskilling for nondevelopers is a mix of soft skills and hard skills. But most importantly, its a mindset shift - calling for humans to draw upon higher order thinking i.e. the capability for abstraction - which we excel in(relative to AI)

I have been developing these ideas in my teaching at Oxford and also in our work at Erdos Research. Anjali Jain and Ayşe Mutlu are working with me to first implement this in #cursor and later in #antigravity.

Our overall goal is to empower non developers to take up AI assisted coding. This is a significant reskilling challenge and I believe will make a big impact 2026 and beyond.

I would also like to thank David Knott for his guidance and inspiration in this work.

When we learn to build software, we often start with details: syntax, functions, files, frameworks. This makes sense—after all, software is made of details. But as systems grow larger, something subtle happens: the details stop being the hard part. The hard part becomes deciding what the system should be.

This is where abstraction matters.

Abstraction means separating the behaviour and rules from the implementation detail.

More broadly, it means, focusing on what matters, and ignoring what doesn’t (for now). When you use abstraction, you describe what you want to happen without worrying about how it is done internally.

For example, when you drive a car, you use the steering wheel, pedals, and gear selector - you don’t think about fuel injection, engine timing, or brake hydraulics The car hides those details from you. That hiding is an abstraction.

Applying this idea to AI assisted coding, Instead of saying: “Here are the exact functions, files, and code…” You say: “The user can add a book” or “The book must have a title”

These statements are abstractions. They describe behavior and rules, not implementation. This matters now because AI can generate code very quickly. But if you don’t clearly say what should exist and what good looks like then:

• the AI will guess (sometimes wrongly)

• you’ll get extra features

• or the wrong behavior

Abstraction is not about avoiding complexity. It is about containing complexity so that thinking remains possible. When you abstract, you are not being vague; you are being precise about what matters right now and deliberately setting the rest aside.

Before AI-assisted coding, abstraction helped teams work together. Architects thought in systems, developers thought in code. Today, that boundary has shifted. Machines can generate code quickly, tirelessly, and at scale. What they cannot do is decide what should be built, what should not be built, and when a solution is good enough.

That responsibility now sits firmly with humans.

In this new world, abstraction is no longer optional. It is how you retain control.

Examples of abstraction include:

• A clear problem statement is an abstraction. A specification is an abstraction. A user story, an acceptance test, a design constraint—each is a way of saying: this matters more than everything else right now.

Without abstraction, AI feels magical but dangerous. With abstraction, AI becomes powerful but bounded.

There is a quiet inversion happening in engineering. Historically, senior engineers abstracted and junior engineers implemented. Increasingly, humans abstract and machines implement. This means that abstraction is no longer “management work” or “theory.” It is a core engineering skill—perhaps the most important one.

This is not a failure. It is a signal to step back, raise the level of abstraction, and think again. Good abstractions are not perfect on the first attempt. They are refined through use, feedback, and iteration—just like code.

In learning, abstraction gives you leverage. In practice, it gives you safety. In the age of AI, it gives you agency.

• Intent before implementation: If you haven’t decided what should exist, code will decide for you.

• Abstraction is control: Abstraction is not distance from the system; it is leverage over it.

• Specs are safety: A specification is a safety device, not documentation.

• AI changes where skill lives: When machines write code, humans must write meaning.

• Clarity test: If you can’t explain it without code, you don’t understand it yet.

• The real engineering shift: The hardest part of building systems is no longer writing code — it’s deciding what code should exist.

With AI assisted coding, Abstraction isn’t a luxury or an academic habit; it’s the mechanism by which complex systems become thinkable.

Abstraction is how humans stay in control of machines

When systems get large (AI systems especially), you can’t reason about:

• tokens

• files

• functions

• model calls

…all at once.

Abstraction gives you compression with meaning:

• Problem instead of requirements soup

• Spec instead of prompt sprawl

• Issue instead of “do some coding”

• Acceptance test instead of vibes

AI makes abstraction more—not less—important

Before AI: abstraction helped teams coordinate. After AI: abstraction helps humans retain intent. The machine can fill in details endlessly. Only humans can decide:

• what should exist

• what should not exist

• where to stop

There’s a quiet inversion happening. Historically: senior people abstracted, juniors implemented Now: humans abstract, machines implement. Which means abstraction is no longer “management work” — it’s core engineering skill.

This is not a conceptual exercise. We are currently exploring how to implement these ideas in #Cursor and #Antigravity.

If you want to study with me - please see my course on AI Engineering at the #universityofoxford. If you want to get free copies of my forthcoming books - please join my subsstack