바이브 코딩에서 하네스 엔지니어링이란 무엇인가

AI로 코드를 만드는 일이 더 이상 낯설지 않은 시대입니다. 이제 많은 개발자들이 자연어로 요구사항을 던지고, AI가 그에 맞춰 코드를 생성하는 흐름에 익숙해지고 있습니다. 이런 방식은 흔히 “바이브 코딩”이라고 불립니다. 아이디어를 빠르게 형태로 만들고, 초안을 생성하고, 반복 작업을 줄이는 데는 분명 강력합니다.

하지만 실제 프로젝트로 들어가면 금방 한계가 드러납니다. AI가 만든 코드는 얼핏 그럴듯해 보여도, 구조가 불안정하거나 기존 규칙을 어기고, 테스트를 통과하지 못하거나, 예상하지 못한 영역까지 건드리는 경우가 많습니다. 결국 중요한 것은 AI가 코드를 써주는 능력 자체가 아니라, 그 AI가 얼마나 통제된 환경 안에서 안정적으로 일하느냐입니다.

이 지점에서 등장하는 개념이 바로 하네스 엔지니어링입니다.

바이브 코딩은 왜 부족해지는가

바이브 코딩의 핵심은 속도입니다. 개발자가 세부 구현을 하나하나 직접 작성하기보다, 의도와 분위기, 원하는 결과를 설명하면 AI가 코드를 빠르게 만들어 냅니다. 프로토타입을 만들거나 아이디어를 실험할 때는 매우 효율적입니다.

문제는 실제 서비스 개발에서는 속도만으로 충분하지 않다는 점입니다. 프로젝트에는 이미 정해진 폴더 구조가 있고, 디자인 토큰이 있으며, 팀 규칙과 코드 스타일이 있고, 빌드와 테스트를 통과해야 하며, 성능과 접근성, 유지보수성까지 고려해야 합니다. 그런데 바이브 코딩은 종종 이런 현실적인 제약을 무시한 채 “그럴듯한 결과물”만 만들어 냅니다.

즉, 바이브 코딩은 시작은 쉽게 만들지만, 신뢰할 수 있는 결과를 반복적으로 내기에는 부족할 수 있습니다.

하네스 엔지니어링이란 무엇인가

하네스 엔지니어링은 AI가 코드를 생성하는 과정을 그냥 지켜보는 것이 아니라, 그 AI가 어떤 환경에서 어떤 규칙 아래 어떤 방식으로 동작해야 하는지를 설계하는 접근입니다.

쉽게 말하면, 바이브 코딩이 “AI에게 만들어 달라고 말하는 것”이라면 하네스 엔지니어링은 “AI가 멋대로 망가지지 않도록 작업 레일을 까는 것”에 가깝습니다.

여기서 하네스는 단순한 도구 하나를 뜻하지 않습니다. 오히려 다음과 같은 요소 전체를 포함하는 작업 시스템에 가깝습니다.

• 어디까지 수정할 수 있는지 정하는 범위
• 어떤 규칙을 따라야 하는지 정하는 제약
• 결과가 올바른지 검사하는 검증 절차
• 잘못된 출력을 걸러내는 보호 장치
• 실패와 수정 이력을 반영하는 피드백 구조

결국 하네스 엔지니어링은 AI를 잘 쓰는 기술이라기보다, AI가 신뢰 가능하게 일하도록 운영 환경을 설계하는 엔지니어링이라고 볼 수 있습니다.

왜 개발자의 역할이 바뀌는가

AI가 코드를 직접 많이 써주기 시작하면, 개발자의 역할도 바뀝니다. 이전에는 사람이 구현의 대부분을 직접 담당했다면, 이제는 사람이 AI가 제대로 구현하도록 조건을 설계하고 결과를 검증하는 쪽으로 무게가 이동합니다.

이 말은 개발자의 가치가 줄어든다는 뜻이 아닙니다. 오히려 반대입니다. 코드를 한 줄씩 입력하는 능력만으로는 차별화가 어려워지고, 대신 어떤 구조를 허용할지, 어떤 변경은 막아야 할지, 어떤 기준으로 품질을 판단할지를 정의하는 능력이 더 중요해집니다.

즉, 앞으로는 “코드를 잘 짜는 사람”만큼이나 “AI가 올바르게 코드를 짜도록 시스템을 설계하는 사람”이 강해질 가능성이 큽니다.

하네스 엔지니어링의 핵심 요소

하네스 엔지니어링은 추상적인 개념처럼 들릴 수 있지만, 실제로는 꽤 구체적인 구성 요소들로 이루어집니다.

1. 명확한 제약 조건 설정

AI는 자유도를 많이 줄수록 엉뚱한 결과를 내놓기 쉽습니다. 따라서 어떤 프레임워크를 쓸지, 어떤 파일만 수정할 수 있는지, 어떤 코딩 스타일을 따라야 하는지, 무엇은 절대 건드리면 안 되는지를 명확하게 정해야 합니다.

예를 들어 프론트엔드 프로젝트라면 다음과 같은 제약을 둘 수 있습니다.

• Next.js App Router 구조만 유지
• components/landing 내부 파일만 수정 가능
• 기존 design token 외 색상 추가 금지
• any 타입 사용 금지
• API 호출 대신 mock data만 사용

