Webinar: The State of Vibe Coding

Summary

Paul Ford, Rich Ziade, and Kevin Barrett (Aboard’s VP of Engineering) present a comprehensive webinar surveying the vibe coding landscape in early 2026. The session is structured in three parts: a blitz tour of the major vibe coding tools and platforms, a roleplay exercise exploring the maximalist AI-replaces-everyone fantasy, and a discussion of how the software development life cycle is changing.

The trio categorizes the vibe coding space into four buckets: Platforms (Gemini, Claude Code, ChatGPT/Codex), Vibe Coders (Lovable, Replit, Bolt), Spec-based tools (Kiro, GitHub SpecKit), and IDEs (Cursor, Zed, Windsurf). Claude Code emerges as the clear favorite among CLI coding agents, praised for generating the best code and having the most thoughtful developer experience. The vibe coders like Lovable and Replit are described as “magic for 30 minutes” but frustrating after four hours, particularly when trying to ship full-stack applications.

The roleplay section features Paul as a mid-level engineer declaring he can build anything with Claude Code and no longer needs a CEO or head of engineering. Rich pushes back with real-world business complexity that chatbots cannot handle, while Kevin warns about the danger of generating 10,000 lines of unmanageable code. The SDLC discussion highlights that prototyping is now nearly free, but “looks done to me” is a dangerous new risk, and that LLMs produce “statistically likely code” that makes bugs nearly invisible by definition. Kevin memorably compares junior engineers using Claude Code to “using a crane to do reps at the gym.”

Highlights

”Claude Code is the Best CLI Coding Agent”

yt-dlp --download-sections "*6:10-7:10" "https://www.youtube.com/watch?v=WVPWboBINrA" --force-keyframes-at-cuts --merge-output-format mp4 -o "WVPWboBINrA-6m10s.mp4"

“Of the CLI agents I’ve used, it’s the best. The quality of the code… I think the makers of Claude have trained it on a corpus of data that includes a lot more code. The model itself is tilted toward code.” — Kevin Barrett, 6:10

”Magic for 30 Minutes”

yt-dlp --download-sections "*11:05-12:00" "https://www.youtube.com/watch?v=WVPWboBINrA" --force-keyframes-at-cuts --merge-output-format mp4 -o "WVPWboBINrA-11m05s.mp4"

“You know what’s fun? For about 30 minutes, a magic act. You know what’s not fun after about four hours? Magic act. Not fun.” — Paul Ford & Rich Ziade, 11:05

”Spec-Based Tools Are Halfway Right”

yt-dlp --download-sections "*14:30-15:30" "https://www.youtube.com/watch?v=WVPWboBINrA" --force-keyframes-at-cuts --merge-output-format mp4 -o "WVPWboBINrA-14m30s.mp4"

“There’s a fatal flaw with spec-driven AI tools… the plain English artifact has to leap to code and that inference gap is too wide. You’re still leaving it to chance for the models to translate English language descriptions of software into the actual software.” — Rich Ziade, 14:30

”Using a Crane to Do Reps at the Gym”

yt-dlp --download-sections "*29:10-30:10" "https://www.youtube.com/watch?v=WVPWboBINrA" --force-keyframes-at-cuts --merge-output-format mp4 -o "WVPWboBINrA-29m10s.mp4"

“If I were building a growth program for a large engineering team and I had junior engineers, I would consider banning them from using Claude Code because I don’t think they would learn. It’s kind of like using a crane to do reps at the gym — they wouldn’t be building any muscle.” — Kevin Barrett, 29:10

”Statistically Likely Code”

yt-dlp --download-sections "*38:30-39:30" "https://www.youtube.com/watch?v=WVPWboBINrA" --force-keyframes-at-cuts --merge-output-format mp4 -o "WVPWboBINrA-38m30s.mp4"

“The really scary thing about generated code is that definitionally what an LLM does is produce statistically likely code. It produces code that looks correct. Which means that when there’s a bug, it’s really hard to see because it looks correct by definition.” — Kevin Barrett, 38:30

”Engineering Has Been a Culture of No”

yt-dlp --download-sections "*30:50-31:50" "https://www.youtube.com/watch?v=WVPWboBINrA" --force-keyframes-at-cuts --merge-output-format mp4 -o "WVPWboBINrA-30m50s.mp4"

