Your Weekend AI Prototype Is Not a Production Strategy

We keep hearing predictions about an AI reckoning. There’ll supposedly be a reckoning in pricing as companies discover that inference isn’t free, a reckoning in valuations as investors begin separating durable businesses from thin AI wrappers, and a reckoning in staffing as organisations work out which roles have genuinely changed and which reductions were driven more by optimism than evidence.

There's another reckoning already happening inside companies.

Senior leaders are experimenting with AI in their spare time, building surprisingly capable applications in an evening or over a weekend, and returning to work with the wrong lesson. They describe what they want, iterate with the model, connect a few services, and produce something that looks remarkably close to a working product. From there, it’s easy to conclude that software development has fundamentally become that simple and that internal engineering teams should now be able to deliver production systems at the same speed.

Timelines shrink, staffing plans disappear, and individual engineers are increasingly expected to handle product management, user experience, design, architecture, development, testing, deployment, and support. In some cases, all of that responsibility is placed on one person.

After all, a leader built an app over the weekend. Why should a team need three months?

Because the two things aren’t even remotely equivalent.

A prototype proves possibility

A prototype is designed to answer a narrow question: can the idea work, can the core interaction be demonstrated, and can the concept be made tangible enough to gather useful feedback? AI has made this process faster, cheaper, and more accessible. People who previously needed engineering support to explore an idea can now build something themselves, while engineers can test alternatives without committing to weeks of implementation.

That’s genuine progress, but a prototype succeeds when it demonstrates possibility. A production system succeeds when it continues working after it encounters reality.

A weekend application rarely needs to support thousands or millions of users. It may not need authentication, authorisation, auditing, accessibility, observability, data retention, backups, rate limiting, internationalisation, incident response, or disaster recovery. It doesn’t have years of accumulated business rules, nor does it need to integrate with legacy systems owned by several other teams. It probably doesn’t have contractual service levels, regulatory obligations, established support processes, or customers depending on it to run payroll, receive medical supplies, manage financial transactions, or operate their businesses.

Most importantly, the cost of failure is usually close to zero. When a prototype breaks, its creator refreshes the page, adjusts the prompt, edits the code, or starts again. When a production system breaks, customers lose trust, employees are pulled into incident response, contractual commitments may be missed, and the company may lose money.

You can build anything quickly when there are no guardrails and failure has no consequences.

The difficult work starts after the demo

AI is extremely effective at helping someone get from nothing to something. It can generate an interface, define an initial data model, create API endpoints, assemble common components, and produce enough functionality to make an idea feel real. That first portion of the work can happen at remarkable speed.

The danger is assuming the remaining work is equally easy.

Production engineering is full of details that don’t appear in a demo. Teams still need to decide what happens when two users edit the same record, an external dependency becomes unavailable, a model returns malformed or unsafe output, or a migration fails halfway through. They need to enforce permissions across tenants, manage customer data deletion, recover from partial failures, diagnose degraded performance, prepare for unexpected scale, and ensure that someone can operate and maintain the system after the original developer leaves.

These aren’t excuses invented by engineers who are afraid of AI. They’re normal production concerns. Ignoring them doesn’t make them disappear. It merely delays when the organisation pays for them, usually at a much higher cost. And the bill always comes due.

Coding faster doesn’t eliminate product development

AI can make good engineers substantially more productive. It can accelerate research, reduce repetitive work, suggest tests, identify defects, generate scaffolding, explain unfamiliar code, and help engineers explore several implementation paths before choosing one. Engineering leaders should expect teams to adopt these tools thoughtfully and should challenge them when they refuse to engage with capabilities that could materially improve delivery.

But faster coding doesn’t eliminate the rest of product development. It doesn’t reduce the need to understand the customer, resolve ambiguous requirements, make trade-offs, validate the user experience, or align multiple teams. Nor does it remove the work required to ensure that a system is secure, maintainable, operationally sound, and appropriate for the organisation’s architecture. Writing code faster accelerates one part of the delivery process, but it doesn’t make the other parts disappear.

The idea that an engineer can now “do it all” confuses tool-assisted capability with infinite capacity. An engineer may be able to generate a passable interface without a designer, but that doesn’t mean the interface is good. They may be able to write product requirements, but that doesn’t mean the right customer problem has been identified. They may be able to generate hundreds of tests, but that doesn’t mean those tests validate the assumptions that matter.

AI can help one person perform more types of work, but it doesn’t guarantee that one person can perform every discipline well, simultaneously, under an aggressive deadline.

Unrealistic plans create predictable failures

When leadership overestimates the extent to which AI has changed, the consequences aren’t theoretical. Timelines are created without engineering input, assuming implementation is trivial. Teams are understaffed because every engineer is expected to produce several times more output. Design and testing are compressed because they’re treated as optional activities around the “real work” of generating code. Technical concerns are dismissed as resistance because the prototype appeared to work, while the risks are transferred to the people responsible for delivery even though they didn’t create the plan.