이런 제약은 AI의 창의성을 줄이는 것이 아니라, 실무에서 필요한 정확도를 높이는 역할을 합니다.

2. 자동 검증 파이프라인

AI가 만든 결과물이 정말 쓸 만한지 확인하려면 검증이 필수입니다. 눈으로 한 번 읽어보는 정도로는 부족합니다. 최소한 다음과 같은 검증 절차가 연결되어야 합니다.

• 타입 체크
• 린트 검사
• 단위 테스트
• 빌드 테스트
• 접근성 검사
• 시각적 회귀 테스트

AI가 결과를 생성한 뒤 이 검증을 통과하지 못하면, 그 출력은 “완성된 코드”가 아니라 그냥 초안에 불과합니다. 하네스 엔지니어링은 이 검증 절차를 AI 워크플로에 기본으로 포함시키는 접근입니다.

3. 실패 방지 장치

AI는 때때로 생각보다 훨씬 위험하게 움직입니다. 관련 없는 파일을 수정하거나, 필요 없는 의존성을 추가하거나, 구조 전체를 뒤흔드는 변경을 만들 수 있습니다. 그래서 반드시 안전장치가 필요합니다.

예를 들면 이런 식입니다.

• 수정 가능한 파일 수 제한
• 특정 디렉터리 밖 변경 금지
• 패키지 설치 명령 차단
• 환경 변수 파일 접근 제한
• 대규모 리팩터링 자동 차단

핵심은 AI를 전적으로 믿지 않는 것입니다. 성능이 좋아졌다고 해서 무제한 권한을 줘서는 안 됩니다.

4. 피드백 루프 설계

AI의 출력 품질을 높이려면, 어떤 결과가 승인되었고 어떤 결과가 거절되었는지 기록하고 반영해야 합니다. 사람이 수정한 패턴, 자주 발생하는 실수, 반복적으로 거절되는 스타일을 모으면 점점 더 나은 작업 환경을 만들 수 있습니다.

이것이 단순한 프롬프트 엔지니어링과 다른 점입니다. 프롬프트 엔지니어링은 그때그때 더 잘 말하는 데 집중하는 반면, 하네스 엔지니어링은 시스템 전체가 점점 더 나은 결과를 내도록 만드는 데 초점을 둡니다.

5. 작업 분해와 역할 분리

하나의 AI에게 모든 일을 시키면 결과가 불안정해질 수 있습니다. 그래서 작업을 나누는 방식도 중요합니다. 예를 들어 다음과 같이 역할을 나눌 수 있습니다.

• 요구사항 해석 에이전트
• 구현 에이전트
• 리뷰 에이전트
• 테스트 보정 에이전트

이렇게 분리하면 각 단계의 책임이 명확해지고, 오류를 조기에 걸러낼 가능성이 높아집니다.

프론트엔드 개발에서 이해하면 쉬운 예시

프론트엔드 실무 기준으로 보면 차이가 더 분명합니다.

바이브 코딩은 이런 요청에 가깝습니다.

“감성적인 느낌의 랜딩 페이지 하나 만들어줘.”

반면 하네스 엔지니어링은 이런 식입니다.

“Next.js 기반으로 작업하고, app 라우터 구조는 유지하고, components/marketing 디렉터리 안에서만 수정해. 색상은 기존 디자인 토큰만 사용하고, 반응형은 360px부터 지원해야 해. 타입 에러와 eslint 에러는 없어야 하고, Lighthouse 성능 점수에 영향을 줄 수 있는 무거운 라이브러리는 추가하지 마.”

둘 다 AI에게 작업을 시키는 방식이지만, 후자는 훨씬 더 실무적이고 재현 가능성이 높습니다.

프롬프트 엔지니어링과 무엇이 다른가

하네스 엔지니어링을 단순히 프롬프트 엔지니어링의 확장판 정도로 보는 경우가 있습니다. 하지만 둘은 초점이 다릅니다.

프롬프트 엔지니어링은 주로 “어떻게 요청하면 더 나은 답이 나오는가”에 집중합니다. 반면 하네스 엔지니어링은 “AI가 어떤 환경에서 어떤 규칙 아래 어떤 검증을 거쳐야 신뢰 가능한 결과를 내는가”를 다룹니다.

즉, 전자는 문장 기술에 가깝고, 후자는 시스템 설계에 가깝습니다.

이 개념이 중요한 이유

AI 코딩 도구는 계속 발전하고 있습니다. 문제는 성능이 좋아질수록 오히려 더 쉽게 과신하게 된다는 점입니다. 얼핏 보면 잘 만든 것 같지만, 실제로는 유지보수 비용이 커지고 품질이 흔들리는 결과가 나올 수 있습니다.

그래서 앞으로 중요한 것은 “AI가 코드를 얼마나 잘 쓰는가”가 아니라 “AI가 실수하더라도 안전하게 제어할 수 있는 구조가 있는가”입니다. 이것이 하네스 엔지니어링이 중요한 이유입니다.

이 개념은 단지 AI 시대의 유행어로 끝나지 않을 가능성이 큽니다. 오히려 개발 조직이 AI를 실제 생산 환경에 도입할 때 반드시 고민하게 되는 현실적인 운영 문제를 설명하는 말에 가깝습니다.

마무리

