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.
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
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.
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
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.?
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.