“Engineering has been a culture of no for 50, 60, 70 years and I think that successful engineering can become a culture of yes. ‘Hey, let’s try it out. We’ll probably throw it away but we can do it this afternoon.’ What used to be six months of planning.” — Paul Ford, 30:50

Key Points

• Vibe coding landscape taxonomy (3:10) - Four categories: Platforms (Gemini, Claude, ChatGPT), Vibe Coders (Lovable, Replit, Bolt), Spec-based (Kiro, GitHub SpecKit), and IDEs (Cursor, Zed, Windsurf)
• Google Gemini as sleeper (4:20) - Not the best coding platform today but has endurance and scale; don’t underestimate Google showing up with “five aircraft carriers”
• Claude Code dominance (6:10) - Best CLI coding agent; best code quality; 90% of using AI tools is telling it what not to do, and Claude is good at that
• ChatGPT/Codex feels bolted on (8:10) - Claude is the new Google of AI; ChatGPT is the Microsoft — “good enough, lock you in, if you complain go tell your CTO”
• Vibe coders hit a wall (11:05) - Lovable, Replit, Bolt are “magic for 30 minutes” but fall apart on full-stack apps; non-engineers got “teased” then walked away
• Platform economics problem (16:50) - All downstream vibe coding tools are arbitraging tokens from foundation models; Cursor is building its own model to escape this
• Spec-based tools halfway right (14:30) - The inference gap from English specs to code is still too wide; specs were written for humans, not machines
• Zed pioneered MCP protocol (18:00) - Kevin uses Zed for its open-source, collaborative nature; they pioneered a protocol for running Claude Code in any editor
• Aboard’s deterministic approach (20:30) - Instead of generating code, Aboard generates specs that run on a handwritten runtime, avoiding chaotic generated code
• Roleplay: AI maximalist fantasy (23:30) - Paul plays a mid-level engineer claiming superpowers; Rich counters with real business complexity (supply chains, HR, barbecues with suppliers)
• 10,000 lines of unknown code (27:30) - Kevin warns about going “deep down the mine shaft” with Claude Code then running out of light; many senior engineers have pulled back
• Banning AI for juniors (29:10) - Kevin would consider banning Claude Code for junior engineers to force learning; it’s like using a crane for gym reps
• Engineering culture shift (30:50) - Moving from “culture of no” to “culture of yes” where you try things this afternoon instead of planning for six months
• “Looks done to me” risk (34:00) - Prototypes from vibe coding look polished but may lack security or have subtle bugs; this is why wireframes existed
• LLMs produce statistically likely code (38:30) - Bugs are nearly invisible because code looks correct by definition; Kevin calls this the huge risk
• QA most vulnerable to change (40:30) - Testing via Playwright and scripted browsers will increasingly be AI-driven; migrations also benefit enormously
• The AAA of software (42:00) - Accountability, Architecture, and Aim — three things LLMs cannot provide that humans must own
• LLMs prefer writing their own code (39:30) - Paul’s experience: Claude Code refuses to reuse open-source libraries, preferring to write simpler versions that produce worse results

Mentions

Companies

• Google/Gemini (4:20) - Platform with coding capabilities; image generation; endurance play
• Anthropic/Claude Code (6:10) - Best CLI coding agent; best product sense of any AI company
• OpenAI/ChatGPT/Codex (8:10) - Multimodal platform with coding tool; feels “bolted on”
• Lovable (10:20) - Vibe coder; good for prototyping; people give up sooner
• Replit (11:30) - Started as browser-based IDE; predates AI; champion of “couldn’t get it over the line”
• Bolt (12:40) - Focused on the prompt; growing fast; hard to distinguish from competitors
• Amazon/Kiro (14:00) - Spec-based tool; Amazon-style predictable outcomes
• GitHub/SpecKit (15:30) - Microsoft-owned; Copilot considered “kind of bad”; AI features low impact
• Cursor (17:00) - Based on VS Code; biggest swing in IDE space; building their own model
• Zed (18:00) - Open source editor; pioneered MCP protocol; Kevin’s editor of choice
• Windsurf (19:30) - Similar to Cursor; hard to distinguish
• Aboard (20:30) - AI-focused software acceleration platform; deterministic runtime approach
• Tassel (16:10) - Spec-based tool focused on privacy and security

