How to Survive in the AI Era
Working like AI is the attitude I'm currently adopting. I'm sticking to 16 coding, 7 sleep, and 1 workout out of 24 hours.
The 16 hours of coding can involve actual coding, reading books, or researching articles—it's any activity related to computer science.
It seems many people are asking the question of how to survive in the AI era, and I've pondered it myself.
However, ultimately, nothing fundamental has changed in software development.
Just as no one said "the compiler developed it for me" when we successfully developed systems using compilers and had computers interpret them into machine code,
AI is ultimately just a tool. Fundamentally, AI-generated code is the source of truth, and problems will arise if you don't understand its structure.
With AI, a vast amount of code is generated, and since it's difficult for humans to read it all, we delegate interpretation, quality gates, code reviews, Lint, and more to AI.
So, my thinking is that all developers now need to work like a Tech Lead or CTO, and the object of management is AI.
Of course, using AI doesn't mean a lack of collaborative attitude in human relationships. While AI might reduce the number of people collaborating, within an organization,
we will still communicate and develop with people. If a new member joins a system built with AI, will they immediately understand that system?
And what considerations should we make to help them understand the system, and how can we onboard them? I wonder if even these questions could be quickly resolved by asking AI.
Is AI a Drug? #
AI is not a drug. Because drugs make you feel good and are incredibly sweet, but they have severe side effects, require self-effort to correct, and even that is difficult.
AI is slightly different. It's incredibly sweet, increases productivity, and grows uncontrollably, but you can even ask AI itself to control it.
In the past, when AI didn't exist, I think I had a low-level system FOMO about the intrinsic depth of systems.
For backend developers, understanding operating systems or computer systems is important, but as a service developer, knowing how CPU clocks work, how many cycles process what, and so on,
is good to know but not essential. Even without that, you can easily build a server system of a reasonably appropriate scale.
Currently, there are people who have a low-level FOMO for AI knowledge to understand AI systems, but I've observed a slightly different type of FOMO a few times.
It's a future-oriented FOMO, perhaps, about not understanding the structure after building a system with AI. Why not just build it first and not worry about that?
In systems where security, availability, and reliability are very important within a company, we should certainly consider it, but I don't think not adopting it at all just because reliability is crucial is the right approach.
Times change and the world progresses; isn't that itself the challenge?
What Strengths Should We Cultivate in the AI Era? #
Personally, I think it's acceleration. Hmm? You might think, "Isn't AI already providing acceleration?"
The basic strategy in the service market is to create a service, release it, get feedback, modify it, and release it again. This cycle
has become so easy with AI that the time constraint for releasing and modifying approaches zero (as long as it's not blocked by specific policies).
As an intuitive example, let's assume that 100 lines of code modification are needed for one round of feedback, and traditionally, one might write about 100 lines a day.
But the world has changed so that the basic stride can now be 10,000 or even 100,000 lines a day. So, if the basic stride is 10,000 lines, will you still work to quickly write only those 100 lines?
No. You should set your basic stride not at 100 lines, but at 10,000 lines, and proceed with more modifications and attempts. Even receiving communications and reaching out to many people
can now be entrusted to AI agents. Passing or dropping those opinions, and so on, can also be delegated to AI, while the developer's current capability lies in conducting the final review and setting the criteria for passing/dropping.
And building your own workflow and pipeline to construct such systems is the strength you need to cultivate now, which means it's an activity aimed at increasing acceleration.
How to Study in the AI Era #
Personally, I highly value reading books. I read at least 4-5 books a month, regardless of whether they are textbooks, humanities, or self-help books.
In the age of AI, I also think it's a good approach to ask the great LLM about a concept, then follow up with more questions to learn. This is like DFS learning.
However, there can sometimes be bottlenecks. For example, when transitioning from a backend developer to an AI engineer versus from an ML engineer to an AI engineer,
the foundational breadth and basic BASE will differ, and for the latter, LLM-based DFS learning will be easier. It's not impossible for backend developers, but,
And I think context switching, where you input questions instead of just reading, is a double-edged sword. The advantage is that you can develop good metacognition about what you don't know,
while the disadvantage is that it's a cost, and those who find it bothersome won't do it. In the former case I mentioned earlier, you might not even know what you don't know, so I recommend reading books.
Metacognition is important but also difficult. Therefore, when you don't know much, building foundational background knowledge is crucial, and I highly value reading books.
This is because books pose questions, explain concepts, and enable application. I highly value the fact that books themselves pose questions.
Simply reading a lot makes you feel a magical reinforcement at some point. And it's because you gain a new perspective to look at problems when starting new tasks.
Secondly, there's on-demand learning, which Andrej Karpathy emphasized: setting a goal to build a certain software, developing it, and then delving into and learning about the parts that block you.
This isn't to say this method alone is good, but it also ultimately converges to metacognition because you know what you don't know.
And the questions you encounter while developing will likely be questions needed in the market, and good for strengthening your capabilities.
Hmm, but this also has a cost: you have to develop, and AI is currently doing a good job of reducing that. However, humans are arrogant animals who adapt and then complain even more,
so there might be people who find even typing a single prompt to AI bothersome. But, well... I've mentioned three things below, and if I summarize them as ways to study:
- Reading books
- LLM DFS
- Project OnDemand
What increases as you move from Reading books -> LLM DFS -> Project OnDemand is the cost you incur to get questions, and consequently, the value of those questions also increases.
Here, value refers to the priority that I myself currently need most, rather than the value of the knowledge asset itself.
Therefore, in the AI era, it's important to study appropriately by carefully considering the cost you can spend for metacognition, the knowledge you can gain, and the environment you can immerse yourself in.
In Conclusion #
In conclusion, what developers need to cultivate hasn't changed. Only the basic stride has changed.
Domain knowledge will be highly valued, and those who research operating principles and core academic concepts will gain even greater advantages.
Anyway, we must continue to learn; things change too frequently. We need to have the flexibility to quickly gather and reflect those frequent changes.
How do we acquire that flexibility? Let's ask AI. Let's establish metacognition to recognize all questions and problems we have, and then ask AI to resolve that recognition.
As the times progress, we merely need to generate more questions.