바이브 코딩은 빠르고 매력적입니다. 하지만 실무에서는 속도보다 안정성이 더 중요할 때가 많습니다. 그리고 그 안정성은 AI 모델 자체보다, 그 AI를 어떻게 통제하고 검증하느냐에서 나옵니다.

하네스 엔지니어링은 바로 그 부분을 다룹니다. AI에게 일을 맡기는 데서 끝나는 것이 아니라, AI가 일하는 방식 자체를 설계하는 것입니다. 앞으로 개발자는 단순히 코드를 생산하는 사람을 넘어, AI가 신뢰 가능한 방식으로 코드를 생산하도록 시스템을 만드는 사람으로 더 자주 평가받게 될 것입니다.

결국 바이브 코딩 다음 단계는 더 좋은 프롬프트가 아니라, 더 좋은 하네스일지도 모릅니다.

Creating code with AI no longer feels unusual. Many developers are now used to writing requirements in natural language and letting AI generate code from them. This workflow is often called “vibe coding.” It is clearly powerful for quickly shaping ideas, producing drafts, and reducing repetitive work.

But once you move into a real project, the limits become visible quickly. AI-generated code may look plausible at first, yet still have unstable structure, violate existing rules, fail tests, or touch areas it was not supposed to touch. What matters is no longer just whether AI can write code, but whether it can work reliably inside a controlled environment.

This is where harness engineering comes in.

Why Vibe Coding Becomes Insufficient

The core of vibe coding is speed. Instead of writing every implementation detail by hand, the developer describes the intention, mood, and desired result, and the AI quickly creates code. For prototypes or idea experiments, this is highly efficient.

The problem is that real product development cannot run on speed alone. A project already has a folder structure, design tokens, team conventions, code style, build and test requirements, performance concerns, accessibility requirements, and maintainability constraints. Vibe coding often ignores these practical constraints and produces only a “plausible-looking result.”

In other words, vibe coding makes starting easy, but it may not be enough to repeatedly produce trustworthy results.

What Is Harness Engineering?

Harness engineering is an approach where you do not merely watch AI generate code. Instead, you design the environment, rules, and operating conditions under which the AI should work.

Simply put, if vibe coding is “asking AI to build something,” harness engineering is closer to “laying down rails so AI cannot break things freely.”

Here, a harness does not mean one specific tool. It is closer to a whole working system that includes elements such as:

• The scope that defines what can be changed
• The constraints that define which rules must be followed
• The validation process that checks whether the result is correct
• The safeguards that filter out bad outputs
• The feedback structure that reflects failures and revision history

Ultimately, harness engineering is less about using AI skillfully and more about engineering an operating environment where AI can work in a trustworthy way.

Why the Developer’s Role Is Changing

As AI starts writing more code directly, the developer’s role also changes. In the past, people handled most implementation work themselves. Now the weight shifts toward designing the conditions that help AI implement correctly and verifying the result.

This does not mean developers become less valuable. It is the opposite. The ability to type code line by line becomes less differentiating, while the ability to define which structures are allowed, which changes should be blocked, and which standards determine quality becomes more important.

In the future, “someone who designs the system that lets AI write code correctly” may become as strong as “someone who writes code well.”

Core Elements of Harness Engineering

Harness engineering may sound abstract, but in practice it consists of very concrete components.

1. Clear Constraints

The more freedom AI receives, the easier it is for it to produce strange results. You need to clearly define which framework to use, which files it can modify, which coding style it must follow, and what it must never touch.

For example, in a frontend project you might set constraints like these:

• Keep the Next.js App Router structure
• Modify only files inside components/landing
• Do not add colors outside the existing design tokens
• Do not use the any type
• Use mock data instead of API calls

These constraints do not reduce AI creativity. They increase the accuracy required for practical work.

2. Automated Validation Pipeline

Validation is essential if you want to know whether an AI-generated result is actually usable. Reading the code once is not enough. At minimum, the workflow should connect checks such as:

• Type checking
• Linting
• Unit tests
• Build tests
• Accessibility checks
• Visual regression tests

If AI generates a result but it cannot pass these checks, the output is not “finished code.” It is only a draft. Harness engineering makes this validation process a default part of the AI workflow.

3. Failure Prevention Guards

AI sometimes acts in much riskier ways than expected. It can modify unrelated files, add unnecessary dependencies, or make changes that shake the whole structure. Safety guards are therefore necessary.

Examples include:

• Limiting the number of files that can be modified
• Blocking changes outside specific directories
• Blocking package installation commands
• Restricting access to environment variable files
• Automatically blocking large-scale refactors

The key is not to trust AI completely. Even if the model becomes more capable, it should not receive unlimited authority.

4. Feedback Loop Design

To improve AI output quality, you need to record and reflect which results were approved and which were rejected. By collecting the patterns people corrected, the mistakes that occur often, and the styles that are repeatedly rejected, you can build a better working environment over time.

This is where harness engineering differs from simple prompt engineering. Prompt engineering focuses on saying things better in the moment. Harness engineering focuses on making the entire system produce better results over time.

5. Task Decomposition and Role Separation

If one AI is asked to do everything, the result can become unstable. The way work is divided also matters. For example, roles can be separated like this:

• Requirements interpretation agent
• Implementation agent
• Review agent
• Test correction agent

This separation clarifies responsibility at each step and increases the chance of catching errors early.