Products & Technologies

• VS Code (17:00) - Base for Cursor IDE
• Playwright (40:30) - Scriptable Chrome browser for testing
• Git (28:30) - Kevin’s analogy: Git didn’t replace engineers, it made them faster; same with AI
• React (12:00) - Common framework in vibe-coded output
• Quest (19:50) - Open-source, local-first vibe coding tool at quest.dev
• MCP Protocol (18:20) - Open protocol pioneered by Zed for running AI tools in any editor

People

• Paul Ford (0:45) - Co-founder of Aboard; drives the webinar presentation
• Rich Ziade (0:48) - Co-founder of Aboard; plays CEO in roleplay
• Kevin Barrett (0:10) - VP of Engineering at Aboard; based in Washington DC
• Linus Torvalds (31:30) - Creator of Linux; referenced for his perspective that compilers were a 1000x speedup, and AI is similar
• Sam Altman (4:40) - Referenced in passing as bringing heat and light to OpenAI
• Martin Kleppmann (48:00) - Referenced in chat; article about formal verification of generated code

Surprising Quotes

“It’s 90% telling it what not to do. And Claude is good at this. A lot of the innovation around AI after the big breakthrough is guardrails.” — Kevin Barrett & Rich Ziade, 7:00

“These tools got a lot of free fuel because non-engineers played with them. Product managers, executives who quietly in the dark wanted the app that they’d been asking for for a really long time.” — Rich Ziade, 11:40

“I have a very dynamic business. I have a roster of clients. I have partners that supply me raw materials. You know nothing about those relationships. You don’t think I can just put a chat on the website? No, because I’ve got to worry about my supply chain and my suppliers who, by the way, I go to their barbecues because I need to be first in line for wood.” — Rich Ziade (in roleplay as CEO), 24:30

“I’ve been pushing like hell to get Claude Code to reuse open-source libraries and modules. And it really wants to write its own stuff to the point that it will say, ‘This is amazing. Thank you for providing it. But it’s a little too complicated. So what I’m going to do is just write a much simpler version for you.’ And then it just sounds bad.” — Paul Ford, 39:30

“All these tools aside from Gemini, Claude, and OpenAI are arbitraging tokens. Their unit of measurement is the token and they charge some fraction of cents per token. And all these other tools are just charging you slightly more per token. That is bad economics for them and they have to change.” — Kevin Barrett, 16:50

Transcript

0:00 Are we live? Hello everyone. How you doing, Paul? I’m doing good. We’re doing a webinar. We’re joined by Kevin Barrett in Washington District of Columbia, our head of engineering. Hello. Kevin, just for everybody to know, Kevin loves doing media. He’s a huge ham. He’s really excited to be on camera and just talk to an audience. It’s his favorite thing in the world. And I just think that’s beautiful, Kevin. I’m really glad you’re here. Welcome, Kevin. It’s going to be fun. Thank you for the opportunity. I’ve been counting down the days.

0:32 It’s great. No, I’m sure you have, actually. It’s special. You really dread this when you’re not someone who does it all the time. So, we’re going to have a good time. We are going to talk about the thing, Richard. The big thing, the elephant in the room, as I like to call it. You’re Paul Ford. Yes. I’m Rich Ziade. That’s Kevin Barrett. We are the leadership team of a company called Aboard that’s an AI focused software acceleration platform. We’ll talk about it for like a minute, but we’re not really going to pitch it in this talk. No, we’re not. But we have a fun podcast that talks about AI and software and culture and it’s really cool. So, check it out.

1:17 All right. Good. So, I think I’m going to share a screen so we have things to talk about. A few things. So, there is chat. The chat is being monitored by our expert chat monitoring expert, Gabe. What we’re going to do, let me just talk for a minute. We’re gonna talk about three things. First thing, we’re just going to do like a blitz tour of the vibe coding space. A few little opinions and some personal experiences. Then we’re going to do a roleplay section. It will be very safe for work. And then we’re going to talk about how the entire software development life cycle may be changing.

2:30 So this won’t just be tips and tricks. It’s going to be kind of like how are our jobs changing and a little bit of how can we get ready for the future. Unless anyone has any objections, I’ll bring up a deck. Rock and roll. All right.

