Inside Our AI Hackathon with NextEra Energy Transmission

Judging was supposed to be the easy part.

That's the quiet truth of most hackathons: by demo time, half the builds have died on the projector, and the judges mostly rank the survivors. That is not the problem our judges had. Four teams presented four working applications, and every one of them ran - clickable, coherent, defensible under questioning. Eight hours had produced a harder job than anyone planned for: choosing between things that all worked.

The room was a mix we don't see often enough. Operations and technology people from NextEra Energy Transmission shared tables with Detect engineers and analysts - four teams, one build cycle, and problem statements pulled from the everyday work of running a transmission business. Here's how the day actually went, and the five lessons we kept.

What kinds of problems did the teams take on?

Real ones. The problem statements spanned finance, compliance, project delivery, and customer experience - from the field to the boardroom, the unglamorous work that determines how fast everything else moves. Each team took one.

We won't map which team took which problem, but the shapes will be familiar to anyone in this industry: project data scattered across systems that don't talk to each other. Documents produced by hand from a shared master, drifting a little further apart with every copy. Data that exists somewhere - paid for, collected, usable - but invisible when a deadline needs it. Customer-facing processes that still run on email and patience. Four different domains, one underlying theme: the information exists; the connective tissue doesn't.

None of this is unique to any one company - it's the industry's shared homework. US electric utilities are entering what Morningstar DBRS calls an investment super-cycle: $1.4 trillion in capital spending projected for 2025 through 2030, double what the sector invested in the prior decade. Meanwhile, about 70% of US transmission lines are more than 25 years old, per the US Department of Energy. Every dollar and every aging asset in that wave generates estimates, procedures, datasets, and customer touchpoints - and the tooling around that work hasn't kept pace with its scale.

What made these right for a build day:

• Owned by experts. Each problem had people in the room who feel it weekly and could arbitrate every design decision on the spot.
• Cross-functional by nature. Each touched more than one team, so a fix had to survive both a business review and a technical one.
• Scoped to a single build cycle. Small enough to prototype in eight hours, real enough that a working version would matter the following Monday.

How do you build working software in eight hours?

By spending the first two of them not building. The day's structure mattered more than its length, so here's the anatomy of the build cycle - it's the part worth stealing.

Hours one and two: listening before building

The day opened in the main room of our office - the team calls it the Detect Den - with an on-site barista and a lot of introductions. Then, deliberately, nobody touched a keyboard.

For two hours the most advanced technology in use was a whiteboard. Teams mapped the current process end to end: where it starts, where it breaks, who feels the break, what data moves through it, and what "fixed" would have to prove. By the end of the morning each team had what amounted to an engineering brief - the problem in plain language, the constraints, and acceptance criteria for demo time.

You could hear the same themes in those criteria across every table: one source of truth. Outputs that survive upstream change. Provenance you can audit. Status you can check instead of chase.

"The first two hours were just listening and understanding," wrote Jon Krone, Project Director of Development at NextEra Energy, who spent the day on one of the builds. "That built the foundation for our coding sessions."

The build loop: guardrails, agents, iteration

None of that happened here. The teams ran a tighter loop, and the agents earned their place in it - pushing back on ambiguous requirements, asking clarifying questions, and proposing approaches nobody in the room had considered.

Step 3 is where the compression showed up first. Splitting front end from back end is ordinary engineering practice; what was different is who kept the tracks honest. "Seeing people from different business units bring their expertise into the room led to some really powerful conversations," says Kyle Ross, Detect's Director of Data Analysis. Decisions that normally wait budget cycles for a meeting slot were made at the whiteboard, in minutes, because the person who could make them was at the table.

The final stretch: scope triage under a clock

The last hour looked like every good deadline. One team stood at a whiteboard triaging its punch-list - highest-impact items first, the rest cut without ceremony - while rehearsing the demo in parallel. That's not corner-cutting; that's the discipline the deadline forces. Scope triage is a skill, and watching operations experts do it fluently on software was one of the day's quiet pleasures.

By late afternoon the demos ran, scored on clarity, execution, creativity, and usefulness. All four worked.

Five lessons from the hackathon

1. Innovation isn't gated on coding skills anymore

For most of the software era, seeing a problem and building the fix were separate jobs. AI coding agents are closing that gap, and you could watch it happen in the room.

"Innovation isn't blocked by software development skills," says Justin Lee, CTO at Detect. "It's driven by subject matter experts - the people who feel the problem most. The real constraint is how well you understand the problem and how creative you can get in solving it."

The strongest builds came from the people closest to the work: the ones who could say exactly where a process breaks, and exactly what fixed looks like.

2. Shared problems beat icebreakers

Two companies, different day jobs, most people meeting for the first time - we had braced for a slow morning of building shared context. That worry didn't survive the first problem statement. People found their footing fast, and even the most technical problem statements were picked up quickly on both sides of the table.

Or as Jon put it afterward: "Starting the day as strangers and leaving it as builders was satisfying - but not as satisfying as the friendships formed, and the potential we saw when two teams come together with dedication and grit."

3. The multiplier is humans with agents - not either alone

Put them together and the multiplier shows up: experts supply the problem understanding and the judgment, agents supply the build speed, and the iteration loop between them converges fast. It's the same hybrid logic - AI screens the volume, expert review makes the calls - that anchors our approach to utility asset management across the grid.

4. The prototype is the easy part

A working prototype is now hours away. Production is not - and pretending otherwise is how AI projects lose credibility. Between a demo that works and a system a transmission business can rely on sits the unglamorous engineering that doesn't fit in eight hours:

• security review and role-based access
• data governance and auditability
• integration with enterprise systems of record
• reliability and scale testing

An eight-hour build doesn't replace that work - it's the same bar we hold our own platform to, down to SOC 2 Type II compliance. What it does is tell you, cheaply and vividly, which ideas deserve it. Every team left with a working starting point instead of an item on an idea board - and at least one build ended the day with a credible path from prototype toward production.

5. A working demo changes the conversation

The quietest outcome may matter most. Conversations about what software could fix are usually abstract - tools, budgets, feasibility, opinion against opinion. A room full of working prototypes ends that. Both companies now hold concrete reference points for what a small, well-aimed team can stand up, and what making it real would take. That changes the next planning conversation more than any slide deck could.

Strangers to builders

The demos were the visible output. The durable result was easier to hear than to measure. "Listening to the final presentations in our mural room, you could not tell who was Detect and who was NextEra," says Matthew Sattler, Detect's CEO. "It was teams one through four."

The alignment ran the same direction - on the importance of innovation, on asking the right questions, and, in Kyle's words, on "challenging ourselves to act in the best interest of the grid." The thank-you notes afterward made the same point with less restraint; one signed off "from the bottom of our vibe coded hearts."

The grid won't be modernized by any one company. Putting the people who run transmission infrastructure in a room with the people who build software for it - and giving them eight focused hours - moves things faster than either group moves alone.

For one day, the connective tissue was the room.

Detect × NextEra Energy Transmission hackathon FAQ