메뉴
HN
Hacker News • 36일 전

Huzzah – AI 코딩의 새로운 패러다임, 유사코드 기반 에디터

IMP
6/10
핵심 요약

한 개발자가 코딩 에이전트의 한계(긴 영어 프롬프트 작성 피로, 휘발성 프롬프트, 비효율적 토큰 소비)를 극복하기 위해 'Huzzah'라는 실험적 에디터를 공개했습니다. Huzzah는 명령형·장문·일회성 프롬프트 대신 유사코드(pseudocode)·선언형·영속적 프롬프트라는 새로운 접근법을 제시하며, 파일을 저장하면 AI가 자동으로 실제 코드를 생성하고 수정 사항은 diff 기반으로 반영됩니다.

번역된 본문

저와 같은 소프트웨어 엔지니어라면 2026년 초의 몇 달은 놀라운 시기였을 것입니다. 코딩 에이전트가 갑자기 충분히 좋아져서 더 이상 코드를 직접 작성할 필요가 없어졌으니까요. 하지만 저와 같다면 얼마 후 벽에 부딪혔을 겁니다. 신혼기가 끝나고 신선함이 사라졌습니다. 더 이상 도파민이 나오지 않습니다. 지금은 8월이고, 저는 완전히 지쳤습니다. 솔직히 말하면, 코드베이스에 원하는 모든 변경 사항을 긴 영어로 설명하는 일에 질이 나서 죽을 지경입니다. 하지만 모든 코드를 다시 직접 작성하고 싶지도 않습니다. 그런 방식에는 진짜 지루함이 있었고, 저는 남은 인생 동안 그것을 피하고 싶습니다. 그러면서도 코드가 하는 일에 대해 더 나은 통찰과 통제가 필요하다는 것을 느낍니다. 제 산출물이 고품질의 신뢰할 수 있는 소프트웨어라는 것을 알고 싶습니다. 전문가로서 자부심을 느끼고 싶습니다. 그래서 둘 다 갖기 위한 방법을 찾고 있습니다.

제가 코딩 에이전트에서 느끼는 문제점은 다음과 같습니다.

인간의 의도에 대한 신뢰할 만한 기록이 없습니다. 프롬프트는 버려지고, 코드가 AI에 의해 생성되었는지 여부도 알 수 없습니다. 인간이 기계에게 무엇을 원하는지 표현하는 중심 권위를 잃었고, 이 사실과 마주하는 것이 중요하다고 생각합니다.

AI 챗은 명령형(imperative)이며, 애플리케이션 자체가 아니라 애플리케이션의 변경 사항을 단계별로 설명하는 지시사항입니다. 즉, 지시사항이 개발 과정에서 반복되어 토큰을 여러 번 소비합니다. 이는 비효율적입니다.

자연어의 상당 부분은 정보 전달이 아닌 사회적 이유로 존재합니다. 평균적인 문장에는 실질적인 정보가 매우 적습니다. 이런 방식으로 기계에게 글을 쓰는 것은 번거롭습니다.

이러한 문제를 해결하기 위해 저는 실험적인 에디터를 만들고 있습니다. 이름은 Huzzah이며, LLM과 함께 작업하는 대안적 패러다임을 제시합니다. 코딩 에이전트에서 프롬프트는 (a) 장문이고, (b) 명령형이며, (c) 휘발적입니다. Huzzah에서 프롬프트는 (a) 유사코드(pseudocode)이고, (b) 선언형이며, (c) 영속적입니다.

직접 보여드리는 게 더 쉬울 것입니다. (브라우저가 임베디드 비디오를 지원하지 않는 경우, Huzzah 데모를 직접 시청할 수 있습니다.)

Fizz Buzz 비교

아주 간단한 예시를 들어보겠습니다. AI를 사용해 fizz buzz를 만들고 싶다고 합시다. 두 번 해볼 겁니다. 한 번은 코딩 에이전트로, 한 번은 Huzzah로요.

코딩 에이전트라면

선호하는 도구에서 채팅을 시작하고 다음과 같이 입력합니다:

100번 반복하는 함수를 만들어줘. 숫자가 3으로 나누어떨어지면 "fizz"를 출력하고, 5로 나누어떨어지면 "buzz"를 출력하고, 둘 다로 나누어떨어지면(예: 15) "fizz buzz"를 출력해줘.

수정이 필요하면 채팅에 후속 메시지를 보냅니다:

100번 반복하는 대신, 함수가 숫자 입력을 받아 그 횟수만큼 반복하도록 해줘.

이 과정을 만족할 때까지 반복합니다.

Huzzah라면

fizz_buzz.hz라는 새 파일을 만듭니다. 그 안에 원하는 방식으로 유사코드 표현을 작성합니다. 개인적으로는 이렇게 하겠습니다:

fizz_buzz() loop 100 modulo 3 ? "fizz" 5 ? "buzz" both ? "fizz buzz"

파일을 저장하면 Huzzah가 자동으로 실제 코드를 생성합니다. 수정이 필요하면 파일을 업데이트하면 됩니다:

fizz_buzz(n) loop n modulo 3 ? "fizz" 5 ? "buzz" both ? "fizz buzz"