3:10 We’re going to talk about the state of vibe coding. The first thing I want to do is just talk a little bit about the patterns in this space and what are the big broad buckets of companies. The first one is platforms — here’s your box, type into it and we’ll make you whatever you want. That’s your Geminis and your ChatGPTs. Then we got the vibe coders which are like come on in, we’re going to build software right now. Then you get spec-based, which is a new thing — we’re going to slow you down, do some thinking, do some architecture before we build. And then you got the IDEs like Cursor and so forth.

4:20 First one — Google. For all that everybody talks about AI, there’s always Google lurking in the background. Gemini doesn’t get all the heat and the light that Sam Altman brings to OpenAI. But it does a lot of everything and it does some things very well. It’s not necessarily the best coding platform today but it has other features. You can use the image generation functions in your code, you can use the code in your smart notebooks, and you can count that this is going to scale and work in a reliable way because it’s Google. Don’t underestimate Google’s endurance in this race. They can always show up with like five aircraft carriers.

6:10 Now Claude Code. Everybody including me is talking about Claude Code. It’s worth mentioning — these are tools for engineers but they’re features of the larger platform. You’re paying the subscription fee already. So they’re a way to get more lock-in. Kevin, how would you talk about this product? Yeah, of the CLI agents I’ve used, it’s the best. You have to know how to use it, but of all the tools I use to generate code, it generates the best code. Why is it better? I think the makers of Claude have trained it on a corpus of data that includes a lot more code. The model itself is tilted toward code. And the UX around the LLM — Anthropic has invented lots of patterns for controlling the LLM like skills and agents. It’s 90% telling it what not to do, and Claude is good at this. A lot of the innovation around AI after the big breakthrough is guardrails.

8:10 And then you’ve got ChatGPT. They’ve got Codex which is their coding tool. It is multimodal. I will say it feels a little bolted on. It keeps getting lapped by Claude and every time I go in to look at it I kind of keep drifting back to Claude. If Claude is the new Google of AI, I really see ChatGPT as kind of the Microsoft — we’re going to get you just enough of everything. We’ll lock you in. It’ll be good enough. And if you complain, go complain to your CTO.

9:30 What’s tricky is the big platforms may just be in it to win it because all the smaller vibe coding tools are downstream of them, often using their LLMs. So those are the platforms. Now vibe coders.

10:20 Richard, you use Lovable a little bit, right? Yeah. It’s got a box you type in but it’s really optimized towards building an application. Early days, they fell down when you tried to drag a full-stack app across the line. They were good for prototyping. They’re still pretty good for prototyping. They’re good for apps that have much smaller surface areas.

11:05 You know what’s fun? For about 30 minutes, a magic act. You know what’s not fun after about four hours? Magic act. Not fun. What you’re seeing now is they got a lot of free fuel because non-engineers played with them — product managers, executives who quietly in the dark wanted the app they’d been asking for for a really long time. But the shine came off real fast. So what they’re doing is building out the less glamorous pieces — databases and persistence layers and logic.

12:00 Replit was the really nerdy one. It started as a browser-based IDE. They predate AI. Really smart people like Replit a lot. It’s for the deep nerds. Lovable feels like it’s still skimming the surface. Replit is in a lot of engineering teams all around the world. These are very well-funded companies. They’re all racing. The challenge is they sort of skip architecture and just run to gluing components together. It’s usually React stuff. Replit is the champion of “we couldn’t quite get it over the line right now.” If you just need to make a website for your coffee shop, these tools are pretty good. But if you need to build a CMS for your coffee shop, that’s trickier. They get close — that’s the thing that’s so tantalizing.

13:30 Kevin, do you have thoughts on these tools? I am not the target audience of these tools. My opinion is that all of these tools are going to be destroyed by the foundation models that we just talked about earlier. Bolt is another one growing fast. This category is tricky because some people will tell you this is the absolute future and other people will tell you they’re losing audience share. Meanwhile, these behemoths — Claude is going to be a $300 billion company when it goes public.

