The Essence of AI Alignment: Aligning What to Do, Not How to Do It

In the process of AI engineering implementation, "AI-human alignment" is a frequently mentioned yet often misunderstood concept. In academia, AI Alignment typically refers to ensuring that AI systems' behavior remains consistent with human values, intentions, and goals—a key AI safety research direction heavily invested in by OpenAI, Anthropic, DeepMind, and others, primarily focused on existential risks from superintelligence. In engineering practice, however, "alignment" takes on a more concrete meaning—it's not philosophical value alignment, but workflow-level intent alignment: how to make AI accurately understand developers' requirements and execute them correctly. RLHF (Reinforcement Learning from Human Feedback) solves general alignment at the model level, while what we need to solve in engineering is project-specific alignment.

Many developers, when using AI-assisted programming, habitually tell AI every single step of how to do things—from variable naming to loop structures, practically writing pseudocode and asking AI to translate. The result? Efficiency doesn't improve, but rework piles up round after round.

Where's the problem? The direction of alignment is backwards.

What exactly does AI need to align with humans on? This article starts from a real database migration case to explore the core principle of AI alignment—aligning What to do, not How to do.

Understanding AI Alignment Boundaries Through Database Migration

Let's take Alembic, a common database migration framework in the Python ecosystem, as an example. Alembic is a database migration tool in the SQLAlchemy ecosystem, developed by SQLAlchemy's author Mike Bayer. Its core philosophy is managing database schema changes (such as creating tables, adding fields, modifying indexes) as versioned migration scripts—similar to how Git manages code versions. Similar implementations exist in Django's Migrations and Rails' ActiveRecord Migration, and this pattern has become standard practice in modern web development. Alembic provides two core operations—upgrade and downgrade—for managing database version progression and rollback. Each migration script contains these two functions, ensuring database changes are traceable and reversible, and typically integrates with CI/CD pipelines for automated deployment of database changes.

When we perform table creation, examining this process through a "Barbell Strategy" lens reveals that the two ends of the barbell are business scenarios and table structure. The "Barbell Strategy" was originally proposed by risk scholar Nassim Taleb in Antifragile, describing an investment approach of simultaneously holding extremely conservative and extremely aggressive assets while avoiding the middle ground. In the AI engineering context, it's borrowed as an analytical framework: focusing on the two extremes of a problem—one end being the highly deterministic, standardizable parts (like a framework's fixed usage patterns), and the other being the highly uncertain parts requiring human judgment (like business decisions). By identifying both ends of the barbell, developers can clearly delineate which work should be delegated to AI for automatic completion and which must be decided by humans.

Here's a key question: Do field design and table structure definitions during table creation need to be aligned with AI?

The answer is yes, because these are directly related to specific business scenarios—AI cannot infer your business requirements from thin air. What fields a user table should have, what relationships exist between order and product tables—only you know these decisions.

But what about the generation logic for Alembic's upgrade and downgrade migration scripts? The conclusion is: this part doesn't need alignment. Migration script generation is a standardized, rule-based process that AI is fully capable of completing autonomously according to established rules. You only need to tell it "create a user table with these fields"—as for how to write op.create_table() or handle op.drop_table() in downgrade, AI can handle that on its own.

This case perfectly reveals the most critical boundary delineation problem in AI alignment.

The Core Principle of AI Alignment: What to Do vs. How to Do

The database migration case above reveals the core principle of AI alignment—distinguishing between "what to do" and "how to do it."

What AI Doesn't Know Is "What to Do"

The essence of AI-human alignment is solving what AI "doesn't know." And what AI truly doesn't know is What to do—what needs to be done. Specifically:

• Scenario alignment: What your business scenario is, what problem you're solving
• Goal alignment: What the final outcome should be, such as the ultimate table structure
• Intent alignment: Why you're doing this, the underlying business logic

This information cannot be inferred by AI on its own—it must be explicitly communicated by humans. Without clearly stating what table to build, what relationships exist between tables, and what constraints fields have, even the smartest AI can only guess. This is fundamentally an information transfer efficiency problem—how to give AI sufficient information to complete the task with minimal communication cost.

What AI Excels At Is "How to Do It"

And How to do—how to execute—is precisely AI's strength. This content can be standardized as:

• SOPs (Standard Operating Procedures): Fixed execution steps, such as the migration script generation workflow. SOPs originated from quality management systems in manufacturing and healthcare industries, referring to decomposing repetitive work into clear, executable step sequences. In AI-assisted programming, SOPs are converted into structured instructions readable by AI, such as "when creating an API endpoint: define routes → write request validation → implement business logic → add error handling → write unit tests."
• Skills (Skill Modules): Reusable capability units, such as code generation templates for specific frameworks. Skills are more fine-grained capability modules, similar to the single responsibility principle in microservices architecture—each Skill encapsulates a specific capability, like "generate RESTful CRUD code" or "write Pytest test cases." SOPs define the process skeleton, Skills fill in the specific execution capabilities for each step, and together they form the core execution layer of the Harness system.
• Constraints and standards: Code style, architecture specifications, naming conventions, etc.

These standardized contents ultimately form a system called Harness (constraint framework). After reading these specifications, AI combines them with the aligned "what to do" from humans to autonomously complete the execution work.

