Paul Ford: Hi, I’m Paul Ford.

Rich Ziade: And I’m Rich Ziade.

Paul: And this is The Aboard Podcast, the podcast about how AI is changing the world of technology and software. And this is episode three—one, two, three—of AI Summer School, our little August wind-down, get ready for the year, little remedial learning. So—

Rich: We showed the agents the door.

Paul: Exactly. What have we talked about? We’ve talked about kind of the rough bits about how it works, how it’s not actually a super conscious being, and instead is a weird database. We’ve talked about how agents, what they are and how they operate.

Rich: Yep.

Paul: And now we’re going to just do something simple. We’re going to do it fast and we’re going to do it under expert guidance. We’re going to build an app with AI and talk about what it actually means to be building software with AI aboard.

[intro music]

Rich: And to help us do that, we’ve got our CTO, Adam Pash. Welcome, Adam.

Paul: Adam!

Adam Pash: Hello, welcome.

Paul: Hi.

Adam: Welcome me.

Paul: Welcome you.

Rich: Welcome you. Yes. It’s worth noting that we’re going to use Aboard to build an app.

Paul: I mean, we’re allowed to, but it’s also what we know best.

Rich: Well, we don’t have to apologize for it. Lean into it. Paul, you’re the president of Aboard.

Paul: I apologize for nothing.

Rich: Okay.

Paul: All right.

Rich: There are many tools out there that advertise a much faster, quicker, revolutionary way to build apps. We’re going to talk about them, and we’re going to talk about our approach. The reason Adam is here, we could have used Aboard without Adam, is he’s going to talk about what’s happening underneath the hood as we go through our process.

Paul: I mean, at this point, Adam has as much experience building AI-powered software platforms as anyone. So you’re getting it kind of, you’re getting the straight stuff. This is good.

Rich: 30 seconds, for the people that are discovering Aboard for the first time. What is Aboard?

Paul: Thank you for asking, Richard. Aboard is basically, I’ll tell you what it feels like and then what it actually is. It feels like you come in and you type a prompt. You say, “I need a CRM for my cat hat factory. You know, I’m selling lots of cat hats.” And it’ll build you one just like that. And it’s real software. It has a database underneath. It does all this stuff.

What we have learned about AI is that’s the first step, not the last step. There’s all sorts of things about software that we know as long-term software professionals that are pretty complicated that require human intervention. But we get that whole first phase, requirements gathering, understanding, like, we get stuff onto screen that you can really talk and react to really, really quickly.

Rich: Let’s do it.

Paul: Let’s do it.

Rich: Let’s walk the walk, as they say.

Paul: I went to aboard.com and there is a space here to describe the software you need. Let’s describe some software. What do we need?

Rich: All right. I’m a headphone company in Austin, Texas.

Paul: Okay. I’m going to type as fast as I can. Company in Austin, Texas.

Rich: I need a way for our customers to submit warranty and repair requests.

Paul: Okay.

Rich: Once submitted, I need a process so that my team can triage them and respond to our customers.

Paul: Look at how fast I typed it.

Rich: [laughter] That’s impressive. Very impressed right now.

Paul: It’s kind of freaky how fast I can type. Yeah. Okay.

Rich: I think that’s enough.

Paul: Let’s go with that. I will say this will make a, if you give us a paragraph, like a long paragraph, you’ll get something pretty full-fledged. This will make something pretty basic.

Rich: Yes.

Paul: Okay? So just, let’s set some expectations. Adam, I’m about to hit submit. I’m going to do it and you’re going to tell me what’s actually going on.

Adam: Yeah. Okay. So what you see now is, you’re in a basic chat interface. So the thing you just wrote went into that chat interface, and you’ve gotten a response. It looks like you’re having a single chat with some single entity out there. What it is, is actually, there’s a bunch of little agents who are responsible for different jobs in this.

So in this case, this agent’s for onboarding you into this process. And it’s saying, “Thanks for sharing the basics. Here’s how I understand your goals.” And then it kind of breaks down in three bullets what you said to it, in a little more detail, asking you if that looks like more or less what you want.

Paul: Yeah. So, I mean, the bot, or the chat says, “Hey, thanks for sharing the basics. Here’s how I understand your goals. Customers should be able to easily submit warranty and repair requests for their headphones.” So three or four contextual things like that, like it kind of states back what I just gave it.

