šLearning How to Learn, again, with AI
- Published on
- ⢠5 min read
- Authors
- Name
- Kien
The experience of using AI to learn made the next step feel obvious. If I want to keep growing, I need to go deeper into backend fundamentals and scalable system design. It increasingly feels like frontend alone is no longer enough. The direction I see engineering heading is toward more complete, full-stack thinking.
Which brings me to chapter one of the systems design book.
Chapter one introduced a simple but important idea: understanding scalability and load. I am trying to develop a lens for how real systems behave as they grow.
Lately, Iāve been thinking just as much about how I learn as what I learn. Discovering the Pomodoro technique helped me be more intentional with focus and energy. It reminded me of a course I took years ago called Learning How to Learn, back when I was still figuring out how to become a programmer in the first place.
However, now that times are changing quite rapidly, especially with the rise of AI technology, this has made me reflect back on how we can leverage AI to learn faster.
Instead of passively reading, my workflow has become much more interactive. I upload books into NotebookLM, then generate mind maps, quizzes, flashcards, and simplified explanations of dense concepts. AI becomes a way to pressure-test my understanding rather than replace it.
One unexpected benefit has been audio. NotebookLM generates podcast-style summaries that I can listen to while walking, cleaning, or doing something mindless. Learning stops being something I have to sit down for. It becomes something that fits into the background of my day.
What surprised me most was feeding my entire blog into NotebookLM.
It was able to infer patterns in how I think. Not just topics, but values. It reflected back a rough value map of how I approach work, learning, and growth. In some cases, it surfaced nuances about myself that I had never explicitly articulated.
If someone had asked me what my core values were, I would have struggled to answer because I never deeply thought about it. But seeing them distilled from years of writing felt unexpectedly clarifying. Even more useful was seeing potential blind spots and weaknesses highlighted in a neutral way.
That kind of reflection is powerful. Writing has always helped me think, but having a system that can synthesize my thoughts at scale adds another layer. It turns raw expression into something I can reason about.
I started this process with chapter one of Designing Data-Intensive Applications and System Design Interview. Rather than treating them as interview prep, Iām treating them as foundational texts. I even generated a personalized audio overview framed around myself as a frontend engineer deliberately expanding into systems thinking.
Listening to my own learning context summarized back to me made the motivation clearer. Iām not doing this to pass interviews. Iām doing it because I have an urge to keep learning and grow past my current abilities. In my about me page of my blog, I mentioned I wanted to be the best version of my self⦠and it wasn't just to impress potential recruiters, I truly meant it.
I had an interesting conversation with a friend recently about this shift of using AI. He talked about the importance of clearly connecting ideas, writing strong PRDs, defining test coverage upfront, and setting precise guardrails. Once that intent is clear enough, an AI agent can execute it with surprising precision.
At that point, your ability to code isn't leverage anymore, its your ability to reason about systems and designing something that is robust.
Eventually, the implementation details are not your only limit. You are free to keep designing, refining, and shipping. Features move faster not because you type faster, but because your intent is unambiguous.
Iāve started thinking of this as value engineering.
In this model, it matters less how elegant your code is and more how clearly you understand the system. Architecture, constraints, failure modes, and tradeoffs become the real work. Prompting becomes execution. Planning becomes acceleration.
In the near future, I think strong developers will be able to build meaningful products without writing much code at all. But only if they deeply understand system design and data-intensive fundamentals. Without that foundation, you cannot set the right guardrails. You cannot trust the output.
Thatās why Iām reading these books now, to lock in fundamentals, to sharpen the mental models and to be almost self sufficient and preparing myself for a workflow where designing the system well is the work, and execution becomes almost instant.