Read This Before You Pay for a Vibe Coding Course

Read This Before You Pay for a Vibe Coding Course You've seen the YouTube video. Someone who knows zero coding talks to AI for a few minutes and an app pops out. A million views. The comments are full of "amazing" and "I'm trying this." You followed along and got 30 errors? The video didn't lie. It just edited out the important parts. And there's a course link sitting quietly in the description. Let's talk about what got cut. Fine, I'll Admit It — The Barrier Did Drop Credit where it's due. Vibe coding lowered the barrier to coding. That's a fact. "Vibe Coding" is a term coined by OpenAI co-founder Andrej Karpathy in early 2025. Instead of writing code, you describe what you want to AI and use the output. "Make me a login screen," "add a popup when the button is clicked" — it actually works. A simple page, a prototype, automating repetitive tasks. These genuinely work well. Knocking out a demo for...

바이브 코딩 강의 결제하기 전에 이 글을 읽어라

바이브 코딩 강의 결제하기 전에 이 글을 읽어라 유튜브에서 봤을 거다. 코딩 1도 모르는 사람이 AI한테 말 몇 마디 하니까 앱이 뚝딱 나오는 영상. 조회수 100만. 댓글창은 "대박", "나도 해볼래요"로 가득 차 있다. 그거 보고 따라 했더니 에러만 30개 뜨더라고? 영상이 거짓말을 한 건 아니다. 편집으로 잘라낸 부분이 있을 뿐이다. 그리고 영상 설명란에는 강의 링크가 조용히 박혀 있다. 그게 뭔지 얘기한다. 인정한다, 진입 장벽은 낮아졌다 먼저 인정할 건 인정한다. 바이브 코딩으로 코딩의 진입 장벽이 낮아졌다. 이건 사실이다. "바이브 코딩(Vibe Coding)"은 2025년 초 OpenAI 공동창업자 안드레이 카르파시가 쓴 단어다. 코드를 직접 짜는 게 아니라, AI에게 말로 설명하고 결과를 받아 쓰는 방식. "로그인 화면 만들어줘", "버튼 누르면 팝업 뜨게 해줘" — 실제로 된다. 단순한 화면 하나, 아이디어 검증용 프로토타입, 반복 작업 자동화. 이런 건 진짜 잘 된다. 투자자한테 보여줄 목업을 하루 만에 뽑는 것도 된다. 여기까진 진실이다. 문제는 이 진실 위에 올라탄 기생충들이다. 커피머신 사고 카페 차리겠다고? 요즘 커뮤니티에 매일 올라오는 글이 있다. "비개발자인데 AI로 앱 만들어서 창업할 거예요." "코딩 몰라도 되는 시대잖아요." "개발자 비용 아끼고 제가 직접 만들래요." 솔직히 말할게. 커피머신 하나 사놓고 커피 전문점 차리겠다는 소리다. 좋은 커피머신 사면 에스프레소 나온다. 맞다. 버튼 하나로 라떼도 된다. 집에서 마시기엔 충분하다. 근데 그걸로 카페를 차려? 원두 로스팅, 추출 변수 조절, 우유 스티밍, 메뉴 개발, 위생 관리, 인테리어, 입지 선정, 임대 계약, 인건비, 마케팅. 커피머신이 해결해주는 건 이 중에 하나도 없다. 커피머신은 커피를 내려...

How AI Coding Changed Completely in 18 Months — Is Prompt Engineering Dead?

How AI Coding Changed Completely in 18 Months — Is Prompt Engineering Dead? In late November 2024, I used AI for the first time. Eighteen months later, the changes I've witnessed aren't just about better tools. The entire way of working has transformed — and the pace of that transformation is accelerating. At first, a new paradigm emerged roughly every six months. Then every three months. Now, something new drops almost every week. AI has moved past its infancy and entered a full-blown transition period. Standing in the middle of it, I thought it was worth looking back at these 18 months. The Past — Copy-Paste and Prompt Engineering The Chat Window Era To be precise, it started with asking ChatGPT about code. I'd paste a function or an error message, get a response, copy it, and move it to my editor. The novelty of asking AI instead of searching Google was refreshing, and I was genuinely impressed by the accuracy. But fundamentally, the workflow wasn't all that d...

AI 활용법, 1년 반 만에 완전히 바뀌었다 — 프롬프트 엔지니어링은 이제 필요 없을까?

