In the AI era, there are four skills that are becoming even more relevant: problem decomposition, precise technical communication, understanding core concepts, and a code review & debugging mindset.

But you know what's more important than knowing those skills matter?

Knowing how to practice them.

This article focuses on exactly that — no hype, no theory. Just practical guidance.

1. Problem Decomposition: From Vague to Concrete

Why is this hard?

We often receive vague requirements: "Build a notification feature," "Add a filter to this page," "Fix the performance issue." Without decomposition skills, we jump straight to a solution — and frequently head in the wrong direction.

How to practice it:

The "5 Whys" Exercise Every time there's a problem or a new requirement, ask "why" at least 5 times before starting to code. This forces you to get to the root of the problem, not just the surface.

Example:

• "Fix the slow login bug" → Why is it slow? → Database query has no index → Why no index? → The schema was never reviewed → Why? → There's no schema review process in the team.
• The solution isn't just "add an index," but also fixing the review process.

Daily Decomposition Practice Before starting any task, write out the steps on paper or in Notion first. Create at least 5-7 concrete steps. If you can't, it means you don't understand the problem well enough yet.

Rubber Duck Debugging Explain your problem to a "rubber duck" — it could be a friend, an AI, or even a wall. The act of verbalizing forces your brain to reorganize its understanding. Often the solution appears in the middle of the explanation.

Practice with System Design Questions Try answering questions like "How would you design a URL shortener?" or "How does a real-time notification system work?" Answer verbally or in writing — not by coding directly.

2. Precise Technical Communication

Why is this hard?

We often know something intuitively, but struggle to articulate it clearly. And in the AI era, clarity of communication = the quality of output you get.

How to practice it:

Write Good PR Descriptions Starting now, every pull request you make must have a description that answers: what was changed, why it was changed, what the impact is, and how to test it. This is the most underrated technical communication exercise.

Practice Prompt Engineering Consciously Every time you use AI (Copilot, ChatGPT, Claude), don't just type randomly. Try writing the prompt in a draft first, review it, refine it — then send it. Notice the difference in output between a vague prompt and a precise one.

Create Architecture Decision Records (ADRs) For every technical decision you make — no matter how small — try writing: what the context is, what options were considered, and why you chose this solution. This trains your ability to articulate technical reasoning.

Give (or Get) Substantive Code Reviews Don't just write "LGTM" in a review. Push yourself to write at least one comment that explains why one approach is better than another — with a clear reference to a concept or trade-off.

3. Understanding Core Concepts, Not Memorizing Syntax

Why is this hard?

We're used to Googling or asking AI for specific things. That's great. But there's a difference between knowing how to use something and knowing how it works. The latter is what AI can't substitute.

How to practice it:

Learn "One Layer Below" What You Use If you use React, learn how the Virtual DOM and reconciliation work. If you use Prisma, study the SQL queries it generates. If you use fetch, learn how HTTP works underneath it.

Build Mini Implementations from Scratch Try building a simplified version of a tool you frequently use: a mini router, a mini state manager, a mini promise. It doesn't have to be perfect — the goal is to understand the underlying mechanism.

Read the Source Code of Libraries You Use Pick one library you use often. Read its source code — not all of it, just the parts you use most. GitHub is available; there's no excuse not to.

Apply the Feynman Technique Try explaining a technical concept in language that a non-technical person can understand. If you can't explain it simply, it means you don't truly understand it yet.

4. Code Review & Debugging Mindset

Why is this hard?

Reading someone else's code (especially AI-generated code) requires a different mindset than writing code. You have to actively search for problems, not just passively read.

How to practice it:

Make Yourself a "Constructive Skeptic" Every time you review code — including your own — ask three questions: What could go wrong here? Are edge cases handled? If the volume is 100x, will this still work?

Debug Without Running Straight to AI Challenge yourself: before asking AI or Stack Overflow, try tracing the problem yourself for at least 15 minutes. Read the error message carefully. Check your assumptions. Add logs. Isolate the problem. That process is what builds debugging intuition.

Review Open Source Code Open a repository for an open source project you're interested in. Read the reported issues, then try to trace it in the code — where is the problem? You don't have to fix it, but the process of tracing builds your ability to read and understand unfamiliar code.

Personal Post-Mortems Every time you find or fix a bug, write a short note: what the bug was, why it happened, how you found it, and what could be done to prevent it in the future. This builds a mental model of common error patterns.

You Don't Have to Do Everything at Once

These four skills don't all need to be practiced simultaneously. Pick the one that feels weakest to you, focus on it for a month, then move on to the next.

Consistency matters more than a burst of intensity.

The programmers who survive in the AI era aren't the ones with the most memorized syntax — but the ones who are best at understanding, decomposing, communicating, and validating.

And all of that can be practiced.