A Frontend Example That Makes It Easier to Understand

From a frontend practice perspective, the difference becomes clearer.

Vibe coding sounds like this:

“Make me a landing page with an emotional feel.”

Harness engineering sounds more like this:

“Work in a Next.js project, keep the app router structure, and modify only files inside components/marketing. Use only existing design tokens for colors, support responsive layouts from 360px, avoid type errors and eslint errors, and do not add heavy libraries that could affect the Lighthouse performance score.”

Both approaches ask AI to do work, but the latter is much more practical and reproducible.

How Is It Different from Prompt Engineering?

Some people see harness engineering as just an extension of prompt engineering. But the focus is different.

Prompt engineering mainly asks, “How should I request something to get a better answer?” Harness engineering asks, “In what environment, under which rules, and through which validation process can AI produce a trustworthy result?”

The former is closer to writing technique. The latter is closer to system design.

Why This Concept Matters

AI coding tools keep improving. The problem is that the better they become, the easier it is to overtrust them. A result may look well made at first, but later increase maintenance cost or weaken quality.

So the important question is shifting from “How well can AI write code?” to “Do we have a structure that can safely control AI even when it makes mistakes?” That is why harness engineering matters.

This concept is unlikely to remain just another AI-era buzzword. It is closer to a practical operational issue that development teams must address when they introduce AI into real production workflows.

Closing

Vibe coding is fast and attractive. But in real work, stability is often more important than speed. That stability comes less from the AI model itself and more from how we control and validate that AI.

Harness engineering deals with exactly that part. It does not stop at assigning work to AI; it designs how AI works. Going forward, developers may be evaluated less as people who simply produce code and more as people who build systems that let AI produce code reliably.

In the end, the next step after vibe coding may not be a better prompt, but a better harness.

用 AI 写代码已经不再陌生。现在，很多开发者已经习惯用自然语言提出需求，再让 AI 按照这些需求生成代码。这种方式通常被称为 “vibe coding”。它在快速把想法变成形状、生成草稿、减少重复工作方面确实很强。

但一进入真实项目，局限很快就会暴露出来。AI 生成的代码乍看合理，却可能结构不稳定、违反既有规则、无法通过测试，或者改动了本不该触碰的区域。最终重要的不是 AI 本身能不能写代码，而是 AI 能否在受控环境中稳定地工作。

这时就会出现 harness engineering 这个概念。

为什么 Vibe Coding 会变得不够用

Vibe coding 的核心是速度。开发者不必亲手写出每个实现细节，只要说明意图、氛围和期望结果，AI 就能快速生成代码。做原型或实验想法时，这非常高效。

问题在于，真实服务开发不能只靠速度。项目里已经有固定的文件夹结构、设计 token、团队规则、代码风格，还必须通过构建和测试，同时要考虑性能、可访问性和可维护性。而 vibe coding 往往会忽略这些现实约束，只做出“看起来像样的结果”。

也就是说，vibe coding 能让开始变得容易，但未必足以反复产出可信赖的结果。

什么是 Harness Engineering？

Harness engineering 不是单纯旁观 AI 生成代码，而是设计 AI 应该在什么环境、什么规则、什么方式下工作的做法。

简单来说，如果 vibe coding 是“请 AI 帮我做出来”，那么 harness engineering 更接近于“先铺好工作轨道，避免 AI 随意把东西弄坏”。

这里的 harness 不是指某一个工具。它更像是包含以下要素的整套工作系统：

• 定义可以修改到哪里的范围
• 定义必须遵守哪些规则的约束
• 检查结果是否正确的验证流程
• 过滤错误输出的保护机制
• 反映失败和修改历史的反馈结构

归根结底，harness engineering 与其说是“会用 AI 的技巧”，不如说是设计一个让 AI 能可靠工作的运行环境。

为什么开发者的角色正在变化

当 AI 开始直接写出大量代码时，开发者的角色也会改变。过去，大部分实现由人亲自完成；现在，重心逐渐转向设计让 AI 正确实现的条件，并验证结果。

这并不意味着开发者的价值降低。恰恰相反。只靠一行行输入代码来区分能力会变得越来越难，取而代之的是定义哪些结构可以被允许、哪些变更必须被阻止、用什么标准判断质量的能力。

也就是说，未来“能设计系统让 AI 正确写代码的人”可能会和“代码写得好的人”一样强。

Harness Engineering 的核心要素

Harness engineering 听起来可能很抽象，但实际上由相当具体的组成部分构成。

1. 明确的约束条件

AI 获得的自由度越高，越容易给出奇怪的结果。因此必须明确规定使用哪个框架、只能修改哪些文件、遵循哪种编码风格，以及绝对不能触碰什么。

例如，在前端项目中可以设置这样的约束：

• 保持 Next.js App Router 结构
• 只能修改 components/landing 内部文件
• 禁止添加现有 design token 之外的颜色
• 禁止使用 any 类型
• 只使用 mock data，不调用 API

这些约束不是削弱 AI 的创造力，而是提高实际工作所需要的准确性。

2. 自动验证管线

如果想确认 AI 生成的结果是否真的可用，验证是必不可少的。只靠肉眼读一遍远远不够。至少需要连接以下验证流程：

• 类型检查
• lint 检查
• 单元测试
• 构建测试
• 可访问性检查
• 视觉回归测试