In other words, you're responsible for deciding "what to do," Harness tells AI "by what standards to do it," and AI handles the actual work. With each party fulfilling its role, efficiency naturally improves.

Harness Engineering: The Bridge from AI Alignment to Automated Programming

What Is Harness Engineering

Harness is essentially the crystallization of all "How to do" knowledge into a structured specification system. When you formalize a large body of "how to do" into standards, these standards become engineering assets—whether enterprise-level or personal R&D assets.

Simply put, Harness engineering transforms a team's accumulated best practices, coding standards, architectural patterns, and other "how to do" experience into structured documents that AI can directly read and execute. This isn't a Wiki written for humans—it's an "operations manual" written for AI to read. This point is crucial—traditional technical documentation targets human readers and allows ambiguous expressions and implicit assumptions; Harness documentation targets AI executors and requires every specification to be sufficiently clear, unambiguous, and machine-parseable. In a sense, writing Harness documentation is closer to programming than writing.

For example: your team mandates that all database migrations must include rollback scripts, all APIs must follow RESTful conventions, and all exception handling must log structured entries—once these rules are embedded in the Harness, AI automatically complies during task execution without you repeating instructions every time.

The Core Value of Harness Engineering

Harness engineering is important because it completes the last link in fully automated AI programming. The entire logic chain works like this:

1. Humans align What to do with AI: Clarify what needs to be done
2. Harness provides How to do: Tell AI what standards to follow
3. AI executes autonomously: Combining goals and specifications to complete the work

When the Harness is sufficiently comprehensive, a feature's development can be completed entirely through automated workflows, dramatically improving the efficiency and quality of AI-assisted programming. You no longer need to scrutinize every line of AI output for code review, because the standards are already built into the process.

Evolution from Monolithic to Multi-Agent Architecture

Furthermore, when we upgrade AI automated programming from a monolithic model to a multi-agent concurrent architecture, the value of Harness is further amplified.

Multi-Agent architecture is a cutting-edge direction in AI engineering. Its core idea is decomposing a complex task into multiple subtasks, completed in parallel or collaboratively by different AI agents. Typical frameworks include Microsoft's AutoGen, CrewAI, LangGraph, and others. Each agent can have different role definitions (such as Architect Agent, Coding Agent, Testing Agent), different tool sets, and different context windows. Compared to a single large model handling all tasks, multi-agent architecture offers advantages in: reducing per-inference complexity, supporting parallel processing for speed improvements, and improving output quality through role specialization. However, the challenge lies in coordination costs between agents—how to ensure multiple Agents' outputs are stylistically consistent, interface-compatible, and conflict-free. This is precisely one of the core problems the Harness system aims to solve.

Each agent is responsible for solving one decomposed subtask, while Harness ensures every agent executes according to unified specifications. This way:

• AI's capability solves small tasks after problem decomposition
• Harness solves standardization issues
• Effective alignment ensures directional correctness

The combination of all three enables end-to-end fully automated development workflows. A requirement comes in, gets decomposed into tasks, distributed to multiple agents for parallel processing, and finally consolidated into output—throughout the entire process, humans only need to clearly state "what to do" at the beginning.

Practical Recommendations: How to Implement AI Alignment Strategy

Based on the above analysis, the following principles are recommended for actual AI engineering implementation:

1. Identify alignment boundaries: When receiving a task, first ask yourself—which parts are scenario-specific (requiring alignment), and which are process-related (to be crystallized into Harness specifications). When unsure, consider whether AI can derive this information from existing specifications—if it can be derived, no alignment is needed. A practical criterion is: if you switched to a completely different business scenario, would this information still hold? If yes, it's likely a "How" and should be crystallized into Harness; if not, it's a "What" requiring alignment each time.
2. Continuously build your Harness: Every time you discover a "How to do" pattern, standardize it and incorporate it into the Harness system. This is a gradual process—don't expect perfection overnight, but maintain the habit of accumulation. Start with the highest-frequency repetitive work—such as project initialization workflows, CRUD interface generation, unit test writing templates—these often offer the best return on investment for Harness crystallization.
3. Focus on expressing What to do: Invest your energy in how to more clearly convey intent and goals to AI, rather than hand-holding AI through code writing. The more precise your description, the higher the quality of AI's output. Good "What to do" expression should include three elements: business context (why), expected outcome (what it should look like), and acceptance criteria (how to determine it's done well).
4. Handle special cases specially: Certain technical choices (such as multi-agent orchestration approaches), while seemingly "How," directly impact architectural decisions and should be aligned as "What to do." Boundaries aren't rigid—they require flexible judgment based on actual circumstances.

Conclusion

The core of AI-human alignment lies in aligning What to do, not How to do. Crystallizing "how to do" into Harness specifications, letting AI autonomously execute according to standards after goals are clear—this is the correct path for AI engineering implementation.

As the Harness system continues to mature and multi-agent architectures evolve, the coverage of AI automated programming will keep expanding, ultimately achieving full-process automation from requirements to delivery. For every developer hoping to improve AI collaboration efficiency, learning to distinguish between "what to do" and "how to do" is the first step toward effective AI engineering.

Stop hand-holding AI through code writing. Tell it what you want, then let it get to work.