Rich: Yeah, which is not, it’s worth noting, not typical. Usually you get results right away with AI. Here it’s actually having a dialogue with you and trying to gain more clarity around what you want.

Paul: And then it says, “I have everything I need to get started.” And it wants my name and email, so I’ll give it my name and email. Paul Ford, and I’ll make it, I’ll make my email, do-not-reply@headphones.com. So just to give it a little twist. Okay, so when you said agents, Adam, what you’re actually talking about are little programs that are running on our servers that talk to LLMs like Claude or ChatGPT.

Adam: Mmm hmm.

Paul: And then they get responses back.

Adam: Correct.

Paul: Then what’s happening? Typically, I would call an API and say, “Show me all the sweaters that are blue,” because somebody just is searching for blue sweaters and wants to buy one. So what’s different here?

Adam: Yeah, I mean I think you’ve probably in, I think, episode two talked about agents. Is that right?

Paul: Correct.

Adam: So we’ve got these agents, they have system prompts that sort of lay out the constraints and sort of guardrails for how they’re supposed to behave. And they have tools available for them to call as well. And those tools allow them to say things like, “I’m done with my job,” or, “Here is the contact information” of the user that they just submitted. So there’s, like, a handful of little—

Paul: So it’s just like a little program.

Adam: A tool is like a thing that an agent can invoke, can call out. You’ll see one later when we get to our roles and security step, you’ll see it in action. But the tools here basically, like, some of them are just, like, cool. They said they’re ready to go, so we’ll hand it off to the next step—right now we’re in the defining features steps. We’ve gone from kickoff to defining features. New agent, new job.

Paul: Let me be the bot, I’ll do a dramatic reading. “Thank you Paul. Here’s a high-level summary of the solution we’ll design for your headphone company’s warranty and repair process. One: Customer portal form, a user friendly page for customers to submit warranty or repair requests, including product details, issue description, and contact info.” Now I won’t read all five, especially in that voice, but it’s gone, okay, so our little agents have gone to the LLMs and they have sort of like figured out what features might go with a piece of software like this.

Adam: Mmm hmm.

Paul: And they’re saying, “Do you think that there’s anything critical I missed?”

Rich: And it’s worth noting that you’re seeing greater and greater level of detail as you go along in this process.

Paul: So what I have a sense of, and obviously we know this platform pretty well, is that there’s this very, very large kind of fill in the blank. It’s almost, to me, like the world’s weirdest game of Mad Libs. We have this sense of the data that we want to fill in. Okay? And, like, it’s a pretty big, complicated data structure that describes a business app.

Adam: Mmm hmm.

Paul: And what we do is, and then somebody gives us a prompt, and we try to translate using all these agents, we go to the LLMs and we try to find the data that would fill in that big sort of blob.

Rich: Yeah, I wouldn’t use the word data.

Paul: Okay.

Rich: Because I think people think of, like, actual data, like my—

Paul: Like my Social Security—

Rich: Like headphone products, right? With SKUs and all that. What we’re really talking about here is filling in the blanks of a spec. You’re filling in information.

Paul: So we’ve made the Mad Libs version of an app spec.

Rich: Of an app spec. Of essentially, we call it a Blueprint at Aboard. Essentially—

Paul: I mean, if you want to say what Aboard really is, we’re that technology.

Rich: We draw out a very detailed definition of what the software is first. And before we just rush to fill in those blanks, we want to have a dialogue with you, the user, to understand what you need. And this is all based on the premise that most business software—and it’s worth noting, we focus on, like, productivity and business software—have the same building over and over again. Relational data, roles and rights, business rules, integrations.

Paul: You know, who gets this? You know who understood this 20 years ago, before AI? Salesforce.

Rich: Yeah.

Paul: Because you log into Salesforce, you move cards around. They knew that, like, if they could get that sales processes, and—which is where the revenue comes in.

Rich: Yeah.

Paul: Needed to kind of follow a certain path, and have certain things. And they were able to sell that to million, probably hundreds of thousands of companies.

Rich: That’s right. And so let me, let me take a minute here to make the distinction between how a lot of tools think about software building with AI and how we approach it, and how others are starting to approach it.

Paul: I mean, Adam’s here. [laughter]

Rich: Fine. I mean, fine, Paul.

