Back to Devoured - September 28, 2026
DEVOURED
Human-AI partnerships are for alignment, not capability

Human-AI partnerships are for alignment, not capability

Tech Sean Goedecke
Engineers remain relevant because current coding agents lack the context to align software with organizational values, not because they struggle to write valid code.
What: Sean Goedecke argues that human-AI partnerships in software development succeed when humans act as 'aligners' rather than code generators. While models efficiently produce bug-free, compilable code, they frequently fail to meet non-functional requirements, architectural standards, or strategic business goals.
Why it matters: This challenges the 'centaur' metaphor from chess, suggesting that human value in coding is shifting away from technical execution toward editorial judgment and system-level alignment.
Deep dive
  • Modern LLMs are highly capable of writing syntactically correct and efficient code, effectively surpassing human speed and error rates in pure generation.
  • AI models often exhibit 'misalignment' by producing verbose comments, unnecessary unit tests, or over-engineered patterns that don't fit specific organizational preferences.
  • The primary role of a human developer is evolving into an 'aligner' who curates code to fit the long-term technical strategy and system values of an organization.
  • Alignment is context-dependent and varies significantly between companies, making it harder to train models that inherently understand organizational nuance.
  • 'Vibe-coding'—relying purely on AI output—risks producing code that lacks taste or maintainability.
  • Human developers are best suited for handling tasks where technical requirements are complex or outside the training distribution of the model.
Decoder
  • Vibe-coding: A colloquial term for relying heavily on AI models to generate entire codebases or features with minimal human intervention, focusing on the result rather than the implementation details.
  • Centaur: A term originating in chess denoting a human-AI team that performs better than either a human alone or an AI alone.
  • RL grader: A component in Reinforcement Learning from Human Feedback (RLHF) that evaluates model outputs to guide training, often leading models to adopt specific patterns of verbosity or structure.
Original article

It’s common to compare the current AI takeover of software engineering to the rise of AI in chess. Chess AIs went from much weaker than serious players to much stronger than even the strongest humans. Between those points, there was a middle period dominated by “centaurs”: human-AI partnerships that were stronger than unassisted AIs or humans. Lots of people think that we’re currently in a world of software engineering centaurs. According to them, coding AIs are not yet capable enough to replace engineers, but AI-assisted engineers are better at programming than both AIs and humans.

This is partialy correct, but the wrong way to think about it. AI-assisted engineers are better, but unlike with chess centaurs, they’re not actually better at programming. When I ask agents to write code, they make fewer mistakes than I do and are orders of magnitude faster. The code that they write always compiles, rarely has race conditions or other concurrency errors, works on mobile browsers, and so on.

That doesn’t mean I can leave the AI alone. Purely vibe-coding at work produces awful outputs. But they’re not awful because they’re bad code, they’re awful because they’re in bad taste: code that is not maintainable, that trades off important requirements in order to satisfy made-up ones, that contradicts the long-term strategy for a feature or service, and so on.

In other words, my primary value is not that I help the AI write better code, it’s that I align the AI with the values of my organization. Human-AI partnerships are for alignment, not capability.

Frontier models are misaligned to the working programmer. They are obsessed with a set of behaviors that presumably satisfy their RL grader: writing enormous block comments above functions, producing hundreds of useless unit tests, adding little bits of text all over websites they design, and so on. Working with agents is about noticing and wrestling with those behaviors. That’s why my prompting advice is to explicitly talk about your high-level values: it’s an attempt to head off obvious misalignment.

This is great news for software engineers. It’s well-understood how to train more capable models: bigger models, more and better data, better RL environments, and so on. However, it’s not well-understood how to align models better. There are plenty of very capable models that exhibit behavior that is badly misaligned with human values. Indeed, it’s one of the main pillars of the AI doomer position that alignment is much harder to solve than capability, and we might thus end up with dangerous super-capable but poorly-aligned AI models.

Alignment is also more context-dependent than capability. Working code is working code, no matter what (which is partially why it’s comparatively easy to train for). But aligning to a company’s technical values is different from company to company, as any software engineer who’s switched companies knows. It can almost feel like relearning the job. So training an aligned coding model doesn’t just require hitting the exact right set of values, it requires creating a model that can adapt on the fly to a wide range of possible values.

Vibecoding maximalists like DHH argue that AI models are (or soon will be) so much more capable than human programmers that we ought to stop reading the code. Eventually there will be no such thing as programmers at all. If it were just about capability, they might be right. But — fortunately for software engineers — good code also has to be aligned to the technical values of the system and organization it’s embedded in. AI models are great at writing code, but not very good at doing that, and it’s unclear that they’re going to get good at it anytime soon. We might all keep our jobs for a little while yet.

  1. For instance, I can’t remember the last time I’ve seen an agent make an off-by-one error. I do occasionally catch a pure programming error, typically in areas where I have a lot of technical domain knowledge. If you’re working out of distribution I suspect it’s easier to beat the models.
  2. It’s still going to be rough for junior engineers.
Explore all 67 articles in today's digest

Fresh dev news, AI-digested daily. Never miss a trend at devoured.fyi