The best code didn't win: what the Dev-to-Dev hackathon final says about agentive engineering

At the finale of Dev-to-Dev: Agentic Engineering Challenge, the project with the best code came in second place. 65 unit tests, complete type safety, protection against path traversal, Docker with non-root user—an architecture that bears the mark of a serious engineer. And that's precisely why it didn't win.

When code quality doesn't save

The second-place project was something you rarely see at hackathons: a clean codebase, test coverage, security that had to be found in the details. The author of this solution didn't just write code; they wrote code that could be sent to production tomorrow. But the hackathon was measuring something else. The organizers were measuring agentic engineering—the very essence that this high-quality project simply lacked. The winning solution understood most accurately what they were looking for.

Agentic engineering is another language

Agentic engineering is a young term (barely a couple of years old), and each team brings their own interpretation to it. But this year's finale made it clear: agentic systems require different priorities. Instead of clean code—the ability to adapt on the fly. Instead of complete test coverage—readiness to work with incomplete information. Instead of perfect architecture—iteration and learning from mistakes. It turned out that:

• Interactivity and responsiveness matter more than internal architecture
• Ability to adapt matters more than comprehensive type safety
• Fast iterations matter more than complete test coverage
• Working with uncertainty matters more than type guarantees

A split in engineering

Placing the best code in second place isn't a judging error. It's a signal of a deep split in how we think about code. Classical engineering: types, tests, documentation, architecture held in check by 65 tests and conforming to all best practices. Agentic engineering: fast hypothesis, integration with the outside world, readiness to fail and learn, ability to think under conditions of uncertainty. It's not just about code. It's about two different worldviews on what good software is.

What this means

For a developer it means: thinking changes. The skills of classical engineering remain valuable, but the agentic paradigm requires a completely different approach to design. A global split in how we write systems is not far off.