Adam: All right, so the spec, which we call a Blueprint, it’s a blueprint for an application. It describes basically all of the business needs for an application. So like Rich said, we’ve sort of made some decisions about, like, what an app entails. So there’s roles, which is roles and rights for security, who can access what data, what they can do that data. There’s data modeling. Like what, what fields do you need on your data? What are the concepts that you need to represent in your database? There are actions, which is business logic you can perform on your data. And then there is the UI, which is, like, how is this thing going to look? What sort of, what sort of UI conventions is it going to lean into? How’s it going to represent your data on a page when you’re interacting with it?

Rich: Yeah. Why not just start coding?

Adam: It’s a great question.

Paul: So that would be vibe coding. Like, why not?

Rich: I mean, there are a lot of tools out there. Bolt. Replit. Lovable. Where you type a prompt in and then—

Paul: It blows away your entire production database for the rest of your life.

Rich: That happens.

Paul: Okay.

Rich: But it’s actually very visually satisfying. You can visit any of these tools and the prompts on the homepage, you just see feverishly outputted code coming out—nicely formatted. They tab—they tab really nicely.

Paul: They build dashboards for you, everything.

Rich: So why not?

Adam: I mean, there are a lot of reasons. I think one of the biggest reasons is there’s no predictability. I don’t know what it’s going to spit out. It’s going to spit out something new every single time. Ours could spit out something new-ish. But the concepts are all the same. We’ve set up these guardrails so that we know, like, it’s going to hit all of the things that we know an application of this sort needs. And we’re going to ensure that it’s going to do it in a way that is predictable, that we can edit and change really easily. If you’ve ever vibe coded, which, I don’t know, do the listeners of this podcast vibe code?

Rich: Probably.

Paul: Some of them have dabbled.

Adam: It’s very common to reach a dead end where you start to say, “No, that’s not right. Please try again.” And it’s like, “Yeah, I see the problem here. I’ll fix that for you. No problem.” And then they do that and then it comes back and you’re like, “That’s still not right. It’s still not working. Please do it again.” And then you just do that forever. You now have a code base that no one understands, including your LLM, that if you want to continue forward with it, you have to basically read the entire thing and understand it, which is sort of not the promise.

Paul: If you want to have a drinking game based on Adam Pash, you just listen for the word “guardrails.” [laughter]

Rich: Yeah.

Paul: That is, that is the term—

Rich: It’s the most boring drinking game I’ve ever heard.

Paul: Not after, like, because I’ll tell you what? In about—

Rich: Ten guardrails in? [laughter]

Paul: In about five minutes, you’re going to be on the floor.

Rich: Yeah.

Paul: What I’ve noticed with, over the last, like, six months or so is this term comes up more and more and more. When you say guardrails, what do you actually mean?

Adam: I mean, we basically create, again, a specific that says, this is what our applications can do.

Paul: Mmm hmm.

Adam: Without us specifying it, it will not do it. So for example, I can’t blow up a production database.

Paul: And for context, a couple weeks ago, Replit, somebody got online and was like, “I’m building amazing things with Replit.” And then, like, a couple days later they’re like, “Um…it just destroyed everything.”

Adam: Yes.

Paul: And then the bot went, “Yeah, sorry, I panicked. Had a bad day.” So it really is like a very junior engineer. Why don’t we erase your database?

Adam: Yeah, because in order for us to do same thing, we would have to first say, “Hey, we want to enshrine a concept in our Blueprint that says, we want the feature for someone to blow up an entire production database.” So then we would have to first conceive of that and say, “Now we support this in our specification.” Then someone would have to go to the engine that runs our Blueprints and say, “Okay, now this has been specified. Please delete the entire production database.”

Rich: Yeah.

Adam: So like, the level of—

Paul: It’s totally possible, but literally, guardrails, like, humans are in the mix going, like, so—because we can assume that we’re not going to blow away the production database, because no human has been tasked with or would normally write a routine that would blow away the production database.

Adam: Yeah. In order for us to have made this decision, you two, would have had to, I guess, been playing the guardrails drinking game enough that you’re like, “Please, please add this feature to the Blueprint where we allow people to destroy their production data.”

Paul: Okay, so that’s—when we’re, guardrails means not just humans in the loop, but that the specification gets executed by tools that people built and understood.

Adam: Yes. And it means predictability.

Paul: Okay, so we don’t just feed this thing back to an LLM and say like, “Now go make them.”

