I'd never built an app before. Claude Code made me think I could.

Backend is my world — I've done it for years. API design, data modeling, infrastructure. But the app side? I didn't know React Native from Expo, let alone how navigation stacks or state management worked on the client side.

The usual approach: read the docs, understand the framework, design the architecture, then write code. I did the opposite. I opened Claude Code, described what I wanted, and started building. When something broke, I fixed it. When something worked, I moved on. I learned why things worked by watching them work — or fail.

I coded backward.

I looked at my MCP connections and realized which companies survive the AI shift — and which don't.

At softly, we tried to automate customer support for clinics. The AI part worked — FAQs, multi-step lookups, even reasoning about clinic policies. The support part didn't.

People don't message a clinic to ask what's on the website. They want someone who knows the things the website doesn't say — can this procedure fix my specific case, will it hurt more than last time, if I'm combining two procedures which order matters — and who can solve their problem right now.

Each question is an edge case. Getting one wrong isn't just bad service — a hallucinated answer about a procedure is dangerous. Generalization and hallucination come from the same place.

But even accurate answers weren't enough. The job was conversion — turning that anxious inquiry into a patient who actually walks through the door. Every rule we wrote implied ten more we hadn't thought to write. The gap never closed.

Coding agents already ship features^[1]. Design tools generate layouts from prompts. Customer support looks like the obvious next step — text-based work, recognizable patterns^[2]. In 2011, Gartner predicted that by 2020, customers would manage 85% of their relationship with an enterprise without interacting with a human^[3]. Fifteen years later, the job still exists.

This is an English translation of the Korean version.

I kept reading that qbits can represent \(2^n\) states simultaneously, and I kept nodding along. Then I asked myself three questions and couldn't answer any of them.

In mid-2022, I typed a prompt into platform.openai.com and got back something that didn't feel like a demo.

It was text-davinci-002. Before ChatGPT, before the hype. But it wasn't the output that mattered. It was the feeling: this is going to break everything we know about building AI products.

Building a good AI model meant collecting data, training, and fine-tuning for specific tasks. Hard, slow, expensive work. Davinci-002 could do a rough version of most of it with just a prompt — plain English, no data, no training, no cost.

My co-founders and I were already building softly, an AI startup. A few months later, ChatGPT launched and everyone else felt it too.

Our team has joined HealingPaper — known as 강남언니 (UNNI) in Korea. I'm leading AI product. Here's what we learned getting here.

Git은 한 브랜치에서 작업한 내용을 Main 브랜치에 병합(Merge)할 수 있는 다양한 방법들을 제공한다. 이러한 방법들을 Merge 전략이라고 부르는데, 다양한 방법들 중에서도 이번 글에서는 가장 많이 사용되는 방법인 1) Merge Commit, 2) Squash and Merge, 3) Rebase and Merge에 대해 소개하려고 한다.

최근에 pytorch로 간단한 모듈을 재구현하다가 loss와 dev score가 원래 구현된 결과와 달라서 의아해하던 찰나, tensor 차원을 변경하는 과정에서 의도하지 않은 방향으로 구현된 것을 확인하게 되었다. 그리고 그 이유는 transpose 와 view 의 기능을 헷갈려했기 때문이었다. 두 함수의 차이는 contiguous 를 이해해야 알 수 있는 내용이었고, 혹시 이 개념이 헷갈리는 사람들을 위해 간단한 예시를 바탕으로 정리해보았다.

PyTorch 1.2 이상부터 torch.utils.data 에서는 크게 map-style dataset (torch.utils.data.Dataset) 과 iterable dataset (torch.utils.data.IterableDataset) 의 두 종류의 데이터 클래스를 지원하고 있다. 데이터 사이즈가 클 때는 IterableDataset 을 사용하는 것이 좋은데, Dataset 과는 딜리 아직 개발되어야 할 기능이 더 필요한 클래스라서 사용할 때에 유의할 점이 있어 정리해보게 되었다.

pandas는 데이터를 다루는 사람들이라면 누구나 쓸 수 밖에 없는 오픈소스 라이브러리이다. table 형식의 데이터를 다루기에 편리하지만 오픈소스라는 특징과 다양한 기능 지원 때문에 속도 면에서는 최적화되어 있지 않은 편이다. 이번 글에서는 pandas의 여러 기능 중에서 iteration하는 여러 방법을 속도와 사용성 측면에서 비교해본 내용을 아주 간단하게 정리해 보았다.