The organisation then acts surprised when quality falls, deadlines slip, employees burn out, or the system fails in practice.

In the worst environments, this becomes openly toxic. Engineers raise legitimate concerns about feasibility and are accused of being negative. Estimates become commitments before the people doing the work have been consulted, and teams are threatened with replacement if they can’t meet dates that were fabricated without any meaningful understanding of the system.

That isn’t an AI strategy; it’s management failure with an AI justification.

Healthy engineering organisations don’t remove the people closest to the work from decisions about how it’ll be delivered. Leadership has every right to set priorities, define outcomes, demand urgency, and challenge teams to find a faster path. Engineers shouldn’t be allowed to hide behind complexity, inflate estimates, or resist change simply because a new approach is uncomfortable.

But urgency isn’t the same as fantasy. Challenging a team to move faster is leadership. Inventing a deadline and threatening the team when reality doesn’t conform to it isn’t.

Engineering judgement matters more, not less

One of the more damaging ideas emerging from the current AI enthusiasm is that experience matters less because models can provide knowledge. In practice, AI makes judgement more important.

A model can generate several possible solutions, but someone still has to recognise which one fits the context. It can produce code quickly, but someone still has to determine whether that code is secure, scalable, testable, and maintainable. It can confidently recommend an approach that’s subtly (or overtly) wrong, and someone still has to detect that error before it reaches production.

The faster code can be generated, the faster bad decisions can be embedded into a system.

Experienced engineers aren’t valuable because they type faster. They’re valuable because they understand consequences. They recognise patterns, identify hidden dependencies, ask uncomfortable questions, and know where apparently simple changes tend to fail. A mature organisation needs to use AI to amplify that judgement, not to declare it obsolete.

The answer isn’t to slow down

None of this is an argument for preserving old processes simply because they’re familiar. Some engineering organisations are too slow. Some teams have accumulated ceremonies, approval layers, architectural rules, and testing practices that add little value. Some engineers use quality as a vague justification for avoiding accountability. AI should force organisations to examine how work gets done and remove steps that no longer justify their cost.

The answer isn’t to pretend nothing has changed; it's to identify precisely what has changed.

Perhaps a prototype that once took three weeks now takes two days. Perhaps a developer can complete a well-defined implementation in half the time. Perhaps test creation, documentation, migration scripts, and operational tooling can be accelerated. A smaller team may even be able to own a broader surface area because AI reduces the burden of moving between unfamiliar technologies.

Those are reasonable hypotheses, but they should be measured. Compare cycle time before and after adoption. Track defects, rework, incident rates, customer outcomes, and maintenance costs. Find the parts of the delivery process where AI creates durable improvement rather than a compelling demonstration, and then change planning assumptions based on empirical evidence.

Don’t take one leader’s weekend project and extrapolate it into an operating model for an entire engineering organisation.

What responsible AI leadership looks like

Leaders who genuinely want AI to improve delivery should ask where it’s already creating measurable leverage, which tasks have become substantially cheaper, which constraints still dominate delivery time, and what new risks it's introducing. They should identify where teams can experiment safely, distinguish customer protections from outdated process, and consider how roles should evolve without pretending that every discipline has disappeared.

They should also involve the people doing the work. Ask engineers to demonstrate how they’re using AI, where it saves time, and where it creates rework. Ask product and design teams how faster prototyping changes discovery. Ask security and operations teams which risks require new controls. Set ambitious goals, then allow the team to shape a credible plan.

Good leadership creates constructive tension between urgency and reality; it doesn’t remove reality from the conversation.

The real competitive advantage

The companies that benefit most from AI won’t be the ones that conclude software engineering has become trivial. They’ll be the ones that learn where AI genuinely compresses work and where complexity remains stubbornly human. They’ll distinguish prototype speed from production readiness, expect more from their engineers, and continue to respect engineering judgement.

They’ll use AI to improve talent rather than justify impossible staffing models. They’ll shorten feedback loops without abandoning quality. They’ll move faster because their systems and teams are better, not because leadership has declared that every difficult problem should now take a weekend.

Unfortunately, if you’re at the wrong end of this chain and leadership has stopped listening, there may not be a clever solution. You can present evidence, explain the difference between a prototype and a production system, offer alternatives, identify trade-offs, and propose a narrower path that delivers value sooner.

But if speaking honestly is treated as insubordination, fabricated deadlines are enforced through threats, and leadership has decided that professional judgement no longer matters, leaving for a better company may be the most rational choice.

And yes, I use the word “better” deliberately. There are few faster ways to lose capable people than to tell them, directly or indirectly, that their experience, judgement, and voice no longer matter.

