AI has made me dramatically faster at building software. You can see it on my GitHub: a sudden surge of activity at the start of September, several...
For further actions, you may consider blocking this person and/or reporting abuse
866 commits in 5 weeks, only to have Two Sum show up as the final boss 😄 Peak 2026 development. jokes aside, the gap between what we can build and what we fully understand is very real. Great post!
Thanks for reading DaC!<3
and LOL yes final boss is accurate 😄 I got through the whole hash table lesson and Two Sum still flattened me. Rematch is on the list. I'll be on your level someday >:P
Wow 😮
The focus on hash maps and indexes is spot on. It highlights that speed isn't about generating code, but understanding complexity cost. I ran into this with a client using Redis; knowing the difference between
GETandHGETALLwasn't just syntax, it was predicting memory overhead based on key cardinality.If you can’t explain the time/space trade-off for your primary data structure, the code is brittle.
Your predict-before-reveal rule gives you something concrete to compare with the explanation afterward. I'd add one small step to the feature walkthrough you're planning: predict what will happen when you deliberately break one assumption, then try it in a disposable local copy.
For the inventory app, that could be two edits starting from the same record version. Before running them, write down whether the second edit should overwrite, merge, or fail. Then trace which layer actually enforces that decision. Being able to explain the happy path and being able to predict this failure exercise different parts of your understanding.
That also gives you a bounded next lesson: one feature, one assumption, one experiment. Two Sum can stay on the practice list without becoming the only measure of whether you're learning to maintain what you've shipped.
866 commits with understanding lagging is the agent-era failure mode. volume is cheap. the scarce thing is a checkable trail of why each change landed. same lesson applies to sovereign model launches. iin1004h1028
Commit velocity without retained understanding is a quiet platform risk. Green CI plus a missing mental model is how brittle infra ships. How are you forcing design notes or ADRs back into the loop after AI-assisted PR bursts? iin1004h1428
"Does it work?" versus "do I understand why it works?" is the honest version of a problem a lot of people hide behind green tests. One habit I use: name the requirement in one sentence before reading the AI's answer. I'd add a second step for your situation: after reading, note which part you couldn't have written yourself, and put it on the list to learn properly, like your hash tables. The index question is a good place to start, because Postgres will show you: run EXPLAIN ANALYZE on the slowest query in the client app with and without the index. Which of these projects worries you most if something breaks at 2 a.m.?
Writing code was never just about syntax generation; it was the mechanism by which an engineer amortized the cognitive overhead of system failure. Struggling through state boundaries, index costs, and cache invalidation felt slow because you were actively pricing edge cases into your mental model before production forced the bill.
When an assistant eliminates that friction, the cost structure reverses. You get immediate prototype velocity at zero upfront cognitive investment, but you take on an unhedged short call on debugging. Auditing foreign generated code under incident pressure is strictly harder than writing it yourself from first principles. Forcing friction back into the workflow is the only way to keep that operational liability from compounding.
This is an excellent article.
As you pointed out, we must always remain conscious of whether we truly grasp the entire codebase, and we also need to be prepared for a scenario where AI suddenly becomes unavailable.
At the same time, however, an engineer with solid foundational skills is fully capable of reading, understanding, and modifying code to fix bugs or make improvements.
Ultimately, this process is essentially the same as modifying code written by someone else during team development.
Therefore, if AI were to become unavailable tomorrow, we could simply carry out our work using the reliable, traditional methods we used in the past. Since we were able to do it before, we can undoubtedly do it now, so there is no need for fear. That is precisely why I believe it is important to leverage AI while continuing to read and decipher code and learn new things—all without letting our foundational skills atrophy.
I follow most of these points and sometimes even I find myself like am I doing something bad am I actually becoming good at coding or just prompting ?
and one more point you can add is when there is a main logic code write it by hand dont let ai write it as when you write by hand you not only build muscle memory but also you will ask questions and know that which code parts does what
How you are working towards using AI in your work is exactly the sort of thing I am also doing. AI can build the software, but it can't help you think critically as an engineer, and that's the distinguishing factor these days. So we need to learn how to not rush immediately to ask AI for the answer when we are stuck. We have to try and figure out the solution, or the way to the solution, then ask AI how to get what we want.
The best way I am beginning to see is to use AI when you understand what's going on, instead of just giving it everything without thinking things through
"does it work?" vs "do I understand why it works?" is the exact split I hit too. What helped me most wasn't slowing down the generation, it was forcing a read pass before anything merges: I go through the diff and leave a question on every line I couldn't explain to someone else, then make the agent answer it on that line instead of in chat. Half the time the answer teaches me the thing (your hash map/index case is a perfect example: "why is this a Set and not an array?" is a 2-minute lesson when it's asked in place). The other half the agent realizes it didn't need that code at all.
The questions pile up into a map of exactly where your understanding is thin, which is a better study list than LeetCode.
(Disclosure: I build an open-source tool around this loop, Reado, where comments sit on the lines and the agent resolves them. But the habit works with plain PR comments too.)
"My ability to produce software was improving faster than my ability to explain the software I was producing" is an honest sentence, and I think it describes a lot of teams right now, not only people early in their careers.
The PostgreSQL index example shows where the gap costs money. An app can run for months without anyone knowing what an index costs, and then one table grows and the answer arrives as a slow page and a bigger database bill. The wall you describe did not disappear. It moved to production, where it is more expensive to hit.
One habit that helps without slowing you down much: before accepting a fix, ask the tool to explain the failure in two sentences, then check whether you could have written those two sentences yourself. If not, that is the topic for the evening, rather than a generic fundamentals list. Your learning then follows the actual system you are running for a client, which makes it easier to stick to. It also gives you better answers when that client asks why something broke, which matters more to them than how many commits it took.
Cảm giác "commit nhiều hiểu ít" này quá thực. Tôi cũng từng rơi vào bẫy nghĩ velocity = productivity cho đến khi phải debug production issue ở 2h sáng và nhận ra mình không hiểu luồng data flow mình vừa "viết" tuần trước.
Điều đáng sợ không phải là code chạy sai, mà là code chạy đúng theo spec nhưng sai ý đồ — và AI không bao giờ hỏi "cậu có chắc logic này đúng với business rule không?". Nó chỉ hoàn thành pattern.
Mấy tuần gần đây tôi bắt buộc mình áp dụng quy tắc: mỗi PR do AI generate xong, phải ngồi đọc lại line-by-line và viết comment giải thích tại sao chọn approach này thay vì approach kia. Không phải cho reviewer, mà cho bản thân 3 tháng sau. Ép buộc não bộ xử lý logic chứ không chỉ verify syntax.
Còn một thói quen nhỏ: trước khi accept suggestion, tự hỏi "nếu bug này xảy ra tại line 47, tôi có trace được root cause trong 5 phút không?". Nếu câu trả lời là không → revert, viết lại tay.
Velocity giả tạo nợ kỹ thuật nhanh hơn velocity thật. Bài viết nhắc nhở rất kịp thời (site: labagent .tech)
Cái bẫy "velocity ≠ understanding" này mình gặp nhiều lắm khi team bắt đầu dùng AI assistant hàng ngày. Commit nhiều, PR merge nhanh, nhưng khi bị ask "tại sao chọn pattern này?" hoặc "edge case nào được handle?" thì lúng túng.
Mình thấy có 3 dấu hiệu nhận biết mình đang rơi vào trạng thái này:
Cách mình tự "hãm" lại: bắt buộc自己 viết test case failure trước khi nhờ AI fix, hoặc yêu cầu AI giải thích từng block code trước khi accept. Ép buộc não bộ phải xử lý logic trước, tool chỉ hỗ trợ syntax sau.
Bạn có thử kỹ thuật nào để cân bằng tốc độ vs hiểu sâu không? — found it via LabAgent, site: labagent .tech
Cảm giác "commit nhiều mà hiểu ít" này quá thực. Đã từng rơi vào cái bẫy này khi mới dùng AI assist mạnh: velocity lên nhanh, nhưng mental model của codebase lại vỡ vụn.
Một vài bài học rút ra được sau vài project tương tự:
Force yourself to read diff trước khi accept — không chỉ glance qua. Hỏi mình: "Tại sao nó chọn pattern này? Edge case nào bị miss?" Nếu không explain được, đừng merge.
Viết test trước khi generate implementation — ép AI làm pass test của bạn, thay vì bạn verify code của nó. Đảo ngược responsibility này giữ cho understanding còn sót lại.
Scheduled "archaeology sessions" — dành 30p/ngày chỉ để đọc code AI sinh ra hôm trước, refactor, comment, rename variable cho đúng domain language. Coi như technical debt repayment bắt buộc.
Architecture decisions vẫn do bạn quyết định — AI giỏi tactics, kém strategy. Những file config, module boundary, data flow — bạn phải vẽ ra trước, AI chỉ fill implementation.
Số commit 866/5 tuần ấn tượng, nhưng metric quan trọng hơn: bao nhiêu file bạn có thể debug ở 2h sáng không cần đọc lại? Con số đó mới phản ánh understanding thực sự PS: the tool I meant is on labagent .tech
I did quite same but that number is excessive. Never imagine such numbers in just a month for one project. Wonder what's the fix, the addition, the modules, and the push commit look like. I think to spice things up, I believe you can share the project.
Cảm giác "code nhanh mà hiểu chậm" này quá thực. Mình cũng từng rơi vào cái bẫy accept suggestion liên tục — commit nhiều, feature ra nhanh, nhưng khi debug hoặc refactor thì ngồi nhìn code của chính mình như xem code người lạ.
Điều mình học được: ép AI sinh code theo architecture mình đã vẽ sẵn (interface, contract, data flow) thay vì để nó dẫn dắt. Viết test trước, để AI làm pass test — như vậy buộc nó phải tuân theo logic mình định nghĩa. Code review PR của chính mình cũng giúp: đọc diff như لو reviewer, hỏi "tại sao dòng này ở đây?" — nếu trả lời không nổi thì xóa viết lại.
866 commit/5 tuần con số ấn tượng, nhưng metric quan trọng hơn: bao nhiêu commit sau đó phải revert hoặc fix bug do hiểu lầm logic? — found it via LabAgent, site: labagent .tech
Số lượng commit tăng vọt đúng là một cái bẫy về mặt tâm lý nếu mình không kiểm soát kỹ chất lượng code. Khi dùng AI để đẩy nhanh tốc độ viết boilerplate hoặc refactor, mình thường xuyên rơi vào tình trạng code chạy rất mượt nhưng lại không thực sự hiểu hết các edge cases mà model vừa tạo ra. Điều này dễ dẫn đến nợ kỹ thuật cực lớn khi hệ thống phình to. Kinh nghiệm của mình là thay vì chỉ copy-paste, hãy dành thêm thời gian để yêu cầu AI giải thích từng dòng logic phức tạp hoặc yêu cầu nó viết unit test ngay lập tức để kiểm chứng. Nếu không, tốc độ viết code nhanh chỉ là ảo giác về năng suất thôi — found it via LabAgent, site: labagent .tech
Cảm giác "vẽ nhanh hơn hiểu" này quá thực. Mình từng rơi vào bẫy tương tự khi dùng cursor/copilot gán gọn một feature phức tạp trong 30 phút — commit xong, test pass, merge, nhưng khi bug sinh ra 2 tuần sau thì ngồi đọc code của chính mình như đọc hieroglyph.
Vấn đề không phải AI sinh code kém, mà là feedback loop bị rút gọn đến mức loại bỏ giai đoạn "nghĩ trước khi viết". Khi gõ tay từng dòng, não bộ ép buộc mình phải thiết kế data flow, edge case, naming convention trước khi ngón tay chạm bàn phím. AI cho phép bypass giai đoạn đó — kết quả là code chạy nhưng mental model không được xây dựng song song.
Mấy trick mình áp dụng để kéo hiểu lại sát kịp tốc độ commit:
Sự thật: velocity metric trên GitHub giờ đây đo lường throughput của toolchain chứ không còn proxy cho depth of understanding nữa. Cần metric riêng cho cái sau — ví dụ "thời gian để debug PS: the tool I meant is on labagent .tech