Choose Your Abstraction Layer Deliberately
Delegate the work you don't enjoy to a higher abstraction; keep the parts that make you good and happy.
- Difficulty
- Easy
- Time to result
- ~weeks to results
- Steps
- 5
- Confidence
- 89%
Shani reframes AI as the latest in a long line of abstraction layers — C to Java to Python to AI — and argues there is no universal correct usage. The discipline is deciding, task by task, which layer you operate at: keep the work where you have irreplaceable judgment or genuine enjoyment, delegate everything else upward. She still writes C herself when code must run on a tiny CPU, because she does not trust a higher layer with that; she delegates elsewhere freely.
Origin
Inbal Shani, drawing on her own arc from writing C (and resenting Java for 'taking away my job') through Python to AI-assisted development, applied to how developers should adopt Copilot.
Core principles
- 01AI is an abstraction layer, not a different kind of thing — the same choice C-to-Java programmers faced
- 02There is no global wave of absolute truth that everyone has to follow
- 03Keep the tasks where your judgment is irreplaceable — Shani still hand-writes C for tight-CPU work
- 04Keep the tasks that make you happy, even if a tool could do them
- 05Delegate the tasks you dislike (writing tests, boilerplate) to the higher layer
How to run it
- 1
Inventory your work into three buckets
Split your tasks into: (a) work where you do not trust a higher abstraction to get it right, (b) work you genuinely enjoy, (c) everything else.
Pro tip Bucket (a) is a trust judgment, not a capability judgment. Shani's test is whether she would trust the tool with code that must run efficiently on a very small CPU.
- 2
Keep buckets (a) and (b) — deliberately, not by default
Protect the high-trust work AND the joy work. Enjoyment is a legitimate reason to keep writing a function yourself; it is what keeps you engaged and therefore effective.
Watch out Do not let the availability of a tool shame you into delegating the work that makes the job worth doing.
- 3
Delegate bucket (c) to the higher layer aggressively
Push the disliked and the routine up the abstraction stack. If you like writing functions but hate writing tests, generate the unit tests and let the AI do that job for you.
- 4
Move up the thinking stack with the time you reclaim
Use the freed time to think systems, architecture, and connected experience — the big picture. This is the skill that AI does not replace and that today separates senior from junior developers.
Pro tip Juniors gain the most here: with an assistant handling simple code, they can spend time from the get-go understanding the system, environment, and product instead of only learning syntax.
- 5
Re-run the split when the tools change
The layer boundary moves. Java took some tasks, Python took more, AI takes more again. Periodically re-inventory rather than freezing your bucket assignments.
In the wild
Despite running GitHub's AI product portfolio, Shani says there are things she will still write in C today — she does not trust delegating an efficient metric-inversion routine that has to run on a very small CPU. Other work she happily hands to a higher-abstraction tool.
→ A worked example of the split: trust-critical, resource-constrained work stays hand-written; the rest goes up the stack.
An engineer told Lenny he loved writing the simple functions Copilot now does for him and was sad it was doing them — but he did not turn it off. Shani's response: he doesn't have to use Copilot for his simple code; he can use it as a chat-based assistant to brainstorm instead, and keep the functions.
→ Reframes the guilt as a configuration choice — the tool has multiple surfaces, and there is no right and wrong way to use it.
Common mistakes
Assuming there is one correct way to use the tool
Teams ship AI tools with a scenario in mind, and users assume they must follow it. In practice everyone chooses their own flavor, and forcing a single usage pattern destroys the fit.
Delegating the work you're best at because the tool can do it
Handing over the trust-critical or joy-generating work hollows out both your competence and your motivation — the two things the abstraction cannot supply.
Reclaiming time without upgrading how you think
If the assistant writes the code and you don't move up to systems, architecture, and the connected experience, you have simply become a faster typist with no defensible skill.
Is it for you?
Best for
Individual engineers and technical ICs deciding how much of their craft to hand to AI assistants without losing their edge or their enjoyment
Not ideal for
Safety-critical or regulated domains (Shani names aerospace and self-driving) where the delegation boundary is set by regulation, not personal preference
From the transcript
“in see even today I don't trust someone inverting metrics for me in an efficient way if it needs to run on a very small…”
“you pick and choose how you want to use it there is no Global wave that is the absolute truth that everyone has to follow”
“job in a way that you're still keeping the things that make you happy on the other hand use AI to do the things that…”
“it's no longer just the actual code writing it's really evolving your thinking to the big picture to the connected experience to Connected systems”
From the episode
The future of AI in software development
Inbal Shani (CPO of GitHub)