AI may be changing how software is built; it hasn’t changed the fact that people do their best work when leadership respects reality.

What I Learned From My Engineering Management Job Search

I was recently asked to talk about my job hunting process.

The tactical version is easy enough to explain. I did not apply to every job under the sun. When possible, I applied directly through a company's career site rather than relying on LinkedIn. When companies asked additional screening questions, I treated those answers seriously, saved the strongest versions, and reused the parts that applied across future applications.

Those things helped, but they were not the biggest unlock.

The biggest unlock was narrative clarity. I had the experience. I had the scope. I had the stories. What I did not have, at least not clearly enough at the start, was a concise way to explain the shape of my career and the kind of engineering leader I had become. Once I started thinking about my career as a sequence of increasingly impactful progressions, everything changed.

This did not make the job search effortless, and I do not want to pretend there is a universal formula for a difficult market. Timing, network, company needs, and plain luck all play a role.

But the shift in narrative clarity changed the quality of the process. It helped me get out of the resume submission black hole, move into more meaningful conversations, and eventually evaluate more than one strong opportunity.

Turning a Career Path Into a Coherent Story

My career has not been a perfectly linear move from individual contributor to manager. I spent many years as a software engineer, moved into engineering management, briefly returned to individual contributor work after meeting the objectives of my team's charter, and then moved back into management with a clearer understanding of the kind of leader I wanted to be.

On paper, that path looked a little unusual. In conversation, it became one of the more useful parts of my story.

The IC years gave me technical depth. The first management chapter taught me how leadership is different from individual execution. The return to IC work gave me perspective, even though I initially struggled with it because I felt my leadership journey was still in its early stages. When I moved back into management, I did so with more maturity, more clarity, and less ego.

That path helped me explain something important about how I lead now. I am technically proficient enough to understand the work, but I do not see management hovering over implementation details. I use that technical depth to understand trade-offs, ask better questions, coach effectively, and create the conditions for teams to execute well.

The Story was the Product, not the Resume

One of the biggest shifts in my search was moving away from a resume full of responsibilities and towards a clearer leadership model. I started describing my work less as “managed a team” and more as building the operating systems around the team: how we hire, manage performance, deliver work, and create the conditions for consistent execution.

That language gave recruiters and hiring managers a clearer way to understand what I actually do. It also helped me avoid sounding like every other engineering manager's resume. Most engineering leadership resumes include themes such as: led a team, delivered projects, partnered cross-functionally, improved processes, and mentored engineers. While those things may all be true, they are not always memorable.

The more useful question became: what changed because I was there? That forced me to sharpen the stories behind the resume bullets and connect them to real operating impact.

The Two-Minute Narrative Mattered

I also developed a short version of my story to use early in recruiter and hiring manager conversations. The goal was not to recite my resume. It was to give people a fast, coherent mental model for my career.

I talked about my journey from software engineer to engineering manager, the lessons I learned during the transition, and how my leadership had matured into something more deliberate and operationally focused. That two-minute version became important because it gave interviews a stronger starting point. It helped me sound less reactive and more intentional, and it made it easier to connect individual stories back to a broader leadership philosophy.

Vulnerability Helped, But Only When Paired With Standards

I made a point of being honest about the parts of management that were hard for me early on. I was not a perfect new manager. Most people are not. I talked about the support I received from leaders and HR partners who gave me room to learn, make mistakes, recover, and grow. I think that mattered because it made the story more human.

But vulnerability by itself is not enough. Engineering management is not only about being supportive when things are going well. Good leaders still have to be good when things are not humming.

So I also made sure I had clear stories about coaching, raising expectations, managing performance, and making difficult calls when the bar was not being met. That combination seemed to resonate because humility without standards can sound soft, and standards without humility can sound brittle; an important balance.

AI-Native Execution Became the Differentiator

The stories that generated the most interest were those about AI, hiring, and engineering execution.

At my previous company, I revamped our hiring process to better screen for engineers who effectively used AI. Not as a crutch or a shortcut, but as a real part of how modern engineers can increase leverage, improve feedback loops, and move faster. That hiring work changed the team's talent density, and once the right people were on the team, possibilities opened up.

The team began using AI to materially improve how we worked, especially around automation, testing, and engineering workflow. Those stories were much more compelling than generic claims about “using AI” because they were connected to concrete operating impact. Hiring managers were not interested in AI theatre. They were interested in what changed, what became faster, what became easier to maintain, and what work became possible that had not been possible before.

These were the stories that moved conversations forward.

The Market Is Still Behind on AI

One of the things that surprised me most was how far behind many companies still are on AI adoption. Not just in buying tools. Many companies have tools. The gap is in changing how teams operate.

There is a big difference between “we have access to AI” and “AI has changed how we hire, build, test, review, support, and deliver software.” Many companies are still much closer to the first statement than to the second.

