Eureka! AI Turned a Corner Two days became two hours. Thirty-six hours became three.

A two-day AI deep dive only needed two hours. Two weeks later a 36-hour feature shipped in three. What I saw in the room, and why a quarter century of process thinking evaporated.

It was a typical gray, cold Chicago weekday in the office when our CEO (Alex Stepien) called for a meeting between me and him and our AI Consultant (James Francis, who has since been hired as our Chief AI Officer). The topic was pretty simple: spend two days together looking at what’s possible with AI from an engineering perspective.

Spoiler: we barely made it two hours, much less two days, before everything changed.

Let’s go back a bit so I avoid the trap of sounding like some red-pilled AI maniac.

AwardSpring was an early adopter of generative AI, but we were overly pragmatic in how we used it: creating simple marketing one-pagers, tidying up verbose emails, building simple outreach campaigns. We steered clear of image generation (for the most part) and its use was pretty limited to simple, low-stakes content generation. There was sound business logic for staying thoughtful in our adoption: we serve mostly higher ed customers, and there’s some stigma about using AI in educational settings, so we metered our usage to make sure we didn’t ruffle any feathers.

In early 2025, as models were advancing, we started to look at AI as part of the engineering process. It was all the rage at this time to see claims of 50%+ productivity gains, largely driven by code completion and early-generation feature scaffolding. Cursor was really gaining meaningful momentum, but we felt disconnected from the movement due to our codebase’s structure: a mono-repo of Angular and C#.net bifurcated into two parts, a legacy .net/MVC/AngularJS plus a modern version of it with updated Angular and C#.net libraries. There wasn’t a ton of really progressive tooling for this stack at the time, so the gains we made over 2025 were modest. We gathered benefits from some code completion and coding assistants, and our head of software engineering (Dan Rovito) launched our first iteration of a lightweight PR checker.

We saw some interesting gains in the back half of 2025, largely around design and prototyping. Tools like Lovable made it easier than ever to take an idea to a clickable spec, which was a huge win for our very small product team. Keeping up with dev capacity was always tricky on the requirements and design front, so this edge was huge. But it didn’t create a major leap forward in velocity. It just kept our product efforts in line with our engineering capacity.

In the background, it’s worth understanding that we had a really well-functioning SDLC over the back half of 2025 and heading into 2026. The team was well-balanced. Velocity and delivery were predictable. Quality was meeting our standards, staying consistent from release to release. Our sprint cycles of roughly five weeks were pretty much humming.

It’s pretty obvious to state that your world loves to get flipped upside down whenever things seem “normal” or “predictable.” Anthropic had released Opus 4.6 the week before. That release is why the meeting got called in the first place, and it turned out to be our disruptor.

You don’t typically know your worldview is about to change. If you did, it wouldn’t be changing. You’d have already formulated an opinion on it and you’d just be gathering evidence to support it (or refute it, if you’re intellectually honest). I wandered into this meeting with my usual CTO skeptic hat on: why am I doing this when I have a million other things that need my attention?

Sidebar: us CTOs are a fickle group. We literally have no chill. We should maybe collectively seek to resolve that. Perhaps my AwardSpring afterlife will be CTO group therapy.

So that meeting I mentioned. Here’s what actually happened in the room. James grabbed a repo, had Claude write its CLAUDE.md (think of it as the briefing document for the model: how this codebase works, what the conventions are, what you must never do), and then built a feature from scratch. He didn’t write a line of code. Not a stub, not a scaffold, not a single for loop. He described what he wanted, answered a few questions, reviewed what came back, and asked for changes the way you’d ask a senior engineer for changes. The model read the codebase before it touched it and contextualized his request. That’s the part I couldn’t stop staring at.

In two hours, I watched everything I knew from the prior quarter century of designing, building and running design and engineering processes entirely evaporate. I am not being overly dramatic here either. In those two hours, I saw how velocity will no longer be constrained by development capacity. Read that again. If you’ve spent even five minutes in an SDLC at scale in your life, you probably spit out whatever you were drinking when it hit you (and if it’s just hitting you as you read this, I apologize for the mess).

The models caught up with the hype in this very abbreviated two-day-turned-two-hour session. I didn’t need to see more. I needed to run at how to seize on this opportunity right now.

If you’re wondering, the cold, gray day was Wednesday, February 11th. Two weeks later, the aforementioned Dan and I were locked in a co-working space not far from his home in Ohio for two days to find out whether any of this held up on our codebase, not a demo repo. The first thing we did was write our own CLAUDE.md, the same briefing document James had built in the meeting, except this one had ten years of our conventions and landmines in it. It has been a cornerstone of how we work ever since.

Process is my thing. Part of that is a finely tuned Agile machine, every ceremony included, and the one that matters here is planning and estimation. We have a tried and true way of breaking work down in Azure DevOps: features and stories are what to build, tasks are how to build them, and every task is written and estimated by the engineer on the hook to do the work. Not by me. Not by a product manager. By the person who has to make it actually work. So we did what we always do. We picked a feature, Dan broke it into tasks and estimated them the way he would for any sprint, and the total came to 36 hours.

We delivered it in three.

One feature, two people, one afternoon. I know the difference between an anecdote and a dataset (that’s a whole other post). But I’d also never seen anything close to that ratio in my career, and I’d just watched it happen with a process I trusted doing the measuring.

That’s my Eureka! moment. Probably Dan’s too. Definitely Alex’s. And James was so excited by our response he joined the company. And now there was more work to do than ever.