# 5 Coding Habits That Improved My Problem Solving in 2026 (In the AI Era) > Source: > Published: 2026-09-21 02:23:27+00:00 AI can write code faster than ever. But there's a problem. **Writing code and solving problems are not the same skill.** In 2026, tools like AI coding assistants can generate functions, explain errors, suggest optimizations, and even help us build entire features. That's incredibly useful. But it also creates a new challenge for developers: If AI can write the code, how do we make sure we still know how to think? Over time, I started focusing less on writing more code and more on improving the way I approach problems. Here are 5 coding habits that helped me. Earlier, my first instinct after seeing a coding problem was: ``` Read problem → Start coding → Get stuck → Search for solution ``` Now I try to slow down. Before writing code, I ask: For example, if the problem asks for the number of subarrays whose sum equals `k`, I don't immediately search for a solution. I first think: ``` What defines a subarray? How can I calculate its sum? Can the same work be reused? What makes O(n²) too slow? ``` This small habit makes a huge difference. **Don't code until you can explain the problem in your own words.** "Optimal solution" sounds attractive. But jumping directly to it can make it difficult to understand *why* the optimization works. Now I usually follow: ``` Brute Force ↓ Find the bottleneck ↓ Understand why it's slow ↓ Optimize ``` For example: Suppose we need to find subarrays with sum `k`. A brute-force approach might be: ``` for (int i = 0; i < n; i++) { int sum = 0; for (int j = i; j < n; j++) { sum += nums[j]; if (sum == k) { count++; } } } ``` This is `O(n²)`. Instead of memorizing that "Prefix Sum + HashMap" is the answer, I ask: **What information am I repeatedly calculating?** That question leads naturally toward prefix sums. The optimization becomes something I understand instead of something I memorized. This is probably the biggest change. It's very easy to say: "Solve this problem in Java." And copy the answer. The code may work. But I may learn almost nothing. Instead, I started asking AI questions like: ``` Give me a hint, but don't give me the solution. What pattern should I look for? Why is my O(n²) approach inefficient? Can you review my approach without rewriting the code? Give me a counterexample for my solution. Explain why this edge case breaks my logic. ``` This changes the role of AI. Instead of: ``` Me → Problem AI → Solution Me → Copy ``` I prefer: ``` Me → Problem Me → Attempt AI → Hint / Feedback Me → Improve AI → Review ``` AI becomes more like a **rubber duck, mentor, debugger, and code reviewer**. The goal isn't to avoid AI. The goal is to avoid outsourcing the thinking. When a solution looks complicated, I don't immediately run it. I take a small example and manually execute the algorithm. ``` nums = [2, -1, 1, 2] k = 2 ``` For a prefix-sum approach, I might create a table: ``` Index Value Prefix Sum Needed Prefix ------------------------------------------------ -1 - 0 - 0 2 2 0 1 -1 1 -1 2 1 2 0 3 2 4 2 ``` Suddenly the logic becomes much easier to see. Dry runs help me catch: And the best part? **You don't need a compiler to do a dry run.** One of the best tests of understanding is: Can I explain this solution to another developer without looking at the code? For every problem I solve, I try to explain: ``` 1. What is the problem? 2. What is the brute-force approach? 3. Why is it slow? 4. What observation helps us optimize it? 5. What data structure/pattern are we using? 6. Why does the algorithm work? 7. What is the time complexity? 8. What is the space complexity? ``` Instead of saying: "Use two pointers." I try to explain **why** two pointers work. "Use a HashMap." I ask: "What information does the HashMap allow us to remember so we don't repeat work?" That difference is important. I don't think these habits magically made me a better programmer. What changed was the way I approached problems. Previously: ``` Problem → Code ``` Now: ``` Problem ↓ Understand ↓ Constraints ↓ Brute Force ↓ Find Bottleneck ↓ Observation ↓ Pattern / Data Structure ↓ Optimize ↓ Dry Run ↓ Code ↓ Test ``` And AI fits into this process without replacing it. I don't think AI makes problem-solving skills useless. If anything, it makes **understanding** more important. When code generation becomes easier, developers need to become better at: Generating 100 lines of code is easy. Knowing whether those 100 lines should exist is harder. The rule I'm trying to follow is simple: **Use AI to make your thinking faster, not to stop thinking.** I don't want to compete with AI at typing code. I want to become better at the parts of development that require understanding the problem, making decisions, and validating the solution. Because tools will continue to change. The ability to **think through a problem** will continue to matter. If you're learning to code in the AI era, don't try to avoid AI. Use it. But before asking: "Can you solve this?" Try asking: **"Can you help me think through this?"** That small change in how you use AI can completely change how much you learn from it.