如果 AI 生成结果后无法通过这些验证，那么这个输出就不是“完成的代码”，而只是草稿。Harness engineering 会把这个验证流程默认纳入 AI 工作流。

3. 防止失败的保护装置

AI 有时会比预期更危险地行动。它可能修改无关文件、添加不必要的依赖，或者做出会动摇整体结构的变更。因此必须有安全装置。

例如：

• 限制可修改的文件数量
• 禁止修改特定目录之外的内容
• 阻止包安装命令
• 限制访问环境变量文件
• 自动阻止大规模重构

核心是不完全信任 AI。即使模型能力变强，也不能给予无限权限。

4. 反馈循环设计

要提高 AI 输出质量，需要记录并反映哪些结果被接受、哪些结果被拒绝。把人类修正过的模式、经常出现的错误、反复被拒绝的风格收集起来，工作环境就会逐渐变得更好。

这正是它与简单 prompt engineering 的不同之处。Prompt engineering 关注的是当下如何说得更好；harness engineering 关注的是让整个系统持续产出更好的结果。

5. 任务拆分与角色分离

如果让一个 AI 负责所有事情，结果可能会不稳定。因此，如何拆分工作也很重要。例如可以这样分配角色：

• 需求解释 agent
• 实现 agent
• review agent
• 测试修正 agent

这样分离后，每个阶段的责任更清晰，也更有可能及早发现错误。

用前端开发来理解的例子

从前端实务角度看，两者差异会更明显。

Vibe coding 更像这样的请求：

“帮我做一个有感性氛围的 landing page。”

而 harness engineering 更像这样：

“基于 Next.js 工作，保持 app router 结构，只能修改 components/marketing 目录中的文件。颜色只能使用现有 design token，响应式要从 360px 开始支持。不能有 type error 和 eslint error，也不要添加可能影响 Lighthouse 性能分数的重型库。”

两者都是让 AI 工作，但后者更符合实际项目，也更容易复现。

它和 Prompt Engineering 有什么不同？

有些人会把 harness engineering 看成 prompt engineering 的扩展版。但两者的关注点不同。

Prompt engineering 主要关注“怎样请求才能得到更好的回答”。Harness engineering 关注的是“AI 在什么环境、什么规则、什么验证流程下才能产出可信赖的结果”。

也就是说，前者更接近表达技巧，后者更接近系统设计。

为什么这个概念重要

AI 编码工具会持续发展。问题在于，能力越强，人们越容易过度信任它。结果乍看可能做得不错，但实际上可能提高维护成本，并让质量变得不稳定。

所以未来重要的问题不是“AI 写代码有多好”，而是“即使 AI 出错，我们是否有能安全控制它的结构”。这就是 harness engineering 重要的原因。

这个概念不太可能只是 AI 时代的流行语。它更像是开发组织在把 AI 引入真实生产环境时必然要面对的现实运营问题。

结语

Vibe coding 很快，也很有吸引力。但在实际工作中，稳定性往往比速度更重要。而这种稳定性并不主要来自 AI 模型本身，而是来自我们如何控制和验证这个 AI。

Harness engineering 处理的正是这一部分。它不是把工作交给 AI 就结束，而是设计 AI 的工作方式。未来，开发者可能不再只是“生产代码的人”，而会更常被评价为“能让 AI 以可信方式生产代码的人”。

最终，vibe coding 的下一步也许不是更好的 prompt，而是更好的 harness。

AI でコードを作ることは、もはや珍しくない。多くの開発者は、自然言語で要件を伝え、それに合わせて AI がコードを生成する流れに慣れつつある。このようなやり方はよく「バイブコーディング」と呼ばれる。アイデアを素早く形にし、草案を作り、反復作業を減らすうえでは確かに強力だ。

しかし実際のプロジェクトに入ると、限界はすぐに見えてくる。AI が作ったコードは一見それらしく見えても、構造が不安定だったり、既存のルールに反していたり、テストを通らなかったり、想定外の領域まで触ってしまうことがある。結局重要なのは、AI がコードを書けるかどうかそのものではなく、その AI がどれだけ制御された環境の中で安定して働けるかだ。

ここで登場する概念が、ハーネスエンジニアリングである。

なぜバイブコーディングだけでは足りなくなるのか

バイブコーディングの核心はスピードだ。開発者が細かい実装を一つひとつ書く代わりに、意図や雰囲気、望む結果を説明すると、AI が素早くコードを作る。プロトタイプを作ったり、アイデアを試したりするときには非常に効率的である。

問題は、実際のサービス開発ではスピードだけでは十分ではないことだ。プロジェクトにはすでに決まったフォルダ構造があり、デザイントークンがあり、チームのルールやコードスタイルがあり、ビルドとテストを通過しなければならず、性能、アクセシビリティ、保守性まで考慮する必要がある。ところがバイブコーディングは、こうした現実的な制約を無視して「それらしい結果」だけを作ることがある。

つまり、バイブコーディングは始めることを簡単にするが、信頼できる結果を繰り返し出すには不十分な場合がある。

ハーネスエンジニアリングとは何か

ハーネスエンジニアリングとは、AI がコードを生成する過程をただ見守るのではなく、その AI がどのような環境で、どのようなルールの下で、どのような方法で動くべきかを設計するアプローチである。

