AI Doesn’t Replace Engineers. It Multiplies Them: Inside Our Biweekly Hackathon

I spent a few hours sitting in on our biweekly hackathon, watching our engineers build an app using Claude Code and Codex under the guidance of our Head of AI, Nathan. It was one of the more eye-opening sessions I’ve seen in a while.

What stood out immediately was how much the AI depended on the team for course correction. The tools produced strong options quickly, but Nathan and the engineers were constantly making judgment calls, choosing between paths, validating assumptions, and steering toward what the end user actually needs. A wrong decision early on could easily send the build in the wrong direction. And beyond that, they were making nuanced choices about which LLM to use for which task, based on the strengths (and limitations) of each model.

The team was happy to hand off the mechanical work, syntax, scaffolding, repetitive generation. But the strategic work stayed firmly in their hands, designing the right solution, shaping the workflow, and ensuring the end product met specific goals. Today’s models can accelerate the journey, but they still need an expert at the wheel to reach the finish line.

A good example is NexaClaw, our enterprise implementation of an “OpenClaw”. In an enterprise environment, it can’t just work, it has to be secure, compliant, and observable. Client data can’t leave their walls. It needs to be deployable across multiple clients using idempotent principles, while staying flexible enough to support any cloud provider or LLM a client prefers. Out of the box, AI doesn’t understand those constraints. The team had to actively direct the models, translating enterprise requirements into concrete architecture and implementation decisions.

That’s why the popular narrative that AI is coming for software engineering jobs misses the point. Expert engineers are still essential. If anything, they’ve just become dramatically more capable.

AI is absolutely disruptive to software development, but not in the way the headlines suggest. The advantage will go to teams who know how to work with these tools, how to evaluate outputs, apply constraints, and turn raw speed into reliable, production-ready systems. Yes, more people without traditional engineering backgrounds will build real software. But the best work will still come from strong engineers who can pair deep expertise with AI acceleration.

In fact, during this hackathon, a small team built in hours what used to take a much larger team weeks, sometimes months. Not because AI was “doing the job,” but because the combination of engineering judgment and AI tooling compressed the mechanical effort and amplified the strategic work. It’s one of the clearest signs I’ve seen that the idea of the 10x engineer is becoming real, powered less by heroics, and more by leverage.