Adam: Yeah. I mean, it’s funny, the Blueprint is like, it’s like a specification in the sense that a human could write it, except it’s shaped like data. But like, the actual content of it is what you would, if you’ve ever seen, like, a PRD, like, a requirements document, like a product requirements document, it has most of that information just encoded in the shape of data, which means that our app engine can then understand it and turn it into a running application.

Paul: As you’re talking, I’m filling out, not even filling out the form, chatting with the thing. And now it is, I’ve answered a few questions, I’ve said, “Hey, we have some Excel data and important stuff like this.” So this is a very accelerated version of working with a product manager who’s doing some business analysis, right?

Now it is building the app, and it’s saying things like, “A team of AI agents have been deployed to build your custom software.” It’s modeling, it’s optimizing, it’s designing. Is this all a bunch of nonsense that we did for marketing? What do we have here?

Adam: [laughing] So there are actually, you’ve been chatting, you’ve been chatting with these agents, but also in the background, there’s agents that are building this Blueprint.

Paul: Mmm hmm.

Adam: So they’re taking the ideas, they’re taking the things that you said, they’ve taken a sort of summary of what you’re asking for, and then they’re going through the steps. They’re saying, “Okay, these are the roles that you need for this application. This is the data modeling that makes sense for your application. Here are the actions, here are these UI.” And it’s basically turning all of those into the shape of this data schema we’ve been describing, and some of them are doing it at the same time. There’s, like, parallel work happening. We’re trying to make it as quick as possible, so you’re not sitting around staring forever.

Paul: So we’re about to look at our app and talk about it. We have this way of building software, we have vibe coding, where you’re like, “Hey, you write the code, AI, and you run it and let’s just see how it goes.”

Adam: Mmm hmm.

Paul: Are there other ways showing up? Like, this is a very open-ended question. But, like, our approach—I’m seeing, Rich, you were pointing out that Amazon is sort of doing what we’re doing. Which is fine.

Rich: They’re not—

Paul: Welcome to the party, guys.

Rich: They’re not really doing that, but what they’re doing is they’re—it’s called Kiro. K-I-R-O. I think Kiro.ai, I think, I’m not sure, but you’ll find it. And what they’re doing is they actually give you two paths. You can go right to code, if you want to just vibe code. Or you could go spec-first. And the reason they’re saying, well it’s spec-first, is if I have a spec, then I’m going to do a better job coding, effectively.

Paul: Mmm hmm.

Rich: So that’s where we are different, in that what they’re doing is they’re preempting, rushing to code by giving the LLM more context, by effectively handing it a document that describes the software. That’s what they’re doing.

Paul: Ultimately, an AI is writing the software.

Rich: Ultimately, AI is writing the software.

Paul: That is where we are different.

Rich: That is where we are different.

Paul: Humans have created the component. Now, it doesn’t mean that when we’re putting stuff together, we wouldn’t use AI tools to speed stuff up. Or if we were writing a component, we might not use some AI—we might use some AI to, like, speed up the process.

Rich: I think it’s actually a lot for people to process.

Paul: It is.

Rich: It is to understand our process.

Paul: Yes.

Rich: I think what we’re better off, like, punctuating with this podcast is that the more context, and to use Adam’s word, the more guardrails, and the more clarity you give AI in terms of what it needs to go do, the more predictable it’s going to be. Now, it turns out we’re still very early days. And even if you gave it a pristine specification, AI veers off. It just can’t help itself.

Paul: Yeah, we’ll build roughly the same application for the same prompt, but it’s a little bit different every time.

Rich: It’s a little bit different every time. That, I think, is an overarching outcome that’s happening with AI, in that you can’t bring goals to AI. It just doesn’t have the sort of zoom out, bird’s eye view, let me think holistically, and then come, zoom in, and do the work. It doesn’t do that today. And that’s why we took a very, very different approach.

Paul: I think one thing we’re saying, and sort of for the AI Summer School point of view, keeping humans in the loop is absolutely urgent. It’s, like, you can’t—everybody seems to fantasize that you can get rid of people. And what we’re learning from talking to business customers and talking to people who really do, and they want to work with us and they want to work with these technologies, they don’t want that. They actually don’t want a whole bunch of AI slop just kind of going out in the world, even if it could conceivably save them a lot of money. They don’t trust it, and they know it doesn’t really kind of seal the deal.