簡単に言えば、バイブコーディングが「AI に作ってほしいと頼むこと」なら、ハーネスエンジニアリングは「AI が勝手に壊さないように作業のレールを敷くこと」に近い。

ここでいうハーネスは、単一のツールを意味しない。むしろ次のような要素全体を含む作業システムに近い。

• どこまで変更できるかを決める範囲
• どのルールに従うべきかを決める制約
• 結果が正しいかを確認する検証手順
• 誤った出力を取り除く保護装置
• 失敗と修正履歴を反映するフィードバック構造

結局、ハーネスエンジニアリングは AI をうまく使う技術というより、AI が信頼できる形で働くための運用環境を設計するエンジニアリングだと言える。

なぜ開発者の役割が変わるのか

AI が多くのコードを直接書き始めると、開発者の役割も変わる。以前は人が実装の大部分を直接担当していたが、これからは AI が正しく実装できる条件を設計し、結果を検証する側に重心が移っていく。

これは開発者の価値が下がるという意味ではない。むしろ逆である。コードを一行ずつ入力する能力だけでは差別化が難しくなり、代わりにどの構造を許容するのか、どの変更を防ぐべきか、どの基準で品質を判断するのかを定義する能力がより重要になる。

つまり今後は、「コードをうまく書ける人」と同じくらい、「AI が正しくコードを書けるようにシステムを設計する人」が強くなる可能性が高い。

ハーネスエンジニアリングの主要要素

ハーネスエンジニアリングは抽象的な概念に聞こえるかもしれないが、実際にはかなり具体的な構成要素から成り立っている。

1. 明確な制約条件の設定

AI は自由度を大きく与えるほど、予想外の結果を出しやすい。そのため、どのフレームワークを使うのか、どのファイルだけを変更できるのか、どのコーディングスタイルに従うべきか、何を絶対に触ってはいけないのかを明確に決める必要がある。

たとえばフロントエンドプロジェクトなら、次のような制約を置ける。

• Next.js App Router 構造を維持する
• components/landing 内のファイルだけを変更できる
• 既存の design token 以外の色を追加しない
• any 型を使わない
• API 呼び出しの代わりに mock data だけを使う

こうした制約は AI の創造性を削るものではなく、実務で必要な正確性を高める役割を持つ。

2. 自動検証パイプライン

AI が作った結果が本当に使えるものかを確認するには、検証が不可欠だ。一度目で読むだけでは足りない。少なくとも次のような検証手順が接続されている必要がある。

• 型チェック
• lint チェック
• 単体テスト
• ビルドテスト
• アクセシビリティチェック
• ビジュアルリグレッションテスト

AI が結果を生成したあとでこの検証を通過できなければ、その出力は「完成したコード」ではなく単なる草案にすぎない。ハーネスエンジニアリングは、この検証手順を AI ワークフローに標準で含めるアプローチである。

3. 失敗を防ぐ保護装置

AI は時として、想像以上に危険な動きをする。関係のないファイルを変更したり、不要な依存関係を追加したり、構造全体を揺るがす変更を作ることがある。そのため必ず安全装置が必要になる。

たとえば次のようなものだ。

• 変更可能なファイル数を制限する
• 特定ディレクトリ外の変更を禁止する
• パッケージインストールコマンドをブロックする
• 環境変数ファイルへのアクセスを制限する
• 大規模リファクタリングを自動的にブロックする

重要なのは、AI を全面的には信頼しないことだ。性能が上がったからといって、無制限の権限を与えてはいけない。

4. フィードバックループの設計

AI の出力品質を高めるには、どの結果が承認され、どの結果が拒否されたのかを記録し、反映する必要がある。人が修正したパターン、頻繁に起きるミス、繰り返し拒否されるスタイルを集めれば、作業環境は徐々に改善される。

ここが単純なプロンプトエンジニアリングとの違いである。プロンプトエンジニアリングは、その場でよりうまく伝えることに集中する。一方、ハーネスエンジニアリングは、システム全体が時間とともにより良い結果を出すことに焦点を置く。

5. 作業分解と役割分離

一つの AI にすべてを任せると、結果が不安定になることがある。そのため、作業の分け方も重要だ。たとえば次のように役割を分けられる。

• 要件解釈エージェント
• 実装エージェント
• レビューエージェント
• テスト補正エージェント

このように分離すると、各段階の責任が明確になり、早い段階でエラーを検出できる可能性が高くなる。

フロントエンド開発で考えるとわかりやすい例

フロントエンド実務の観点で見ると、違いはよりはっきりする。

バイブコーディングは次のような依頼に近い。

「感性的な雰囲気のランディングページを一つ作って。」

一方、ハーネスエンジニアリングは次のような形になる。

「Next.js ベースで作業し、app ルーター構造は維持し、components/marketing ディレクトリ内だけを変更して。色は既存のデザイントークンだけを使い、レスポンシブは 360px から対応して。型エラーと eslint エラーはなくし、Lighthouse のパフォーマンススコアに影響する重いライブラリは追加しないで。」

どちらも AI に作業を依頼しているが、後者の方がはるかに実務的で再現性が高い。

プロンプトエンジニアリングと何が違うのか

ハーネスエンジニアリングを、単なるプロンプトエンジニアリングの拡張版だと見る場合がある。しかし両者は焦点が異なる。