AI 활용법, 1년 반 만에 완전히 바뀌었다 — 프롬프트 엔지니어링은 이제 필요 없을까? 2024년 11월 말, 처음으로 AI를 사용했다. 그로부터 1년 반. 그 사이에 일어난 변화는 단순한 도구의 발전이 아니었다. 일하는 방식 자체가 바뀌었고, 바뀌는 속도 자체가 가속되고 있다. 처음에는 6개월 단위로 새로운 패러다임이 등장했다. 그것이 3개월로 줄었고, 지금은 한 주가 멀다 하고 새로운 것이 쏟아진다. AI는 태동기를 지나 과도기에 접어들었다. 그리고 과도기의 한가운데에 서 있는 지금, 이 1년 반을 돌아보는 것이 의미가 있겠다는 생각이 들었다. 과거 — 복사 붙여넣기, 그리고 프롬프트 엔지니어링 대화창 시대 정확히 말하면 ChatGPT에 코드를 물어보는 것부터 시작했다. 함수 하나, 에러 메시지 하나를 붙여넣고 답변을 받아 복사해서 에디터에 옮기는 방식. 구글 검색 대신 AI에게 물어본다는 것 자체가 신선했고, 답변의 정확도에 꽤 놀랐다. 하지만 사용 방식은 본질적으로 검색과 다르지 않았다. 질문하고, 답변을 읽고, 수동으로 적용하는. 그 반복이었다. 그때는 이것만으로도 충분히 혁신적이라고 생각했다. 프롬프트 엔지니어링이라는 발견 몇 달이 지나자 한계가 보이기 시작했다. 같은 질문인데 어떻게 물어보느냐에 따라 답변의 질이 확연히 달라졌다. "이 코드 고쳐줘"라고 하면 대충 수정해주지만, 역할을 부여하고 맥락을 설명하고 출력 형식을 지정하면 전혀 다른 수준의 결과가 나왔다. 2025년 초, 프롬프트 엔지니어링을 본격적으로 학습하기 시작했다. 시스템 프롬프트 설계, 체인 오브 씽킹, 퓨샷 러닝, 역할 지정. 프롬프트 하나를 설계하는 데 코드를 작성하는 것만큼의 시간을 들이기도 했다. 실제로 효과가 있었다. 같은 모델이라도 프롬프트에 따라 주니어 개발자 수준의 답변과 시니어 개발자 수준의 답변을 오갔다. AI를 제대로 활용하려면 프롬프트 엔지니어링은 필수라고 확신했다. 그런데 그 확신은 오래가지 않았다. 프롬프트 엔지...

What It Means to Design Scenarios with AI

What It Means to Design Scenarios with AI From the moment my kid said "visual novel," we have come this far. Twenty parts. Looking back, we have covered quite a distance. Not a single line of code was written. Ren'Py was never installed. And yet the most important work of this project is done. Scenario design. The work of understanding the structure of emotion and translating it into systems. What I Discovered on This Journey At the start, the goal was "making a visual novel." By the end, the goal had shifted. Making a visual novel is not technically difficult. Ren'Py handles most of the technical challenges. The difficult part is making a visual novel that truly moves the player's emotions. And for that, what you need is not technology but an understanding of emotion. Love is not a single variable but the result of conditions. A scene is not a backdrop but an amplifier of emotion. The consequences of choices arrive not immediately but later. Good ...

The Complete Scenario Architecture — Weaving It All Together

The Complete Scenario Architecture — Weaving It All Together Over 19 parts, we designed individual elements. Now it is time to weave them all together. Here is the complete picture of the design built with AI. System Architecture Summary This visual novel runs on three core systems. 1. Emotion System (3 Layers) Layer A - Fundamental Disposition: need_for_affection, fear_of_rejection, pride, insecurity Layer B - Momentary Emotion: affection, anger, sadness, jealousy, admiration, fear Layer C - Relationship State: trust, reliance, intimacy, tension, resentment, respect Love is not a variable. It emerges from the combination of Layer C variables. 2. Context System location: 5 locations time: 4 time periods weather: 4 weather types (not player-controllable) privacy: 3 levels mood: 5 atmospheres The same event creates different emotions depending on context. 3. Memory System Pattern tracking: did_not_ask, avoided_confession, missed_timing, etc. Event flags: shared_umbrella, saw...

Endings Are Not Success or Failure

Endings Are Not Success or Failure Endings in most existing visual novels work like this. High affection means a happy ending, low means a bad ending. Success or failure. Pass or fail. But real relationships do not divide into success and failure. There are relationships where both people liked each other but it did not work out, and relationships that lasted despite no initial attraction. There are relationships that fit perfectly but the timing was off, and relationships that do not fit but neither person can let go. To express these diverse outcomes, endings must be determined not by a single value but by a combination of states. State-Combination Endings This is the ending structure designed with AI. Connected — High trust + low avoidance + mutual emotion. The most demanding conditions. Simply liking each other is not enough; trust must have been built, and the player must not have avoided key moments. Late Love — High trust + high avoidance. They know each other's hea...