Introduction
Seventy-five degrees at a ski resort in late March. My daughter and I walked Park City's Main Street in t-shirts, ducked into galleries, and found three original Banksy pieces we weren't expecting. By Thursday, when we left, it was snowing hard enough to finally look like Utah.
I was two weeks into my new role at Rise8. I'd been a name in Slack. Now I was in a hotel lobby full of the people behind those names, about to spend a week split between a company offsite and a conference that would test whether the ideas I'd been reading about for months hold up when real teams put them to work.
The week delivered. Over 3,000 deploys to production and more than 1 million tokens consumed across ShipSummit's teams in 36 hours. Those are real numbers from real teams building real things. But the numbers aren't the story. The story is what happened around them.
Meeting the Company at 7,000 Feet
Elev8 is Rise8's internal all-hands. It ran Saturday through Monday at the Grand Hyatt Deer Valley, perched above Park City with views that made it hard to stay inside for the sessions. Sunday was the leisure day. People scattered across Park City, Deer Valley, and Woodward for activities. My daughter and I took the leisure track, explored Park City's Main Street, and made it to the outdoor opening reception, where nobody needed a jacket. A wine tasting rounded out the afternoon before an optional happy hour at Hidden Ace.
Monday was the structured day. The morning EAT activity had groups building Lego sets together. It sounds trivial until you realize that collaborating on a physical build with people you've only known through video calls strips away the remote-work formality faster than any icebreaker exercise. Leadership Q&A followed. Then a scavenger hunt sent buses into Park City, where teams competed their way through downtown before free time and happy hour. The food was excellent throughout, the kind of catering that signals a company invests in getting these moments right.
Elev8 concluded Monday night with a formal dinner where teammates were recognized for their contributions. Awards, shoutouts, the kind of genuine appreciation that only lands when you can tell the people giving it actually mean it. Two weeks into a new job, sitting in that room, I knew I'd made the right move. The culture wasn't performative. It permeated everything, the way people talked to each other, the way leadership showed up, the way recognition felt earned rather than scripted. It was just awesome to be a part of.
The real value was in the margins, though. Conversations at happy hours and over breakfast. Putting faces and mannerisms and senses of humor to the names I'd been reading in pull requests and Slack threads. Two weeks in, that matters more than any agenda item.
ShipSummit: Learn, Build, Ship
ShipSummit ran March 31 through April 2 at the same venue. Rise8's inaugural conference and hands-on hackathon, open to the public, organized around a format with clear intent: Day 1 was talks and workshops. Days 2 and 3 were almost entirely hands-on building through what Rise8 calls Impact Labs. Learn, build, ship. In that order, and for a reason.
The attendee tracks used ski-run difficulty ratings, fitting the Deer Valley setting: Green Circle for people new to AI-assisted building, Blue Square for intermediate practitioners, Black Diamond and Double Black Diamond for engineers pushing the edges. The range mattered. ShipSummit was not an engineering conference. Product managers, designers, and platform engineers were there in equal numbers, working on the same teams.
Day 1: Talks and Workshops
Bryon Kroger opened ShipSummit, then Mina Hsiang and the Ship Stories panel set the tone with real stories from government and civic tech, a grounding reminder that shipping software in high-consequence environments has its own constraints that AI does not automatically dissolve. Gene Kim followed with a talk on vibe coding and ran workshops across multiple tracks throughout the day, giving people at every skill level a way to get hands-on immediately. I got my copy of his Vibe Coding book signed at the Day 2 book signing. He told me he believes the book holds up even as things move this fast, and that there may be a Volume 2 covering some of Steve Yegge's work like Gas Town, geared more toward non-engineers.
John Cutler drew the line between individual AI productivity (easy) and team-level collaboration with shared context (hard) in "Single-Player vs. Multiplayer." Steven Sloss covered product craft for high-consequence AI.
The afternoon keynote was my favorite session of the week. Kent Beck's "Features vs. Futures: Sustainable Augmented Development" started with a core argument: experienced engineers carry a mental cost model for what's feasible, built up over years of knowing how hard things are to implement. That cost model acts as a filter. Projects that would take six months get shelved. Features that require a rewrite get deprioritized. Over a career, the filter becomes invisible. You stop even considering the things you've learned are too expensive.
AI breaks that filter.
Along comes the genie & the box of "things worth working on" just got bigger. Much bigger.
But Beck didn't stop at "the box is bigger." The genie metaphor carried through the talk. Ask the genie for something vague and you get something back fast, confidently, and often not what you meant. It's a genie, not a mind reader. The less precise your wish, the more creative the interpretation. And the genie does finger guns, pew pew, and tells you everything is fine. The code compiles. The tests pass. The demo looks great. You feel like you're moving fast because the genie is moving fast. The danger is that the genie's confidence is contagious. You stop questioning whether you're building the right thing because the building is so easy.
His prescription: iterate on features, but step back after each one. Evaluate. Level up. Don't let the genie's speed trick you into skipping the reflection that makes the next iteration better than the last. This connects to Beck's broader argument about optionality: every feature you ship constrains what you can do next. Each one consumes flexibility in the codebase. Without deliberate tidying between features, teams drive themselves into exhausted optionality requiring complete restarts. The genie makes that trap worse, not better. If features are cheap to produce, the temptation is to skip the exhale-then-inhale rhythm, vibe-code the feature, move on, vibe-code the next one, and accelerate the lock-in instead of the learning. Features are what you ship today. Futures are what becomes possible when you pair cheap code with deliberate judgment about where to aim it. The talk connected to progressive delivery, feature flags, and reversibility as the infrastructure that lets you move fast without moving recklessly.
This connects to something Beck has been saying more broadly: nobody knows. Nobody knows what good looks like anymore. Nobody knows what this means for jobs, for economies, for the shape of the profession. The honest response is not to pretend you have answers. It is to experiment cheaply, try multiple approaches, and "bless and release" the practices that no longer serve you. The genie talk was optimistic about possibility, but grounded in the admission that the ground is shifting under all of us.
I caught Beck in the hallway afterward. He said T-shaped skills, meaning generalist capability across most things with one specialty of deep knowledge, are still the way to go over pure generalist. He also offered a comparison I haven't been able to shake: we are like the carpenter who just saw the invention of the circular saw. We think we are extinct, but more likely we just have different ways of working.
After Beck, Paul Rayner presented "Design in the Loop," making the case that domain modeling is the real bottleneck in AI-assisted development. He cited an experiment where the same LLM produced 3 schemas from a basic domain story and 9 schemas with correct business constraints from EventStorming output. Same model, same project, different input quality.
LLMs don't fail at domain work because they're not smart. They fail because they have no access to your domain.
David Bland's "IKEA Effect of AI Prototypes" raised a useful warning: people overvalue things they helped build, and AI-generated prototypes can create false confidence if teams skip validation. The practitioner panel with Morgan Hoose, Simon Murphy-Holroyd, and Jeff Patton closed out the talks with field reports from teams using these tools in production. Then Adam Furtado and Chad Brackelsberg kicked off the Impact Labs, and the building began.
Day 2: Story Craft and the Thought Leader Panel
Jason Fraser and Mike Gehard's morning session was the most practical talk on structuring work for AI agents that I've seen. Their workflow: find context in the codebase, define intent with user stories (As a / I want / So that), run gap analysis, write acceptance criteria in Given/When/Then, create a spec, hand it to an agent with fresh context, then validate against the original intent.
They revisited INVEST for the agent era and reordered it: Valuable and Testable move to the top. The old priorities assumed human effort was the constraint. When agents handle implementation, the constraint shifts to knowing what "right" looks like. Fraser called it "waterfall in 15 minutes," which got a laugh, but the point was serious. Structured intent, expressed clearly, produces better outcomes than unstructured speed. The acceptance criteria are not bureaucracy. They are the specification the agent needs to do good work.
The Day 2 closing panel brought Gene Kim, Paul Rayner, Mike Gehard, and Matt Pacione together, moderated by Sharon Hamilton. The core message: AI is an amplifier, not a fix. If a team already has poor delivery habits, weak user connection, or slow feedback loops, AI accelerates those weaknesses. Teams with strong practices and close collaboration with users benefit disproportionately. The gap between high-performing and low-performing teams is widening, not narrowing.
Several speakers framed AI-assisted work as personally invigorating, almost like rediscovering a creative spark that had faded under the weight of normal work and life. But the panel balanced that energy with real time on ethics: environmental costs of compute, labor disruption, concentration of power among a few AI companies, data privacy. The tone was not anti-AI. It was the tone of practitioners who use these tools daily and want to be honest about the tradeoffs. Beck's "nobody knows" ethos ran through the room: nobody on that panel claimed to know what this means for hiring, for junior developers, for the economics of software. They said so out loud. That honesty matters more than enthusiasm.
Impact Labs: Operation Avalanche
The centerpiece of ShipSummit was the Impact Lab, a day-and-a-half build challenge. The mission was called Operation Avalanche, developed with the Utah Avalanche Center. Real problem, real data, real domain experts in the room.
I was on Blue #1 with Bryon Kroger (Rise8's CEO), Justin Joseph, and Paul Nieto. Some of the teammates I was meeting for the first time. We designed and shipped an app that aggregated weather and avalanche data and reports to help skiers, snowboarders, and hikers navigate backcountry conditions. Going from "we just met" to "we shipped a working prototype" in roughly 36 hours was the most concrete proof-of-concept for this way of working I've experienced.
Bryon, it should be noted, is not an engineer. He was committing directly to main from the start, embracing trunk-based development without knowing that's what it was called. But midway through the build, he was talking about database schemas and API contracts like he'd been doing it for years. That's the thing about AI-assisted development that's hard to convey in a blog post: it doesn't just speed up engineers. It pulls non-engineers into the building process in ways that weren't possible before. The CEO of the company was shipping code to production and arguing about data models. Nobody told him he wasn't supposed to be able to do that.
The structure mattered. Rise8 built a lesson series as part of the Impact Labs: nine lessons covering everything from setting up a cloud workspace with Claude Code to the Explore, Plan, Implement, Verify workflow, to writing automated tests and building reusable skills. Teams worked through these during the event, not before it. The curriculum treated AI-assisted development as a learnable discipline with a specific process, not a feature you turn on. That framing echoes Beck's "teaching augmented coding" philosophy: provide structure, pair people up, let them play and learn.
If you're teaching augmented coding, I recommend leaving prompting alone. Nobody knows so everybody should be trying & sharing.
The teams that moved fastest in Impact Labs were not the ones with the best prompts. They were the ones that spent the most time understanding the problem before opening a terminal. Domain modeling first, code second. The Utah Avalanche Center experts were in the room for a reason. When your domain context is strong, the AI produces better output. When it's weak, you get plausible-looking code that misses the point.
The Bigger Picture
A week at altitude gave me a concentrated version of what I'd been reading about for months. I've been building a research knowledge base around how AI is reshaping software engineering, pulling from practitioners like Kent Beck, Simon Willison, Grady Booch, Vlad Khononov, the Thoughtworks retreat, and others. ShipSummit pressure-tested those ideas against real teams doing real work. Here is where I've landed.
Coding Changed, Engineering Didn't
AI has transformed coding, the act of producing code, but has not yet transformed software engineering, the discipline of building systems that work. The bottleneck was never typing speed. It was always understanding: the domain, the users, the tradeoffs, the failure modes, the system as a whole. Grady Booch has been saying it for over a year:
Very little about software engineering has changed over past last three months. A great deal has changed about coding, not unlike when we saw the rise of high order programming languages and compilers.
At ShipSummit, this was visible. The teams that built useful prototypes in Impact Labs were the ones with strong engineering instincts. They understood the problem domain. They wrote acceptance criteria before writing code. They validated against real user needs, not just passing tests. The coding went fast. Everything around the coding still required human judgment. Peter Naur argued in 1985 that programming is theory building, that the real product of development is the understanding in the developers' heads, not the code on disk. That argument has never been more relevant.
The Bottleneck Moves, It Doesn't Disappear
When AI accelerates code production, the constraint shifts to comprehension, review, testing, and deployment. You don't eliminate constraints. You move them. Organizations that only optimize coding without addressing the downstream pipeline get worse, not better, because they pile up inventory in front of a constraint that hasn't changed.
Vlad Khononov's Theory of Constraints argument played out in real time during Impact Labs. Once code production was fast (and it was very fast), the constraint shifted to understanding the problem, validating the approach, and delivering something useful. Paul Dix made the same point through Amdahl's Law: if coding is 20% of the delivery cycle and you make it 10x faster, you get a 1.25x overall speedup. To get 10x end-to-end, you have to speed up review, validation, release, and ops. ShipSummit's format got this right by starting with domain experts and structured planning before turning teams loose to build. The Thoughtworks retreat reached the same conclusion: "Quality doesn't disappear when code is generated by agents. It migrates. It moves upstream into specifications precise enough to guide machines."
Feedback Loops Over Model Intelligence
The next leap in AI-assisted development will come from better feedback loops, not smarter models. The quality gap between one-shot generation and iterative review is the most consistent finding across every practitioner I've read.
I believe the next leap in AI-assisted software engineering will come not from smarter models, but from better feedback loops.
The Impact Lab teams that iterated, tested assumptions with the Utah Avalanche Center experts, and refined their approach outperformed the teams that tried to build the whole thing in one pass. Khononov's OODA framework identifies Observe as the weakest link in AI-assisted development. Willison's red/green TDD pattern gives agents a concrete feedback mechanism: write the test, watch it fail, write the implementation, watch it pass. Beck's "Precious Eyeblink" argues that the Doherty Threshold, sub-400ms response time, should be the target for developer tool feedback. All three point the same direction: speed of iteration beats quality of the first attempt.
The Expert Wielding the Tool
AI agents amplify existing expertise rather than replacing it. The silver bullet is not the agent. It is the engineer who knows how to direct it. Domain knowledge, architectural judgment, and system understanding become more valuable when code is cheap, not less. Initial Capacity put it directly: "The silver bullet isn't the agent. It's the engineer who knows how to wield it."
ShipSummit was not a room full of prompt engineers. It was practitioners, product managers, designers, engineers, and platform engineers, each bringing domain expertise and using AI to move faster within it. Beck's circular saw comparison from our hallway conversation fits: we are not extinct. We have different ways of working. The carpenter still needs to know wood, joints, and load-bearing walls. The saw made the cuts faster. Willison calls this skill "agency," the ability to guide and evaluate AI tools effectively. It is the meta-skill that compounds with everything else you know.
Human-in-the-Loop as a Design Pattern
Human oversight is not a temporary crutch until the models get better. It is an intentional design choice. Martin Fowler's team frames it as two loops: a "why loop" where humans set intent and evaluate outcomes, and a "how loop" where agents execute. The most effective AI-assisted workflows treat the human role as architectural: setting intent, verifying outcomes, providing domain context the model cannot access on its own.
The question worth asking is not "how do we use AI to go faster?" It is "how do we give AI enough context to go in the right direction?"
Fraser and Gehard's story craft workflow operationalized this at ShipSummit: define intent with user stories, set acceptance criteria, let the agent implement, then validate against the original intent. The human stays in the loop not because the AI is unreliable, but because the human is where the domain knowledge lives. Beck's "Intentions & Actions" essay traces this pattern back to its roots: people come to systems with intentions that are separate from the available actions, and the mapping between them is where computers either feel like magic or feel like misery.
The Economics of Cheap Code
The cost of producing code has dropped to near zero. Or more precisely: the marginal cost of generating code has. The infrastructure costs of running agents at scale, token pricing, rate limits, the API bills that stack up when you're doing real work and not demos, those are real and still shaking out. Beck's "Starving Genies" documents what happens when providers throttle supply simultaneously. Nobody knows where the pricing lands yet. But even at current rates, heavy agentic usage costs a fraction of an engineer's salary, and the trajectory points one direction. This changes how we build, price, fund, and hire for software. The second-order effects are what matter. Matt Aimonetti put it well: the real opportunity is not doing the same thing with fewer people, it is doing something 10x better with the same people. Expectations rise. Competitors move. The bar goes up.
Beck's "Programming Deflation" adds nuance: when code is cheap, the market bifurcates. Some software gets commoditized. Other software, the kind that requires deep domain knowledge, architectural care, and operational reliability, becomes more valuable precisely because the noise floor rises. Thorsten Ball's oil analogy makes the same point from a different angle: cheap oil didn't just eliminate horse-drawn carriages, it restructured the entire petroleum industry through second-order effects that nobody predicted from the price change alone.
Code is becoming disposable, but systems are not. Every throwaway prototype depends on rock-solid infrastructure underneath. The Winchester Mystery House is the cautionary model: sprawling, idiosyncratic, and impossible to maintain.
Harness Engineering and Agent Guardrails
A new discipline is forming around constraining and directing AI agents through configuration, tests, and process design. Martin Fowler's team calls it harness engineering. The idea: you don't control an agent by making it smarter. You control it by building the right guardrails. The CLAUDE.md files, the test suites, the acceptance criteria, the verification gates.
ShipSummit's Impact Lab curriculum was harness engineering applied to a learning context. The Explore, Plan, Implement, Verify workflow is a harness. The story format (As a / I want / So that) is a harness. The acceptance criteria are a harness. Beck's unbundling of code review points the same direction: the old monolithic review process needs to be decomposed into specific quality checks that can run independently, some by humans, some by agents.
Agent Architectures Are Still Forming
How should you structure agent systems? The answers range from role-based orchestras (conductor coordinates specialized agents) to evolutionary swarms (generate many solutions, select the best) to dark factories (fully automated production lines). Each encodes different assumptions about where intelligence lives and what humans are for. Wes McKinney warns that Brooks' Law may apply to agents too: adding more agents to a late project makes it later. Nobody has converged on the right answer yet. This is one of the clearest examples of Beck's "nobody knows" in practice: we are inventing the patterns and the vocabulary at the same time, and the teams at ShipSummit were experimenting across this spectrum in real time.
Measuring AI Impact Is an Unsolved Problem
Vendor claims of 100-200% productivity gains don't match real-world measurements. Independent studies keep landing in the 3-16% range: DX Core 4 deployments across 300+ organizations, Booking.com's throughput data, survey results from the Pragmatic Engineer. The gap is not surprising: most measurement frameworks still count code output, which is the one thing AI already makes cheap. What matters, and what we still can't measure well, is whether teams are shipping better outcomes faster. DX Core 4, SWE-CI, and other frameworks are trying, but the field is young. Beck's NPV framing offers a different lens: headcount reduction is the least interesting of four value levers. The real value is in what becomes possible, not in what becomes cheaper.
Demos Are Not Products
The gap between a compelling AI demo and a reliable product is the central tension of this moment. Demos show the ceiling of what's possible. Products must deliver at the floor of what's acceptable. Most AI agent announcements conflate the two. Impact Labs operated in demo territory, and that's fine for a 36-hour hackathon. But the teams that treated it as a learning exercise rather than a shipping exercise came away with better instincts for the real work ahead.
Conclusion
Two weeks in at Rise8. Met my coworkers over Legos and a scavenger hunt through Park City. Found three Banksys I wasn't looking for. Built an avalanche safety app with people I'd met 48 hours earlier. Heard Kent Beck explain why the box of possibility just got bigger, and why the genie's finger guns should make you pause, not relax. Watched teams of strangers ship over 3,000 deploys in a day.
And here is the thing I keep coming back to: nobody knows. Beck said it plainly in his "Still Burning" series: nobody knows what good looks like anymore. Not him. Not the people on that panel. Not the vendors selling you productivity metrics. Nobody knows what this means for junior developers trying to break in, for teams trying to staff projects, for companies trying to plan two years out, for economies built on assumptions about how software gets made. The ground is shifting and the people who have been doing this for thirty years are as uncertain as the people who started last month.
That is not a comfortable thing to say at a conference. But it was the undercurrent at ShipSummit, and it is what made the week feel honest instead of performative. The speakers who impressed me most were the ones who said "I don't know" and then followed it with "so here is what I'm trying." Beck's prescription: experiment cheaply, try many things, share what you learn, and bless and release the practices that no longer serve you. Not a roadmap. A disposition.
The tools will keep changing. The models will get better. The patterns that matter, the feedback loops, the domain understanding, the engineering judgment, the structured workflows that turn intent into verified outcomes, those are what compound. But the meta-pattern above all of them is the willingness to work in uncertainty without pretending it is certainty. ShipSummit showed me what it looks like when a room full of people takes that seriously. The circular saw is here. Nobody knows what the carpenter becomes next. The only honest move is to pick it up and find out.
See the associated LinkedIn post.
Comments
To leave feedback or questions, simply login using your preferred social network. I will read and answer your comments promptly, but please keep in mind that they will be public.