파일을 저장하면 Huzzah가 diff(변경 사항)를 캡처하여 LLM의 프롬프트로 사용합니다. 영향을 받는 소스 코드가 그에 따라 재생성됩니다.

다른 예시들

다른 시나리오에서 어떤 모습일지 더 잘 보여드리기 위해 몇 가지 추가 예시를 소개합니다.

1. 장바구니

list cart list inventory mock_data = // 모의 데이터 포함

init() inventory.fill(mock_data)

add_item(id) cart.add(item by id)

remove_item(id) cart.filter(item by id)

checkout() return cart.sum(item by price) and format as price

2. 할 일 목록

Todo { id: int text: str completed: bool }

add_todo(text) todos.add(text, completed = false)

toggle_todo(id) todo = todos.get by id todo.completed = NOT .completed

remove_todo(id) todos.filter by id

장점

이미 몇 가지 장점을 눈치채셨을 것입니다. (이하 생략된 부분)

원문 보기
원문 보기 (영어)
If you’re a software engineer like me, the first few months of 2026 were incredible. Coding agents suddenly became good enough that we no longer needed to manually write code. But if you’re like me, then sometime later you hit a wall. The honeymoon period ended, and the novelty wore off. No more dopamine hits. It’s August, and I feel utterly fatigued . To be honest, I’m sick to death of writing longform English to describe every change I want to my codebase. However, I also don’t want to go back to writing all my code manually. There was real tedium in that practice that I’d prefer to avoid for…well, the rest of my life. And yet, I sense that I need to have better insight and control over what my code is doing. I want to know that my output is high quality, reliable software. I want to feel good about myself as a professional. So I’m trying to find a way to have my cake and eat it too. My problem with coding agents is that There’s no reliable record of human intent. Prompts are discarded, and the code may or may not have been generated by AI. We’ve lost the central authority that expresses what the human wants out of the machine, and I think it’s important to contend with that fact. AI chats are imperative, step-by-step instructions that describe changes to the application, not the application itself. This means instructions are often repeated, and thus consume tokens, many times over the course of development. This is inefficient. Much of natural language exists for social reasons, not informational. The average sentence is scarce in real information. Writing in this manner, to a machine, is cumbersome. To address these problems, I’m building an experimental editor. I’m calling it Huzzah, and it poses an alternative paradigm for working with LLMs. With coding agents, prompts are (a) longform, (b) imperative, and (c) transient. With Huzzah, prompts are (a) pseudocode, (b) declarative, and (c) persistent. It’s easier if I just show you. Your browser does not support embedded video. You can watch the Huzzah demonstration directly . Comparing fizz buzz Let’s take a very simple example - say you want to use AI to create fizz buzz . We’ll do this twice - once with coding agents and another with Huzzah. With coding agents You start a chat in your tool of choice, and type something like the following: Create a function that loops 100 times. If the number is divisible by 3, print “fizz”. If the number is divisible by 5, print “buzz”. If the number is divisible by both (like 15 for example), print “fizz buzz”. If you need to make an edit, you’d send a follow up message to the chat: Instead of looping 100 times, the function should take a number input and the function should loop that amount of times. You repeat this process until you’re satisfied. With Huzzah You create a new file called fizz_buzz.hz . In it, you write a pseudocode representation, however you like. This is how I’d do it, personally: fizz_buzz() loop 100 modulo 3 ? "fizz" 5 ? "buzz" both ? "fizz buzz" You save the file, and Huzzah automatically generates real code from it. If you need to make an edit, simply update your file: fizz_buzz(n) loop n modulo 3 ? "fizz" 5 ? "buzz" both ? "fizz buzz" When you save the file, Huzzah captures the diff and uses it as the prompt to the LLM. The affected source code is thus regenerated. Some other examples To give you a better sense for what this could look like in other scenarios, here are some alternative examples. 1. Shopping cart list cart list inventory mock_data = // include some mock data init() inventory.fill(mock_data) add_item(id) cart.add(item by id) remove_item(id) cart.filter(item by id) checkout() return cart.sum(item by price) and format as price 2. Todo List Todo { id: int text: str completed: bool } add_todo(text) todos.add(text, completed = false) toggle_todo(id) todo = todos.get by id todo.completed = NOT .completed remove_todo(id) todos.filter by id Benefits You should be able to see some benefits already. Notice how much more terse and readable the pseudocode is than the longform prompts? Here are some more: Writing prompts this way engages your mind, because it feels much more like you’re designing the shape of the code. You can be as terse or as verbose as you like. The pseudocode acts as developer documentation because a human wrote it to express their intent. You could write a language agnostic pseudocode and use it as the basis for multiple language or environmental targets. Think complex algorithms, like a CRDT . Caveats There are no silver bullets, of course. Some exceptions: It’s entirely possible that there are issues with this approach at scale. This is obviously more ideal for new codebases than existing ones. If you lack domain expertise, natural language is probably the easier interaction method. Some things may be more difficult to reliably express, like cross-file dependencies. LSP-type features would not be available (though this could plausibly be generated). Current state Huzzah is actively being developed, and exists only in an experimental state for now. You can find the source code and setup instructions here . Please give it a spin and let me know what you think! Cheers.