Rich: We’re making a mistake here, not AI. I don’t think this is an AI bug. I think it’s a human bug. And the human bug is this: I’ve just, down the street from my apartment, they’re building a big apartment building. And they closed my street for two days.

Paul: Like, massive, like 10 stories.

Rich: Massive. It’s going to be hundreds of units. They closed my street and the cement trucks showed up. Like they’re, they’re finally pouring. You know, the steel rods are in and they’re going to pour the foundation.

Paul: Yeah. They go down like 80 feet.

Rich: And it’s, it’s something, because it’s a massive amount of cement getting pumped through. Right? And a lot of people are there, a lot of people in hard hats are watching this process. And I’m thinking to myself, okay, they’re pouring this cement and then the architect who’s on site walks up and says, “Oh my God, the elevator shaft is 20 feet to the left.”

Paul: Doesn’t matter.

Rich: The cement’s been poured and whatnot. Right? And so what you’re really—rushing to code is the equivalent of deciding you’re going to build an apartment building, calling the cement guys, and pouring, and then saying, “Hey, wait, I need the elevator shaft 20 feet to the left.”

Paul: Well, then what are we doing?

Rich: For months, they drew up those blueprints, thought about the foundation, looked at a, probably a small-scale model, walked around it, considered—you know why? And this is something I’ve been saying—

Paul: There’s a process in construction. Like, there’s a set of evaluations before you do something.

Rich: There’s a set of evaluation—

Paul: The city is involved.

Rich: Exactly. To me, when you vibe code, you are rushing to pour the cement and you can say, “Hey, do me a favor, move the elevator shaft.” It’s very hard to do.

Paul: Wait a minute. Okay, great. That’s a good, thoughtful thing. But we just built a business that just in about five minutes, spun up a headphone-management tool.

Rich: That’s right.

Paul: Okay? So it looks like we just put a lot of cement.

Rich: We didn’t. We did in the end. But what we did for the first five minutes of this process was, as Adam was describing, is that we simulated the architecture, the data model. A lot of pre-planning happened which, like, dramatically narrowed the set of options at the end.

Paul: I have a story for you that’s relevant to the previous metaphor. The building that going up in your neighborhood is really big. 10 stories.

Rich: Huge.

Paul: It’s distinct. It’s its own building.

Rich: Yeah.

Paul: When I moved, like, a couple places ago, I moved into an apartment building. It was a condo. Bought a place. And it looked exactly like five other condos.

Rich: Yeah.

Paul: Around the, around the neighborhood. Because the city had approved one set of plans.

Rich: Yeah.

Paul: Because it’s so hard to get stuff built in New York for the exact reason you described. Like, there’s a lot of systems here and you can’t just dig into the ground and so on and so forth.

Rich: Yes.

Paul: So they’re like, “If you build one of these, it’s approved.”

Rich: Exactly.

Paul: If you get a lot of a certain size.

Rich: Exactly.

Paul: And it was built for, it was kind of for a lot where there had been a house and then you wanted to put an apartment building.

Rich: Also all of the de-risking is baked in. A lot of the safety stuff’ in place. It’s easier to go back to the same folder that has those files.

Paul: So that’s a year. Right? Like, that’s a year that they spent building and they could start making money on selling the units.

Rich: Yeah.

Paul: Instead of trying to get approval to make something really distinct. And this is for a pretty generic apartment building.

Rich: Sure.

Paul: In a non-great neighborhood in New York City. Right? Just so, so that to me feels like what we’re doing.

Rich: Yes.

Paul: The spec is our set of pre-approved architectural plans from the city.

Rich: Yeah.

Paul: You can build a business application along these lines, and you can get pretty predictable outputs, which is the data will be clean and transactional, users will log in through Google Authentication or simple tools. What’s the other stuff that you kind of take for granted in a business app, Adam?

Adam: I mean yeah, data access is a huge one. Like, who can see what data and what can they do to it.

Paul: So roles and permissions.

Adam: Right? And if I were vibe coding, that would be one of my biggest stresses, honestly.

Paul: Mmm hmm.

Adam: The UI, frankly—if you’ve ever vibe coded, like, if we’re looking at a sample app right now.

Paul: Okay, yeah, let me tell you on the left, I’ll describe it. It’s called Headroom Support. It looks like a business app. It’s got a left nav. On the left are things like support requests, customers, users, products, statuses, priorities. And so let’s just, I’m just going to do one support request. It’s a Kanban board, goes left to right. So we built software here, and it says, “Microphone failure on Drop + Sennheiser PC38X. Customer reports that the microphone has suddenly stopped working.” And it’s got warranty information, and so on.