14:30 Now spec-based. What is a spec? A spec is something akin to a blueprint of what you’re going to build. Specifications used to get written for other humans to consume. It’s sort of like a contract. A spec is an insurance policy. In the human world. Now what’s interesting about specs in the AI world is that when you just type three sentences in a box, AI won’t come back to you and say “you left a lot of ambiguity there.” AI will make assumptions. Two sentences means tons of gaps of clarity. So the thinking is why don’t we give AI a spec? That’s Kiro from Amazon. Before it spews out code it spews out a document.

15:30 There’s a fatal flaw with spec-driven AI tools. The plain English artifact has to leap to code and that inference gap is too wide. Most people when they write specs don’t write them for machine consumption. These models draft specs off of other specs. The point of a spec is for humans to develop. And the way Kiro writes credible specs is it looks at other specs in the world — which isn’t ideal for machine consumption because machines don’t think in a narrative sense, they think structurally. The Kiro approach is if we take the spec approach we’ll have a more predictable outcome. And they’re Amazon and they like predictable outcomes. GitHub has SpecKit too but Copilot is commonly considered kind of bad. The AI features are fairly low impact or a distraction.

17:00 Now IDEs. Cursor is the beast. It’s based on VS Code. It can look pretty magical. The biggest swing — they’re building their own model. They want to own this space. Kevin, why are they building their own model? All the tools aside from the foundation models are arbitraging tokens. They charge you slightly more per token. That is bad economics and they have to change. Cursor is like, well, if we make our own model, we can charge ourselves.

18:00 Now Zed. Very nerdy, very open source. Kevin uses it. There’s two reasons I use Zed. First, I’m not smart enough to use Vim. Second, Zed was initially built to do really good collaboration like pairing using CRDTs. They built in a chat interface for AI stuff, and they pioneered a way to use tools like Claude Code in Zed and open-sourced this as a protocol. Now other tools are using this approach. I’ve started using Claude Code in Zed. I don’t use Zed’s interface anymore for that stuff. It’s very neutral. It lets you follow your own workflow.

19:30 Windsurf — very similar to Cursor. Hard to tell the difference. Honorable mention: Quest. It’s fully open source but also local first. You can run an LLM locally inside your network. If you’re a government agency or security-focused company, you can take everything in house. Then there’s Aboard. The core user is not an engineer. They’re a business stakeholder, a product manager. Code is one of the phases in the journey. Under the hood, very technical things are going on, but we want to give you your thing.

21:00 We don’t vibe code, we create a vibe software architecture. Kevin, what does it mean for us to be deterministic? The spec-based tools are halfway right. They use specs to determine how something should work. But the mistake all these tools make is they generate code. Generating code is inherently chaotic. Instead, we generate a spec that runs on our runtime. So you get all the benefits of very fast development without the downside of code that no one understands that could do anything. The tradeoff is we don’t do a lot of things. You’d never use us to make a game or a social media platform. We are for database-driven, logic-powered productivity apps.

22:30 Quick afterward before the roleplay. We kind of poo-pooed across all these apps. The truth is this stuff is changing and getting better. Can the day arrive when a spec-driven tool actually ships fully baked software? Maybe. It’s better today than it was 6 months ago. But process and careful stepping through is key. All of these tools are different riffs on process. They’re backing into process. They thought we could all shortcut by just typing into a prompt.

23:30 Now the roleplay. I made a playbill. I’m the AI believer. Rich is the CEO. Kevin is the head of engineering. I’m gonna fire you both because I’ve been using Claude Code. I’m a mid-level engineer and I have been given superpowers. I can build anything now. AI is just going to get better. I’m going to tell you, I don’t need you. I can take products and launch them. I can A/B test them. I think your entire role is redundant.

24:30 Why do I need you? Because you’re not a business person. I have a very dynamic business. I have a roster of clients. I have partners that supply me raw materials. You know nothing about those relationships. You don’t think I can just put a chat on the website? No, because I’ve got to worry about my supply chain and my suppliers who, by the way, I go to their barbecues because I need to be first in line for wood. Also, I’ve got some HR issues in a file. You want to look at those too?

26:00 There’s this maximalist thing that happens. You use these tools and you’re like “oh my god, it’s over. It unlocked.” And then you look around the room saying “goodbye, goodbye, goodbye.” No one ever points to themselves oddly. I buy that there’s a huge transition happening but I just don’t buy that it’s that simple. By the way, there’s a 4pm HR meeting that I need you to attend.