That was surprising, especially given that companies have the technical talent, budget, and organisational scale to move faster. It also made the AI-related parts of my story stand out more than I expected.

The Practical Application Lessons

A few practical things helped, too. I did not optimise for application volume. I applied to roles where there was a plausible fit, including some that would have stretched me professionally. When possible, I avoided one-click application flows and applied directly through the company’s career page.

For applications with additional questions, I treated them as opportunities to create a signal. Over time, I built a small library of strong answers that I could adapt instead of starting from scratch every time. That helped me move faster without compromising the application's quality.

But the tactical mechanics only worked because the underlying story became clearer.

The Real Lesson

The job search reminded me that experience alone is not enough. You have to help people understand the shape of your experience.

For me, that meant getting clear about the kind of leader I am and the operating impact I tend to have. I help teams raise the bar, use better systems, and ship more effectively without unnecessary drama.

That sounds simple, but getting to that level of clarity took work. However, once I got there, it paid dividends.

Summer Open Triathlon Race Report

For the first time I can remember, maybe ever, I was both confident and relaxed going into a race.  They say the second night before a race is the most important night and to get a full night's rest and while I might argue that it should start about a week out, more, quality, sleep is better than none.  Thursday night resulted in a quite crappy sleep with me waking up every few hours.  But Friday night, I went to bed a little early and slept soundly with none of the pre-race jitters that usually keep you awake starting at 2am.

I'd set my alarm early enough to ensure I got to the race right as transition opened, only was a tad late and as a result didn't get the money transition spot.  I did, however, still get a really decent one and set up my stuff.  We were told four-to-a-rack, but that left lots of space and I knew from experience that late arrivals would move other, non-present athlete's stuff over to make room for theirs.  Even knowing this, I took my bike out for a warmup ride since I'd never ridden the course before and couldn't drive it beforehand.  It was only a 12.5-mile loop and I had plenty of time.

We had our own lane coming out of Union Reservoir and for the next several miles marked with cones.  But when the road turned right, the cones stopped and I realized I didn't have directions or know the streets so I just winged it.  Turns out, I guessed right and did manage to ride the entire loop.  As I'd suspected earlier, coming back to my rack, someone else had racked there bike where mine would have gone.  Thankfully, he was still there and I had him move his stuff over.

I finished setting up and started putting on my wetsuit.  We still had ample time before starting, but I wanted to make sure I was acclimated to the water.  Or, at least as much as possible given the 54º temperature.  The water was cold and I got in as much of a warmup as I could manage - I didn’t want to start cramping.

We line up to start and I take a left of center position up front.  The horn sounds and we’re off.  I go out hard and strong and eventually someone catches me and passes but he’s going too fast for me to be able to hang on.  I did most of the swim on my own, without drafting, which stinks, but sometimes is the nature of the beast.  About 300-400m in my chest tightened up and I forced myself to relax and backed off.  One of my points of emphasis this year is swimming less in training, and not working so hard on the swim in racing.  Was it a good strategy, I don’t know, but I was 3rd in my AG on the swim.

T1 was a smooth transition with no issues.  Due to the run over the muddy and grassy berm from the parking lot to the dirt road I chose not leave my cycling shoes clipped in to my pedals but I did when dismounting after the bike so in retrospect, I should have just left them clipped.

The bike was uneventful.  Only two riders passed me during the entire loop and neither were in my age group.  I passed a ton of riders, but I stopped looking at age groups on people’s calves and just rode my race.

T2 was even smoother leaving my shoes clipped in to my pedals, but the problem was that due to the cold water and probably the airflow on the ride, my feet were completely numb - exactly like last year.  I ran on stumps to my rack, dumped my helmet, pulled on my shoes, grabbed my race number and was off.

I tried to keep a high turn over on the run and was initially successful, but eventually slowed down.  I don’t recall when I started feeling my feet again, but it was well after mile two.  The out-and-back course was flat, having just been grated, but sported some rough spots with decently sized rocks churned up by the blade.  There was also a massive puddle that had to be navigated.  Only two guys passed me on the run, but neither were in my age group and I believe had started in a wave ahead of me so I already had at least three minutes on them.  The second guy passed right before the finish and I should have held him off, but didn’t.

All in all, it felt like a really solid race for me at the time and was confirmed when I looked at the results later and saw that I’d made the podium, getting third.

Swim:     10:59 (3rd in AG, 31st overall)
T1:        1:14
Bike:     34:29 (3rd in AG, 31st overall)
T2:        0:40
Run:      23:22 (6th in AG, 56th overall)

Total:  1:10:46 (3rd/13 in AG, 29th overall)

Thanks to my wife, my coach Billy Edwards, my shop Foxtrot Wheel & Edge, my team Foxtrot Racing, sponsors GU Energy and Rudy Project, multisport shop Colorado Multisport, for all the support.