Rich: So this is, it’s worth sharing. It poured in sample data so that app can look recognizable.

Paul: Okay. So an LLM made a bunch of—so first of all, we have, it made us a spec for a headphone customer service tool.

Adam: Mmm hmm.

Paul: Then it said, “Okay, now that I have this spec, let me fill it with some sample data that the AI also generates.”

Adam: Mmm hmm.

Paul: And now it looks pretty real.

Adam: Right.

Paul: Okay.

Adam: And then what I get is, with that sample data, for example, you’ll see it’s not just, like, flat data that’s sort of, like, generic or whatever. It’s very specific, and it also has relationships, like, relationships between data, so that you can link things together, you can have, like, really robust sort of relational data, which is what basically everything on the internet is built with.

Paul: Okay, so this is just, so it spun up a web app.

Adam: Yep.

Paul: Okay. And all right, so this is our point of view on building an app with AI. You could have it just, you can go to a vibe coding tool like Replit and you can have it write you some code, and you can put that code on GitHub or deploy it or do stuff with it. And that’s—so that’s like having a programmer.

Adam: Mmm hmm.

Rich: We’re starting to see other approaches materialize out there.

Paul: Yeah.

Rich: It’s still very early days. This sounds like—this whole podcast sounds like an Aboard pitch.

Paul: Well, no, no, this is—we’re not saying you can have a programmer. We’re saying you can have a product manager.

Rich: You can have a product manager, but then the product manager hands it off to a platform that actually ships the first cut of the software. Now, we know software isn’t always right. It’s never right out of the first cut. There’s changes you want to make, but the cost of change, which is, talking about moving the elevator shaft, is always very, very expensive. And what we’re trying to do is set you up so that you can make those changes without wading through the code. Changing things by touching the code first without clarifying what you’re changing, right, is pain. It’s pain for humans, it’s pain for machines, it’s pain for AI. It’s hard. Right?

Do you think 12 months from now, two years from now, five years from now, we can get the full app without people coming in the mix and having to tweak and turn screws? AGI? AGI?

Adam: I mean, my answer is a qualified, like, yes. But, like, with the understanding that it’s actually no. [laughing] You can take it so much further. Like, we will continue building out our specs, so it can represent more and more concepts, more and more ideas.

Rich: It’ll eat away at more and more of the human work.

Adam: Exactly. But ultimately, like, I mean, the human work becomes what it’s always been. There’s still people. You have to talk to people, you have to have, like, get their feedback, you have to see things that they don’t like about it and adjust it.

Rich: They’re the ones that are going to use it.

Adam: Yeah.

Rich: So you don’t know exactly. Like, “I got a weird ask, when it comes in from Minnesota, there’s a law there around warranties and you can’t turn them away,” or whatever.

Adam: Yeah.

Rich: There’s always weird stuff that shows up.

Adam: If you’ve ever built anything for anyone, like, the hard part isn’t the building, it’s the like, relationship and the communication and the understanding and the getting on the same page.

Rich: It’s always so incredibly specific.

Adam: So it’s always, there’s always that component of it. You’re never—and then, and individuals aren’t built to make products, like, a user from some company who doesn’t build products for a living, they don’t know the best way to do it, and they shouldn’t.

Rich: No. They’re just telling you what they need.

Adam: Yeah.

Paul: I can sort of simplify this a little bit. Which is it’s such a vast industry that there will be one or two tools where you vibe code. Just like Airtable is a really powerful way that people level up from spreadsheets and they build database-powered applications.

Rich: Sure.

Paul: It is a $10-billion company and people run their businesses on it.

Rich: Sure.

Paul: But the entire economy doesn’t run on Airtable, because for various reasons, it’s just not always the right solution. Airtable would tell you that, no, actually we are, right?

Adam:  And I guess you’re going to see vibe-coding tools and you’re going to see people like Aboard, and we’re going to say, “We’re the best decision that you will ever make,” and people will go to us and to others, “No, actually I kind of need it to be like this one over here.”