27:30 Kevin, I can build everything I want in a few hours. Why should I listen to a word you say? Good luck. Senior engineers and visual artists are the two cohorts most skeptical of AI. If you go off by yourself and build out the entire product, you’re going to end up in these hyper-idiosyncratic undebugable places where you’ve gone really deep down the mine shaft and then your light went out and you don’t know where you are. I know plenty of people who went deep on Claude Code as a senior engineer and then pulled way back because they wrote 10,000 lines of code and don’t know what any of it does.

28:30 Kevin, 200 engineers to 120 engineers — realistic? I do not think Claude Code replaces engineers. It’s a tool like any other. Before Git, before version control, we were putting files on shared drives. Then Git comes out and nobody said “thank god now we can fire a bunch of engineers.” But all the engineers got faster. It’s the same thing here.

29:10 If I were building a growth program for a large engineering team and I had junior engineers, I would consider banning them from using Claude Code because I don’t think they would learn. It’s like using a crane to do reps at the gym. They wouldn’t be building any muscle.

30:00 I think the culture shifts a little bit. Some people are going to let their engineering teams go without thinking about it. What I think is real is a skilled operator can accelerate. I’ve gone really deep and you do get into that hole and then you have to back out and rearchitect and start all over again. That goes a lot faster than it used to but it ultimately becomes indistinguishable from programming and ends up taking weeks. Not years, and you can do things you didn’t do before, but it’s not like you can whistle a tune and have a tool.

30:50 Engineering has been a culture of no for 50, 60, 70 years and I think that successful engineering can become a culture of yes. “Hey, let’s try it out. I don’t know, we’ll probably throw it away but we can do it this afternoon.” What used to be six months of planning. A lot is going to get thrown away and we have to embrace that.

31:30 Linus Torvalds, who created the Linux operating system, is using AI to evaluate code more and more. He’s like, “Yeah, it’s fine.” But if you think about it, compilers which take code and turn it into machine language — that was like a thousand times speed up. You had to sit there and flip switches before those showed up. And we don’t think about that. But think about how many programmers there were in 1960 with IBM and then suddenly Fortran and these new languages make it way more accessible. You end up with 50 million people in the software industry today. This kind of progress tends to get spread out and lead to growth. Implicit in that is shifts in skills.

33:00 Now the software development life cycle. How do you make software and what is changing? A lot of things are changing but there’s new risks. Stakeholder interviews, product strategy, problem statements — I think prototypes are going to lead followed by feedback. It’s just too easy to make. Let people click on something even if it’s not real and then iterate.

34:00 One of the big risks is “looks done to me.” Things look really good coming out of vibe coding sessions but haven’t thought about security or have weird bugs. You have to be paranoid that what you’re presenting — this is why there were wireframes, so people don’t get convinced something’s done and ask why it’s taking so long.

35:00 Requirements and specs. The prototype everybody liked and iterated on — you can say to the robot, turn that into the specification. Specs can be anything now. They can be user stories. You can tell it to make a comic book. However is the best way to communicate the quality of a system is now approaching free and used to be unbearably expensive and really boring. The risk is nobody used to read the spec and now no one is writing them. That thinking of creating the spec was part of building a culture around the product. You had to fill in the blanks and then you were someone who knew it and could guide its development.

37:00 Architecture phase. It was always about finding the one really good true architecture. Now you can prototype architectures — what if scale is low at first and gets really big. There’s a flexibility built into this new way of working. But LLMs will propose and build platforms for you — they really can’t make the decision for you. You need to have a sense of what you want. The recurring theme is expertise is needed in all phases to validate what’s coming out.

38:00 Implementation coding. We know it’s slow with constant scope challenges. The thing that ships is always smaller. Now we have fast and cheap and sometimes good but not always good. How’s your culture going to change to receive 10 times as many iterations? There’s an absolute glut of bad code coming. Claude Code writes really good code but it might have nothing to do with the actual business goal.

38:30 The really scary thing about generated code is that definitionally what an LLM does is produce statistically likely code. It produces code that looks correct — that’s what it’s supposed to do. Which means when there’s a bug, it’s really hard to see because it looks correct by definition. When you generate a lot of code and review it, it’s very scary. That is the huge risk.

