A little while ago, I read Jongtaek from Toss's essay A Carpenter's Life. At a moment when so many people talk about AI, vibe coding, harness engineering, and graph engineering without looking at the actual code—and I cannot deny that I have been one of them—the essay meant a great deal to me.
I do not think a good developer is someone who only thinks in enormous abstractions. It is almost the opposite. You need to be able to climb high and then come back down. Even while talking about the whole picture, you should know which small promises hold that picture up. And while touching small pieces of code, you should not forget the whole they create.
(...)
Someone who can see lines and planes while looking at a point, then descend to the point again while looking at the lines and planes. Someone who accepts that every abstraction will eventually leak, and can therefore return below and get their hands dirty. I want to live that carpenter's life. However much the times change, I believe someone, somewhere, will still need a person who has thought deeply about nails and hammers.
For a while, I did not know what to do with the arrival of AI. At first I was amazed that it worked at all. Then, after spending tens of billions of tokens, I despaired about how I would make a living. Then I told myself there were still things people did better... To be honest, I still move between those feelings.
One thing did change for me: AI rekindled my passion for development. Now that everyone can use AI to build something, products are overflowing into the market, but genuinely good products remain scarce. Producing that quality takes more than telling AI to “do it.” People who understand the internal design and implementation well enough to steer it in the right direction will become more important and more valuable. That is why Jongtaek's description of “someone who can see lines and planes while looking at a point, then descend to the point again” feels so beautiful to me. I want to become that kind of person too.
Intoxicated by AI's convenience, I think I stopped paying much attention to the lines and points for a while. Lately I have been trying to restore the balance: keep up with the newest AI technology while looking more closely at the actual intent and implementation of the technology I use. AI helps with this process too—by sketching how a codebase is organized or explaining a part I cannot yet understand.
While roaming through official documentation, articles, and blogs, I found a blog by someone named Less. They seem to be attending Woowacourse. Between the name “Less” and the many architectural references, I suspect they studied or worked in architecture before learning development. Their thinking is deep and their writing is excellent. Every so often I notice a sentence that feels AI-written, so my cautious guess is that they use AI for a draft, then reread and revise it several times themselves. (That may simply be my guess because it is what I do.) Either way, it is impressive whether they use AI or not. I want to write that well too.
At first I tried asking AI to imitate my voice and write blog posts, but I disliked the results enough to take them all down. Maybe Korean is underrepresented in its training, but AI has a recognizable way of writing: chopping sentences too short, or producing a mechanical neatness and bluntness that I cannot quite name. More than anything, I think the presence of a story matters. Looking back, some of my older learning posts could easily pass for AI writing. A piece feels human when it reveals the question that made me dig into a technology, or the problem I actually defined and the way I solved it.
“I am fascinated by frontend development's ability to improve small inconveniences in everyday life.” It was the first sentence in my first résumé, and I still want it to be part of my identity—even if I sometimes wonder whether, like everyone else, I should lead with technology and outcomes instead. Whenever I notice something inconvenient, I have to improve it. I put my tumbler and phone on top of my lunch-bag cloth so I will not forget the coffee or lunch I set down. I cut a chair-leg noise pad to fit the point where the bathroom door keeps hitting the record cabinet. At the office sink, the hand soap and dish detergent kept turning around and becoming indistinguishable, so I labeled both the front and the back. I automated the company email-signature process and birthday reminders.
Even when the inconvenience is not mine, if someone mentions it—or I think they may experience it—I ask, “What about doing it this way?” and make the change before proposing it. When my girlfriend kept forgetting her transit card, I placed a holder and note by the door. When the company's workout channel tracked fines manually, I automated both workout completion and reminders to pay.
That instinct continued in the product. I optimized a board that slowed down while loading large datasets, preserved state across tab switches with Activity, and added progressive images so large assets appeared quickly. In development, I used composition components and named slots to keep per-screen UI flexible but consistent. I shortened long builds, introduced Storybook to improve communication with designers, and automated release notes to reduce coordination work.
There are, honestly, more examples than I can count. TokTok World began as an internal Advent calendar event and became a culture product. I built attendance and stretching-reminder apps that people at the company still use. Building systems and improving them one step at a time—making products more consistent and teammates more efficient—is deeply compelling and fun to me. Now I want to move beyond a small team and dramatically improve the efficiency of a larger one. I also want colleagues with whom I can share these questions about systems.
Recently, Daangn's Design Engineer opening made my heart race. Every part of the job description felt like what I had wanted. It was work I had already been doing because I loved it, and work I wanted to keep doing. I looked up Daangn's design-system team and discovered that Hyeonsu, whose articles I already followed, is part of it.
In the age of AI, the cost of writing code has dropped dramatically. That makes it even more important to produce consistent code. Consistent output requires code designed around consistent standards. Code built on such standards develops repeatable patterns, and the more those patterns repeat, the more reliably AI can implement them—or be forced to implement them. Models and context windows will keep changing and growing. What matters is not the changing model, but collecting, structuring, and injecting the stable context of decisions and work processes. A design system should become the source of truth for UI/UX and component-usage patterns.
One idea I keep returning to is treating a design system as a programming language. A recent video introduced BAML, a language for agents. It argues that current programming languages optimize for human productivity and already contain slop everywhere—JavaScript's default numeric sort converting values to strings, for example—so AI slop was inevitable. Instead of fighting that slop with prompts, BAML tries to remove it through types and language design. Could a design system likewise guide people toward intended patterns at the system level, not as a simple guide but as executable code containing rules and intent, much like the lint rules Toss built for voice and tone? What if AST analysis found frequently used patterns in a codebase, made them canonical, and exposed them at error, warning, and info levels? What if a dashboard continuously tracked those patterns so decisions accumulated over time?
Thinking through these questions makes my passion for development feel alive again. The spark is lit; now I need to fan the flame. I want to discuss design systems with other people, argue carefully about UI/UX and DX, and resist easy compromises. I hope the system we build can make life easier for the people around me and, eventually, for the many users of the product. Here is to joining a large-scale design-system team someday!