プロンプトエンジニアリングは主に「どう依頼すればより良い答えが得られるか」に集中する。一方、ハーネスエンジニアリングは「AI がどの環境で、どのルールの下で、どの検証を経れば信頼できる結果を出せるか」を扱う。

つまり前者は文章技術に近く、後者はシステム設計に近い。

この概念が重要な理由

AI コーディングツールは進化し続けている。問題は、性能が上がるほど、かえって過信しやすくなることだ。一見うまく作られているように見えても、実際には保守コストが増え、品質が揺らぐ結果になることがある。

だから今後重要なのは、「AI がどれだけコードをうまく書くか」ではなく、「AI が失敗しても安全に制御できる構造があるか」だ。これがハーネスエンジニアリングが重要な理由である。

この概念は、AI 時代の流行語で終わる可能性は低い。むしろ開発組織が AI を実際の本番環境に導入するとき、必ず向き合うことになる現実的な運用課題を説明する言葉に近い。

まとめ

バイブコーディングは速く、魅力的だ。しかし実務では、速度より安定性が重要になる場面が多い。そしてその安定性は、AI モデルそのものよりも、その AI をどう制御し、どう検証するかから生まれる。

ハーネスエンジニアリングはまさにその部分を扱う。AI に仕事を任せるだけで終わるのではなく、AI が働く方法そのものを設計することだ。これから開発者は、単にコードを生産する人ではなく、AI が信頼できる形でコードを生産できるシステムを作る人として評価される場面が増えるだろう。

結局、バイブコーディングの次の段階は、より良いプロンプトではなく、より良いハーネスなのかもしれない。

Crear código con IA ya no resulta extraño. Muchos desarrolladores se han acostumbrado a expresar requisitos en lenguaje natural y dejar que la IA genere código a partir de ellos. Este flujo suele llamarse “vibe coding”. Es claramente potente para convertir ideas en algo tangible, generar borradores y reducir trabajo repetitivo.

Pero al entrar en un proyecto real, los límites aparecen rápidamente. El código generado por IA puede parecer convincente a primera vista, pero tener una estructura inestable, violar reglas existentes, no pasar los tests o tocar áreas que no debía tocar. Al final, lo importante no es solo que la IA pueda escribir código, sino que pueda trabajar de forma estable dentro de un entorno controlado.

Aquí aparece el concepto de ingeniería de harness.

Por qué el Vibe Coding se Vuelve Insuficiente

El núcleo del vibe coding es la velocidad. En lugar de escribir cada detalle de implementación a mano, el desarrollador describe la intención, el tono y el resultado deseado, y la IA crea código rápidamente. Para prototipos o experimentos de ideas, es muy eficiente.

El problema es que el desarrollo de productos reales no puede sostenerse solo con velocidad. Un proyecto ya tiene una estructura de carpetas, design tokens, reglas de equipo, estilo de código, requisitos de build y tests, además de rendimiento, accesibilidad y mantenibilidad. El vibe coding a menudo ignora esas restricciones prácticas y produce solo un “resultado que parece correcto”.

En otras palabras, el vibe coding facilita empezar, pero puede no ser suficiente para producir resultados confiables de forma repetida.

Qué es la Ingeniería de Harness

La ingeniería de harness es un enfoque en el que no solo observas cómo la IA genera código. En cambio, diseñas el entorno, las reglas y las condiciones operativas bajo las cuales la IA debe trabajar.

Dicho de forma simple, si el vibe coding es “pedirle a la IA que construya algo”, la ingeniería de harness se parece más a “poner rieles para que la IA no pueda romper cosas libremente”.

Aquí, harness no significa una única herramienta. Se parece más a un sistema completo de trabajo que incluye elementos como:

• El alcance que define qué puede modificarse
• Las restricciones que definen qué reglas deben seguirse
• El proceso de validación que comprueba si el resultado es correcto
• Las protecciones que filtran salidas incorrectas
• La estructura de feedback que refleja fallos e historial de revisiones

En definitiva, la ingeniería de harness no trata tanto de usar bien la IA, sino de diseñar un entorno operativo donde la IA pueda trabajar de forma confiable.

Por qué Está Cambiando el Rol del Desarrollador

Cuando la IA empieza a escribir mucho código directamente, el rol del desarrollador también cambia. Antes, las personas se encargaban de la mayor parte de la implementación. Ahora el peso se desplaza hacia diseñar las condiciones para que la IA implemente correctamente y verificar el resultado.

Esto no significa que el valor del desarrollador disminuya. Es lo contrario. La capacidad de escribir código línea por línea se vuelve menos diferenciadora, mientras que gana importancia la capacidad de definir qué estructuras se permiten, qué cambios deben bloquearse y con qué criterios se juzga la calidad.

Es decir, en el futuro puede ser tan fuerte “quien diseña el sistema para que la IA escriba código correctamente” como “quien escribe buen código”.

Elementos Clave de la Ingeniería de Harness

La ingeniería de harness puede sonar abstracta, pero en la práctica está compuesta por elementos muy concretos.

1. Definir Restricciones Claras

Cuanta más libertad recibe la IA, más fácil es que produzca resultados extraños. Por eso hay que definir con claridad qué framework usar, qué archivos puede modificar, qué estilo de código debe seguir y qué no debe tocar nunca.