Rich: I mean, the best way to look at this is the Salesforce world. Salesforce, if you take it exactly as it is, as a shrink-wrapped product, you would need literally an entire economy around implementations around the world. Like, many, many billions of dollars are spent dealing with the delta between what Salesforce is when you take it out of the box and what people actually want. An economy is around—multi-billion dollar consulting firms. There are countless numbers of them around the world. Their whole job is to close the gap between what Salesforce sells out of the box and what customers want.

Paul: You know what we’ve learned, AI is a technology. It is not—it’s very different, and it’s very exciting, but it is a technology. And this is year 50 of plain-English programming, and, we’re going to be able to, you know, you’ll just tell the computer what you need and so on. We’re closer than we have ever been. This is really, it is an exciting time. Every time we get close to, like, no, you just think it and it happens? A gap opens up and people are like, “Actually, it’s just missing this one thing.”

Rich: Yeah.

Paul: And humans need to get back involved. And that’s Salesforce. Like, that is every software as a service tool, and then they end up adding, like, a special little API so that you can customize it endlessly and so on. So…

Rich: That’s right.

Paul: For the purposes of summer school, building a business app. Building an app with AI, okay? You can make a lot of progress. You can get way past prototype phase. You can get something that really works. You should vibe code. You should play. You should—

Rich: Play.

Paul: But when you go and you tell your boss, and your boss says, “Hey, we can fire all those engineers and we can just do it purely with one of these tools,” what would you say? Hey, Adam, I don’t think, according to what you just told me here, I can get rid of 20 engineers and I can just use this instead.

Adam: I mean, this being Aboard?

Paul: Mmm hmm.

Adam: I mean, look, Aboard, we actually have humans involved that can, like, help push things across the line for you. If you’re just vibe coding, I guess it’s like, it’s a real There Be Dragons situation. Like, you can, you could potentially replace those—not hire those people. Let’s say you’re starting from scratch, because vibe coding is very much about starting from scratch. So you build the app that you think that you want from scratch, and maybe you even get it far enough that you, like, you start running your business off of it, and then you need something, or you make a change and it’s not working. You blow up your database or even, like, less catastrophic, you…just, it’s just not working. It’s not doing the thing you need.

Paul: Log-in doesn’t work.

Adam: You have to now, like, find an engineer who has to come in and has to, like, read this entire code base that’s been made by a machine, has to understand it, and then actually work on it, and then you’re probably never going to get rid of that person. So, like, ultimately, I just, I don’t see it. I don’t see it happening. [laughing]

Rich: I think different jobs with different titles are coming on the other side of this, because I do think these tools do change the game. I do think deconstructing the steps of what you’re trying to do? Forget Aboard for a second. These tools do accelerate a lot of things. A lot of the, like, ugly, boring stuff that you had to deal with can be sprinted through really quickly. But if you’re not thoughtfully thinking through how those pieces click together, you’re going to get in trouble today. Again, all of this, by the way, Paul, will be moot because next week’s summer school is about AGI. And there’s, we’re going to talk about products like DreamCatcher.ai that monitors your sleep, and then when you wake up in the morning, there’s a new app on your phone.

Paul: We’re not going to talk about that.

Rich: Oh, shoot.

Paul: All right, so…

Rich: Fine.

Paul: You know, the truth is we don’t really need to tell people to go to aboard.com after this episode because we just kind of did it.

Rich: Let’s not pitch aboard.com.

Paul: But if you need us or you want to talk, or you have questions about summer school, but you take the lesson that—it’s funny, as a software company that’s delivering AI solutions, humans in the loop, that is a big part of your, that is your summer school lesson. When you go back to work in September?

Rich: Yeah.

Paul: And they tell you that, no, you are going to get replaced with AI? You should cock an eyebrow. I don’t know if that’s real.

Rich: Not today, that’s for sure. Follow us on LinkedIn

Paul: YouTube. LinkedIn, YouTube, and…in your hearts.

Rich: Like and subscribe, and turn on notifications. This way, every time there’s a podcast, your phone will buzz. [laughter]

Paul: That’s not cool. I don’t like when I get the notifications about myself. That’s not fair.

Rich: Come on, man, lean into this. Lean into it.

Paul: Let’s market. Hello@aboard.com if you need us. Adam, thank you so much for coming on.

Adam: Yeah.

Rich: Thank you, Adam.

Paul: All right.

Rich: Have a good week, everybody.

Paul: All right, one more episode of summer school and then we’re back to work.

Rich: AGIiiiiiiiii.

Paul: Bye.

[outro music]