39:30 If you’re pulling data out of a database and putting it back in, you’re in a pretty good place. But when you try to do something subtle or experimental, you’re in no man’s land. I’ve been pushing like hell to get Claude Code to reuse open-source libraries and it really wants to write its own stuff. It’ll say “this is amazing, thank you for providing it, but it’s a little too complicated so I’m going to write a much simpler version.” And then it just sounds bad. It’s not outcome driven. It doesn’t have ears.

40:30 QA is increasingly going to change. Launch Playwright which is a scriptable version of the Chrome browser, test every component, save the test. QA is really vulnerable. I also think migration is going to benefit enormously because you can say “verify every single element from database A before it goes into database B.” You can do that with mathematical certainty. These projects — everybody hates them and they always fail. “We’ve been working on the migration for 18 months.”

42:00 DevOps — “deploy this to Digital Ocean” will be the new DevOps. The complexity of the cloud is vast and AI cuts through it like butter. The risk is real — an LLM can destroy your server, share your keys. But Amazon Cloud Services will be you asking it to do things, not 50 different icons.

42:30 What do you get out of all this? Really fast exploration. Lower cost. Lower barrier to entry. But the AAA of software: Accountability for these systems, understanding the Architecture to maintain them, and knowing your Aim and business goal. LLMs cannot handle those three A’s. Train engineers into responsibility. Sustaining and building this culture knowing you can accelerate delivery, but hitting the brakes when these things are at risk, is where you need to go.

44:00 Questions. Can you talk about vibe upgrading? I think if you have a good working system, that’s a very strong place to start with an LLM transformation process. You can get from legacy system to modern API-driven, good data dictionary, RAG search on the front. It’s still work, you still need to use your brain, but it goes a lot faster. An excellent spec is your existing software — it’s fully detailed out. But you can’t just say “hey AI, upgrade this to some new platform” and let it go. You have to create checkpoints along the way for it to migrate through a pipeline.

47:00 Test engineering question. LLMs are very eager to write tests. We internally have leaned into if you’re going to use Claude to do a significant change, please write tests for it. Even if it generates the tests and you code review them, you at least have a level of assurance. There’s also formal verification which is a step beyond testing. Being able to say with authority that the code generated does what you intend is essential.

48:30 Are the LLMs eating the bad code? They are just helping themselves to bad code. They eat everything and produce bad architectural patterns. You sit down to make a new web application and do the exact same project twice — one will use a totally different component framework. There isn’t actually reliable logic about best practices built in. An experienced engineer has strong preferences because of the pain of development. Just because an LLM ate the whole world doesn’t mean it has good judgment about what’s better than what.

50:00 Thank you for mentioning banning AI for junior engineers. When should junior engineers use AI? As a general rule, I try not to use Claude Code to do something that I don’t know how to do because that is how I learn — by doing. I’ll have Claude Code do things that I know how to do very well that I can review and that are tedious. If it’s writing 300 lines of tests, sure. But if it’s learning some squirrely database reflection I’ve never done before, I want to do it myself even if it’s difficult and hurts my brain, because I’ll come out the other side knowing how to do it.

52:00 I’ll throw a mild counter — the LLMs are really good at explaining code and explaining how a system is working. Find an open-source example and make it step through and tell you everything that’s going on. I’ve learned more about digital signal processing than I ever learned before. The books are very dry, but doing it and listening to something make static and going “how do I fix that” turns out to be really motivating.

53:00 Kevin’s value to our organization is not that he can do things at the prompt. It’s that he can think holistically about engineering both as a human discipline and as a concrete way to make computers do things and bring those worlds together. That career is because he is good at those things. I don’t think that career is going away.

54:00 It’s tempting to not bother to learn because it seems easier and faster. But it’ll teach you. Use the tools that way. Upgrade yourself. Vibe upgrade yourself. I have it make me little simulated animations of things if they’re confusing. You can have it draw charts, do math, show you interactions so you can understand when the database gets hit or how an index gets formed. Make it teach you. That can be really good.

55:00 All right, we’re going to wrap up. If you have questions that we didn’t get to, email us at hello@aboard.com. We love talking to people. We’re thinking about doing some live coding streaming. Kevin, thank you for coming in. It was very valuable to have you here. We’ll do more events. We love to see people in New York City and we’re very grateful. Check us out and anything we can do to help you.