Por ejemplo, en un proyecto frontend podrías establecer restricciones como estas:

• Mantener la estructura de Next.js App Router
• Modificar solo archivos dentro de components/landing
• No añadir colores fuera de los design tokens existentes
• No usar el tipo any
• Usar solo mock data en lugar de llamadas API

Estas restricciones no reducen la creatividad de la IA. Aumentan la precisión necesaria para el trabajo real.

2. Pipeline de Validación Automatizada

La validación es esencial para saber si un resultado generado por IA es realmente utilizable. Leer el código una vez no basta. Como mínimo, el flujo debería conectar comprobaciones como:

• Type checking
• Linting
• Tests unitarios
• Tests de build
• Comprobaciones de accesibilidad
• Tests de regresión visual

Si la IA genera un resultado pero no puede pasar estas comprobaciones, la salida no es “código terminado”. Es solo un borrador. La ingeniería de harness convierte este proceso de validación en una parte básica del flujo de trabajo con IA.

3. Protecciones contra Fallos

La IA a veces se comporta de formas mucho más arriesgadas de lo esperado. Puede modificar archivos no relacionados, añadir dependencias innecesarias o crear cambios que alteren toda la estructura. Por eso hacen falta protecciones.

Por ejemplo:

• Limitar el número de archivos modificables
• Bloquear cambios fuera de directorios específicos
• Bloquear comandos de instalación de paquetes
• Restringir el acceso a archivos de variables de entorno
• Bloquear automáticamente refactors de gran escala

La clave es no confiar completamente en la IA. Aunque el modelo mejore, no debería recibir autoridad ilimitada.

4. Diseño del Bucle de Feedback

Para mejorar la calidad de las salidas de IA, hay que registrar y reflejar qué resultados fueron aprobados y cuáles fueron rechazados. Si recopilas los patrones que las personas corrigieron, los errores frecuentes y los estilos que se rechazan una y otra vez, puedes construir un mejor entorno de trabajo con el tiempo.

Aquí es donde se diferencia de la simple ingeniería de prompts. La ingeniería de prompts se enfoca en expresarse mejor en el momento. La ingeniería de harness se enfoca en hacer que todo el sistema produzca mejores resultados con el tiempo.

5. Descomposición del Trabajo y Separación de Roles

Si le pides a una sola IA que haga todo, el resultado puede volverse inestable. También importa cómo se divide el trabajo. Por ejemplo, los roles pueden separarse así:

• Agente de interpretación de requisitos
• Agente de implementación
• Agente de revisión
• Agente de corrección de tests

Esta separación aclara la responsabilidad de cada etapa y aumenta la posibilidad de detectar errores temprano.

Un Ejemplo Fácil de Entender en Desarrollo Frontend

Desde la práctica frontend, la diferencia se vuelve más clara.

El vibe coding suena como este tipo de solicitud:

“Hazme una landing page con una sensación emocional.”

La ingeniería de harness suena más así:

“Trabaja sobre Next.js, conserva la estructura del router app y modifica solo archivos dentro de components/marketing. Usa únicamente los design tokens existentes para colores, soporta responsive desde 360px, no dejes errores de tipos ni de eslint, y no añadas librerías pesadas que puedan afectar la puntuación de rendimiento de Lighthouse.”

Ambos enfoques piden trabajo a la IA, pero el segundo es mucho más práctico y reproducible.

En qué se Diferencia de la Ingeniería de Prompts

Algunas personas ven la ingeniería de harness como una simple extensión de la ingeniería de prompts. Pero el foco es diferente.

La ingeniería de prompts se pregunta principalmente: “¿Cómo debo pedir algo para obtener una mejor respuesta?” La ingeniería de harness pregunta: “¿En qué entorno, bajo qué reglas y mediante qué proceso de validación puede la IA producir un resultado confiable?”

La primera se parece más a una técnica de escritura. La segunda se parece más al diseño de sistemas.

Por qué Importa Este Concepto

Las herramientas de programación con IA siguen mejorando. El problema es que, cuanto mejores se vuelven, más fácil es confiar demasiado en ellas. Un resultado puede parecer bien hecho al principio, pero después aumentar el coste de mantenimiento o debilitar la calidad.

Por eso la pregunta importante está pasando de “¿qué tan bien puede escribir código la IA?” a “¿tenemos una estructura que pueda controlar la IA de forma segura incluso cuando se equivoca?”. Esa es la razón por la que importa la ingeniería de harness.

Es poco probable que este concepto se quede solo como una palabra de moda de la era de la IA. Se parece más a un problema operativo práctico que las organizaciones de desarrollo tendrán que enfrentar al introducir IA en flujos reales de producción.

Cierre

El vibe coding es rápido y atractivo. Pero en el trabajo real, la estabilidad suele importar más que la velocidad. Y esa estabilidad viene menos del modelo de IA en sí y más de cómo controlamos y validamos esa IA.

La ingeniería de harness trata exactamente esa parte. No se queda en asignar trabajo a la IA; diseña cómo trabaja la IA. En adelante, los desarrolladores pueden ser evaluados menos como personas que simplemente producen código y más como personas que construyen sistemas para que la IA produzca código de forma confiable.

Al final, el siguiente paso después del vibe coding quizá no sea un mejor prompt, sino un mejor harness.