Enjoying this issue?
Get tomorrow's AI & engineering digest in your inbox — hand-picked, summarized, and always spam-free.
TLDR
Dave Ablar, a 10-year Python veteran, now writes zero code by hand — everything goes through Cursor or Claude Code. He estimates a 10x productivity gain over 2022 and argues that the real bottleneck for builders is no longer technical skill but awareness of architecture, security, and how to align an LLM judge with human taste. The conversation is a practical guide for non-technical founders who want to build and sell software using AI agents, with concrete advice on database choice (Supabase), firewall rules, and avoiding spaghetti codebases.
Key points
Dave Ablar says he no longer writes any code manually; all development goes through AI coding agents.
He estimates a 10x productivity improvement over 2022 and 100x over when he first started coding.
He recommends being a generalist rather than a specialist because AI agents can outpace human coordination.
He advises starting with a personal tool and scaling up, rather than jumping straight to a commercial product.
He explains using an LLM as a judge for subjective quality evaluation, trained via human alignment data.
He emphasizes basic security practices: Supabase with row-level security, strong passwords, firewalls, and environment variables for secrets.
Tools mentioned
Techniques
- LLM as a judge
- intent-driven development
- vibe coding
- row-level security
- firewall rules
- environment variables for secrets
Stop scrolling. Start reading smarter.
Receive the day's most important AI & engineering updates in one concise email. No spam.
Transcript (captions)
So you've been coding in Python for over 10 years now. How different do you view the software engineering space now that we have all these AI tools? >> I don't write a single line of code
anymore. Not a single. So everything goes through codecs or through cloud code. Think about any skill you would learn. You're not going to start at the elite level. But right now we all start
with these same really great tools that can help us produce code. >> If you had to put a number to it, how much faster do you think you're able to move now? Well, compared to when I was
just starting out, probably 100x, you can build useful stuff with one prompt. Heck, you can even build entire software products that you could sell even if you have a limited technical background.
>> Do you have any examples of maybe landmines that you've stepped on when trying to scale something, >> the stakes get bigger and bigger and bigger as you start to build software
that's used by more and more people, there are certain obligations when it comes to data privacy and protection, security breach. That's one thing that you cannot take back. Once those emails
and that personal data is leaked, you can't go back. >> If I was starting today with no technical experience, I would be most excited about this.
>> All right, Dave. So, you've been coding in Python for over 10 years now. Your team has delivered 50 plus AI solutions with Glido. You are shipping new features and updates like every week. I
just want to know how different do you view the software engineering space now that we have all these AI tools. >> Oh man, what a question to kick this off with. Well, obviously it's completely
different. It's completely different. What happened over the past three years and especially what happened in the last year is just wild. It's just crazy in terms of what we can do right now. And
we're all experiencing this, right? We're all using these tools. We're all producing lots of code. We're building. And so first of all, it's like really exciting. So if you ask me like what is
mainly different from when I started out back in 2013, so like over 10 years ago already, well, first of all, coding was really freaking hard and learn and learning and learning to code as well.
And you would just spend so much time working on this tidy little program, looking up Stack Overflow, and then trying to make stuff work, right? So you could build small little things and then
if you worked on something long enough you could build something useful maybe right now fast forward in the world that we live in today you can build useful stuff with one prompt and we all know
that we see it on your channel like every week just one prompt and you you can build stuff. So what that then also means is that we can now just think bigger as developers, as builders, and
we can now do stuff and build stuff that just wasn't realistic or possible a couple of years ago. So that means we can build automations for yourself, for personal productivity, for your company,
inside the company, for clients. Heck, you can even build entire software products that you could sell even if you have limited a limited technical background. That's now all possible and
it's getting faster every week. >> If you had to put a number to it, how much faster do you think you're able to move now? >> Well, compared to when I was just
starting out, probably 100x. Well, that's not fair because I was a complete noob. But let's say let's do a little bit more of a of a realistic take. Let's say we go back to 2022.
At that time, I was already working as a freelance data scientist, data analyst for like two or three years at that point. So, I was professionally writing code mostly Python code almost every day
for already three years. >> Okay. If I look at that point right now and see like how much I could ship and produce and do and all of that compared to what I can do right now, I would I
would still put it like a solid 10x like a solid 10x of actual useful like production ready code that you can ship and on some projects is maybe even more because I can now also work on projects
and work with languages that before were just not possible. So I come from a Python background, data scientist, later AI engineering. So I used to make backend systems. But if you were to ask
me to build like a a shiny like front end or dashboard, I have like I have never written a single line of JavaScript like actually in my life pretty much. I only started to pick that
up once the coding agents were there. I was like, "Yeah, like let's just try it." Right? So that is I think a distinction like like a solid 10x on on the work that I already did
professionally but like probably even more than that on other like possibilities that I just couldn't do before. >> Gotcha. So before kind of preai
engineers would kind of typically specialize in either like more of the back end at a very high level like a back end or a front end and it was a very different way you thought about
writing that code. >> Oh yeah for sure. And you of course you have full stack engineers as well. But then even with full stack it would it was probably focused on like specific
languages and you know you back then you also had these like 10x engineers right like the the old legends of these and you have you had these like just crazy developers that could do it all but
generally speaking mostly people would either do back end front end security infrastructure they would have like one or two languages that they're comfortable with and that is now um that
that is now completely like flipped on its head. >> So now instead of really having to specialize, everyone that's building can sort of be a jack of all trades there,
more of a generalist and and feel confident that they are kind of able to write high quality code in maybe some of the areas that they weren't super proficient in beforehand.
>> Yes, for sure. And I also would highly recommend everyone to try and do that because why is that the case? If you don't if you stick to specialization where of course
like there there's always value in specialization right so maybe people watching if you're working in enterprise let's say you're working for meta or Google or whatever and you're part of
like a highly specialized team >> you need to be top 1% of what you're doing right you need to be a hyper specialist >> but let's be real most people don't work
in the top 1% at mad at Google and all of that most of us are like we're building we like to build stuff and there you can better nowadays be a generalist because if you specialize
means you focus on one part of the project let's say means you also need other people to deliver something end to end to ship something and now your AI agents can move way faster than you can
communicate and keep can keep up with teammates so if you cannot work across the entire stack you are quite quickly going to hit a bottleneck where your agent is all already ready, right? It's
ready to ship. It's ready to work on the next part. But if for example, I don't know, there is not an integration with the front end because you only do back end or um you don't know how to work
with the databases and adjust your back end to the database, right? there is a dependency and that creates problems and I've seen really in the first of all the projects that I've worked on the teams
that I've worked with but also now what we do in glido and how we build glido that we have very of course still we have separate roles and responsibilities and we have more people but we give
people complete ownership on a particular aspect of the product where they can really ship from something from like start to finish on their own without needing someone else other than
like maybe a review from someone in the process, right? But not like actual work or code that needs to be developed. So I think being a generalist is the best way to go. It's now possible. So you can
just get better at um engineering, learn engineering principles and then which language or framework you apply that to uh starts to matter less and less. >> Real quick guys, I just have to take a
second to tell you about the sponsor of today's video, Code Rabbit. So, I know that a lot of you guys are building with coding agents now. And the code definitely piles up faster than you can
actually read it because the agent doesn't just touch one file at a time. It goes through your routes, your schemas, your tests, and your config in a single pass. And then you open the
pull request and GitHub gives you an alphabetical list of files. So, you're rebuilding the logic in your own head. So, Chainstack is Code Rabbit's review interface for that exact problem. What
it does is it splits the pull request into cohorts of related work and orders them by what depends on what. So, it reads it in the order that it was actually built. It opens on an overview
page with the summary, the walkthrough, and what's blocking merge, merge conflicts, and failing CI checks you can fix from the page in one click. There's also a timeline of every change,
approval, and comment. So, you can see why each decision got made. And the semantic diff view is the part that I would probably use the most because when code gets moved, a normal diff shows it
deleted on one side and added back on the other, bearing the real change. The semantic view shows you what actually changed. And you can ask the agent questions about the PR right on that
page. So, if you're shipping more agent code than you can read, there's a free 14-day trial. No credit cards required. The link is in the description. And huge thanks to Code Rabbit for sponsoring
this part of the video. Now, let's get back to it. I hear you. And I think that I'm really excited for this conversation because my audience is typically people that are coming from a nontechnical
background. And it seems like your audience is like the exact opposite. And >> one one thing that I hear from my audience like when you know I'm building stuff and I always sometimes wonder is
this right? You know cuz the only really source of truth that I can trust is my agent and that's not always going to be the source of truth that you want to trust.
>> I'm curious you know I want to zoom out and I want to start from the very beginning but real quick before we transition into that. I'm just curious how did you feel about the whole vibe
coding era like when that term really started to pop up and you as a software engineer there was probably so many alarms going off in your head when everyone was just picking up these tools
and started you know building apps and stuff like that. >> Yeah. So first of all I found it very exciting because the thing is I was also very much part of that whole vibe coders
journey even though I have uh experience as an engineer like I've said I was now also creating front-end applications fully custom code websites >> and I wasn't reading the code and I
couldn't care so like that would also put me in in a category of like five coder >> and even though that I technically know how to like set up an architecture and
how to secure your applications and all of that, right? That of course helps and that adds a little bit of um just extra experience to it. But I'm very much pro pro vibe coding. You just need to know
what the stakes are depending on what you're working on, right? Because >> if you're building if you're building your personal website, >> by all means like vibe away. There's
like zero risk, right? But it it's always about like risk versus reward trade-off. So I think it's awesome that everyone can build right now. I can build more. Uh that's super fun. Anyone
can build. And then the question is you just need to start being careful like once you let other users, other people use your software and especially when personal data is involved, right? So
that's that's I think where you need to draw kind of like a fine line in terms of like how far can you really just push things without really understanding what's going on and just going off of
the looks or like checking whether something works and diving deeper into hm let's see if this actually is secure because now it's not your only your own data that you're working with but it's
also other people's right so I think that is um yeah so that is kind of like my view on the whole vibe coding uh turn more or trend really that was going on. >> I hear you. Yeah. I mean it's very cool
because we see all of these stories of people, you know, from whatever sort of background that just have this idea and then they start talking to an AI agent and they're able to actually run with
it. And we've seen some pretty cool exits. We've seen people just change their lives because they've been able to take their idea and turn it into something. So, let's actually like kind
of walk through that process a little bit. If someone has an idea and they want to sit down this weekend and they want to start building that out, what how would you do that? What what sort of
steps and planning do you go through in order to start building some sort of app or software? >> Great question. So, so let let's walk through this. So,
first of all, you need to get a rough idea of how big the thing is that you want to build. Because when it comes to building
products and let's focus on software products uh right now to make it a little bit simpler right um there's different level different levels to things
>> okay >> so first of all I would say ask yourself the question is this something is this a software tool that just you want to use like because you want to have some type
of tool either something that you're currently paying for right now that you don't want to have a subscription for anymore or just something that doesn't exist or you want to combine m multiple
tools into one like is it something that you just want to use. So, so that that's like one question because another level could be uh for example, yes, it's for me, but it's also for example for people
within my company. So, maybe it's like a team thing, a company thing or maybe it's something where you say I want to build something and I want to sell that to other people. So, I want to have this
as like an AI agency offer maybe, right? So, I sell it to other companies or I sell it to other people. Mhm. >> And that could be partly productized meaning you build something you package
it and you sell it or it can be partly a surface right so there's you build something but then there's a surface element to it as well right so you help implement it into businesses this is all
related to for example like AI automation right as you know no single automation is ever 100% the same so there's also an a customization component to it and then the another
level is do you want to build like a software product like fully handoff that people can just jump on a subscription. They can just go to a website, create an account, download it, get on a
subscription, and use it. For example, what we're doing with Glido, right? So, there's these four different categories uh that that your ID could fall into. And why is that important? Because as
you progress up that ladder, I say I would I would position it as a ladder. Um it gets more complex and the stakes are bigger. Again, summarize, if you just build something for you, you use
it. Stakes are very low. Just just go and build. Just open cloud code and go for it. >> If you use it inside your team, other people use it. It's still considered
internal, right? But you may already want to be a little bit more careful like who's going to use this? What are what kind of like data is going to be in this application? Now then if you sell
it to to uh a company there's even like a legal aspect involved right because you probably have a contractor's terms of service there is certain there are certain obligations when it comes to
data privacy and protection so there's a bigger risk >> and then the and the other level is the like when you actually build the software product and you let um
consumers use it we have the whole idea of data privacy and and personal rights and all of that when it comes to data so and and probably more people using it. So just the risk gets bigger. So um
let's pause there for a second because that that's what I think uh it's good to start there. >> Um so was that all clear? >> Yeah. So it sounds like before you start
building you want to kind of have an idea of essentially you said how big and that makes me think like how many how many people will use this? How many hands will this touch? And would it be
fair to say that a good way to get started is you kind of start on that first rung of the ladder where it's like I'm going to build this first just so I can use it. And that's sort of the way
I'm thinking about it. And that doesn't mean that later if I wanted to have my team use it, I couldn't scale up the back end because, you know, it sounds like as you move up the ladder of
requirements and people, you have to think about other things like the architecture a little bit more and the database and just making sure that it can handle this stuff, the privacy. But
it's totally fine to start off on that first rung and then when you need to move up, you can start to do that, right? It's not like you choose, okay, this is going to be a personal tool and
then later, maybe six months later, you realize you want to scale it up. You're not like stuck, right? You're always able to continue to move up the ladder. >> Yeah, I think that's a that's a very
good clarification because of course you can always like make the ambition bigger, right, of the project. And I think one of the tr uh one thing to watch out for is for example like
skipping levels and being someone for example no technical background and jumping straight into building custom software and then selling that to people and letting companies rely on it. Right?
So there you skipped a couple of steps in terms of like your homework in order to figure out okay what does this look like? What does this mean? What data is flowing through it? So I think that is a
a very like natural way to progress in there because you're totally right. So when we make that a little bit more kind of like tactical as to what's different right there is not much different
nowadays in terms of the process it is still even for my projects like I don't write a single line of code anymore not a single so everything goes through nowadays either through through codeex
or through cloud code or even through grot depending on kind of like who has the best models so everything goes through the coding agents so that's also interesting like for the audience uh
watching that I think this is the very first time in history where someone with zero coding skills and someone who has been doing this for over a decade use the exact same tools and the exact same
process which is quite quite wild to think about it right now just like now that I'm explaining this I'm just like making this up but now I think about it it's actually pretty wild because think
about any skill that you would learn right if you just start with, I don't know, playing basketball or anything like that. You're not going to start at like the elite level like your exercises
and what you do is going to be way different, right? But right now, we all start with these same really really great tools that can help us produce code. So the only thing that is like
different is what instructions do you give it and how do you review the output, right? And then that's the skill. That is where like the reps come in and that's where also the stakes get
bigger and bigger and bigger as you start to build software that's used by by more and more people. But I think that is like very motivating for like people to watch. Like you have these
tools you can jump on like a $20 subscription. You probably want to get to like $100 and $200 otherwise you know you run out. >> You'd be sitting there all week like man
when is this reset coming? You probably want a little bit more, but like that for most for most people that is within reach and from that you can start you can start building and you can start to
build really really cool things and >> yeah start building with something that you would use that you think is cool and then start to make it make it better and then over time um and we can we can get
into this deeper if if you want to but there are like for for for the most part VIP coding is totally fine. But there is one aspect of it that is security where you just cannot afford to make the risks
because let's say even if you build an application and it's like vibe coded and the architecture is bad like what's the worst thing that can happen like people will use it and at some point like it
will like get a little bit slower or it will break but you'll notice right you'll start fixing it. So there's nothing really like so like and that is something you'll be aware of because
people start complaining it's like huh maybe maybe we need to revisit that but like a security a security breach that's one thing that you like cannot take back out sorry we'll fix it in the next
version you know like that's that's out once once those emails and that personal data is leaked you can't go back so that is one aspect that uh we could get into that if you if you want to but that is I
think the most important thing as you level up security >> totally totally and I definitely want to get into that and I think we'll just kind of keep working our way up here.
That's why I love the ladder analogy because you really do have to earn your way up to the next rung. You can't just jump from the ground to rung four or you're probably going to fall and you
you just have to start from the bottom again. So >> yeah, >> it sounds like the first piece is kind of you figure out how big and you you
think about high level like how big am I building this and how much risk is there involved? >> Yeah, >> once you kind of have a good idea of
that, >> what is the next step to start that building process? What does it look like for you to sort of map this out in your head to sort of plan out the
requirements? How does that process look? Or if that's not the next step, what is the next step? >> Yeah. No, that is that is definitely the next step. So, uh, when you have this
idea and when you want to start just just building, um, what I've observed over the, uh, past year, pretty much one year ago, everyone was really like pushing
um, spec driven development, the importance of plans, and you can probably remember this, right? Um, and I've just found that as the models get better and better and better and the
models that we have to right now like the the planning phase and the generating the specs becomes like it becomes less important I found. >> So what does that mean spec planning?
>> Uh yeah. So spec spec different development was is uh refers to kind of like a way of building software where you first use AI not to produce code but to produce specs and what are specs?
specifications. So you describe how the project or the product should work in natural language. So you and and you could and you would use AI for this. So you would pretty much say like I want to
build XYZ, I want to build this and then let's create some specifications for this. So it would say the AI would start to create a document. Okay, it product needs to do this, it needs to do that,
it needs to do that, it needs to do that, etc. And you would create this this plan um and the specifications. And then once you had all of these documents
only then you would read those and you would approve those and then only then you would like go into uh development mode and you would actually ask your agents to start uh writing the code and
to start building the thing. That was pretty much the meta um one year ago when we just got these like big breakthroughs with cloud code open 4.5 4.6 six, right? Like the good old glory
days of AI AI agents. Um, and now it's just like getting crazier and crazier. So, um, the thing is there's still value in that and I don't think it's wrong to go through that process even just to
help you think about what it is that you want. But the thing is what I find myself doing most of the time right now, I just like I go straight into building and like I let the model figure out what
it like how it should structure things. And there are of course certain kind of like standards that I kind of like steer the model towards when I'm for example working with the Python programming
language just because I've so much experience with that. But like the summary of this it gets easier and easier and easier to just tell it what you want and it will start to it will
start to build it will start to build it. So coming back to you started this question. So let's say people have this idea and what is the next step? I would say right now get on codeex, get on
cloud code, use GPT6 Astra or Opus 5.5 which are currently like two top frontier models. Opus 5.5 really good so far. >> Super good.
>> Super good. And just tell it tell it what you want to build. >> And and the Yeah. And as as simple as it sounds for people just starting out, there's not much more to it. And then
you just look at the output and you tell it what you like, what you don't like, and that will already get you really, really far. >> Yeah. And and the cool thing about that
is that I think humans are really good at explaining what they want. Like, you know, it's easy to say, I want this, I want this, but you really just have to sort of go through that grill me process
where you have AI interview you about >> what specifically do you want? What do you not want? What does this look like? What is your vision? And I was just talking to a few Google engineers and
and they were explaining this as saying like >> the plumbing, the boring stuff on the back end that that we used to have to think about
>> where humans used to have to set that all up before they could start to be creative and think about the vision. That plumbing is pretty much just taken care of now because you explain what you
want and the agents know how to go set up all that stuff so that you can really just they kept calling it intent driven automation or intent driven engineering and I thought that was pretty cool. I
wanted to see do you agree with that? Do you agree with that narrative or that mindset? >> Yeah, for sure. I I really like that. I like that term intent driven. And um
what does it mean? You just tell the model what you want. Like you you have a certain intent as a builder, you have an idea and you want to make that a reality. And the thing is often
when you start with something even though you might have like a rough idea of where this thing should go until you actually see it in front of
you and use it. Um you cannot really give the the best feedback I found. So you can like then that's why I've moved away from like big plans and specs and all of that. just
like just just build me this and then I see it and I look at it and I test it and it's like hm this feels a little bit off or can we make that faster or this doesn't really look right like whether
whether it's visual or actual logic right or the output here is wrong like can we fix that right and um that's also now the pretty much the like the development process with glido the tool
that we're building right now it's mostly like ideas and then just using natural language like it's actually fun. We're using glider to build glider, right? So, we use glider to talk to it.
It's like, hey, can you try this, you know, like let's build it out. And often I do that straight on the um like production codebase. I'll do it on a separate branch, right? So, it's not
like immediately shipped, but like there there's there's not even like a playground. I just create a new branch and it's like build it and then I can directly see what it looks like in the
product itself and then I can iterate on it. And then that's I think uh a perfect description of like intent driven development. You just tell it yeah >> what what you want and it will build it.
>> By the way guys, I've got this completely free SOP for you about getting your first a automation client. It's going to go over the exact steps that has been proven for hundreds of our
AIS Plus members to get their first paid gigs. It goes over the one sentence service pitch that can get you started today. Why your first client should cost you money. The 5-minute video that
answers can this person actually deliver before you've actually received any money. what to do when you have zero case studies. There's so many good things in here that are going to help
you out. Even if you already do have clients, I would recommend grabbing this because like I said, it's yours completely free. So, if you want to grab this, there's a link for it down in the
description. Let's get back to the video. That's so cool. It It's really interesting how you kind of pointed out how the meta a year ago was doing all this kind of planning, but now you say
you're you're you're kind of building first more and then really just getting it in your hands and playing around with it. I remember when I used to use plan mode first for everything even not even
if I was building automation but I would just use plan mode default just to sort of brainstorm and it sounds like maybe do you think the models are just getting better and the models and harnesses are
getting better so that's why the med has shifted or >> yeah it's just and it's it's for sure the combination so that's also important to um to understand um and I think even
like people that are actively working on clawed code on the development I think I even saw this on X like entropic engineers mentioning this as well that plan mode is not even really needed
anymore because yes like models get better but um it is essentially also within the harness because what what what is really a plan right it is first >> essentially getting you give it you
always start with a goal or a task I want to build this and then before it would help the model to first plan out so be before just getting into like uh code generation
it would first like zoom out a little bit. Okay, let's just first reason over this like let's see if everything makes sense and then once we have the plan I can now execute on of it and it feels
like um the engineers working at OpenAI and Tropic is essentially by making those models and the harnesses better and more capable they just merge this process as like a trait that the model
and the harness combination already have without like turning the plan mode on H that makes sense. So now let's say we have started to throw in some of the I want statements and now we're getting
some stuff back. >> Yeah. >> In automation, >> you know, we run a lot of evals and we see, okay, cool. We have this, you know,
we have these inputs, we have these outputs, this is, you know, 90% correct. Let's make some iterations and and see if we can get this to like 98 99. How do you think about from a, you know, an app
perspective or a software perspective essentially the eval process? What does it look like to verify? What does it look like to see if the things actually work rather than just assuming it does
or having you, you know, go in there and click through a few times? >> Yeah. So, this all this of course depends very
much on what you're uh building, of course, because uh output quality. So, what what does good look like is always tied to the application that you're building, right? So, let's talk about
glido. What does good look like? Well, um, Glido works well. If you press a button, people can talk. That will be processed in under 500 milliseconds and the text will be pasted back into your
application like exactly the way you wanted to see there, ready to paste text. So, it will correct some errors and all of that while leaving generally most of your speech intact. Like that's
what people want from a dictation app. So it starts with that getting clear on what does good look like. Then the second question is can we find examples of that? Can we find examples
of cases uh where it went well? And in glido for example uh we don't use user data because we like really designed this application to be private by design but we use the data of uh uh our uh our
accounts internally meaning the developers that work on glido right so we use our own kind of like data sets that we collect we have a bunch of people so that data set then also grows
and in there we can run these experiments so we have data sets in there like when we put this into our system we expect this to come out and and that essentially then becomes
becomes an epha, right? Uh that you can run and that you can check against. >> Uh the cool thing is that as models and harnesses get better and capable, >> whenever you have some data and when you
don't have some data, you can even ask the model to generate some realistic data for your use case. And again, whatever you're building, whether that's a chatbot, an automation of any sort.
And once you give these models an objective in terms of like here's what I want this to look like. Here's what I want you to improve on. I want it to be faster. I want it to look more like
this. I want it to be better. I want to have less errors. Once you give that and let that run in a loop and that pretty much means you tell it to go and improve it. Use the data, generate more if
needed, do research, use sub agents, run this in the loop until it gets better. like it's a very messy prompt, but even just saying giving that prompt to a model like Opus 5.5 given the thing that
you're building will kick off this like research experiment well where it will go on it and we'll try to find ways to to make it better. So what we find over and over again is like the better models
and harnesses get, the easier all the things that we have to do as developers get. planning, spec different development, quality assurance, debugging, security, evaluations,
you know, all of these things also get easier as the models get better. So, I think that's a really interesting uh property that that I found uh and also just something that you need to be aware
of because you do need to ask the model, right? So, you do need to be aware of like what are Eiles? How can I set up a loop in order to make my application better? So just that realization
>> and asking it >> is is the right starting point. >> Yeah. So it sounds like defining what does good look like and that's something that you would do with
a human as well. You know, you're setting the expectations of what do you want? Because if you don't align with a human or an agent on what you're looking for, then when it comes back with
something that isn't aligned, it's maybe not that it failed. Maybe it's just that you didn't you weren't clear enough on that. Yeah. >> And then from there,
>> giving it a way to essentially verify that, you know, whether that's you verifying or or the agent verifying. I think kind of a combination of both. But >> what is good? Here's how you verify it.
>> And um what you were saying about this whole like loop, it made me think of when Carpathy's like auto research came out. And I think that's when I remember
having this big moment of like, wow, like agents can actually >> see their goal, prove it, and then keep researching and keep trying again until they hit it. And I thought that was
incredible. Now, I've got an interesting one for you to kind of stem off that, which is a lot of the best auto research or goal prompts or loops are when you have an objective milestone to make them
hit. >> What about how do you think about it if it's subjective? If it is something that's more like taste or, you know, if the definition of good isn't something
that can be objectively proven. >> Yeah. Um, that's very true. Whenever you have something that's very easy like it's either good or bad but because you have a data set with examples those are
the best scenarios or making things faster right so for glido we also have a lot of infrastructure that we need to manage uh models that we deploy um and there also code code and architecture
around that if you just give it an objective like hey here's what we're at right now in terms of latency you can test that by running a test now go make it faster
>> you know super clear because every time it runs an iteration, it can see am I above or below? Am I going to in the right direction? So, what if you have a use case that doesn't have this? And uh
let's think about an example of this to uh make it a little bit more tangible. So, >> my most common is like video editing and I want it to like I'm saying like yeah,
make it feel professional, make it feel engaging. It's like how does it know? Yeah. >> Yeah. Yeah. Yeah. So, yeah. Yeah. So like that that really is a tricky it's
really a tricky example. I I'll give you one more and then I'll also consider this one. >> Okay. >> Think about this. But um we have for
example also done a lot of work in customer support in customer care. And the thing is when a uh customer asks a question and the AI agent gives it a reply, right?
There are hundreds, thousands, probably even like millions of different ways that you could reply to a customer and they could all be correct or they could all be wrong because the final goal in
this case is that the customer is happy, right? So like they got a good reply. But whether you use a different word, yes or no, that is all um subjective meaning there can be there can be
differences. So one of the techniques that you can use for that is what you would call an LLM as a judge to run that at scale because and how how does this work right so like the um the best way
to to check the outputs of your AI agents when it's subjective uh the best way which is also the most expens expensive and non-scalable way is you you refle
the AI do the work a human refuses it and says this is not good, this is good, etc. But then what's the point of automating it? Because in the case of like customer care, if a human needs to
review every ticket, they could probably just reply themselves, right? Because it's probably easier to reply than to review and give good comments. So that's unscalable. But if you do that for a
little while, you could create a little data set around it. when the uh customer asked this and the AI said that the human said this is good yes or no because you know you start to collect
data and then this whole concept of an LLM as a judge is you use another language model so another like independent language model call or multiple calls or however you want to
set it up in order to review the output. So you let an LLM look at the let's say the reply to the customer and you let the LLM say is this good yes or no and why now the challenge is in the
beginning as you know like an LLM might say yes this is good or no this is not good but how but then how do you know that is good right so you like shift the problem from like an LLM that you need
to check to another so there's a little trick for that and that is uh essentially called creating alignment between the human reviewer and the LLM. And you can do that by let's say you
have 100 examples and you let the human review 100 examples and you you list all of this. You have an Excel spreadsheet for this whatever. This is like manual work. Nobody wants to do this. It's
unscalable. But you need to do this because this is where you can essentially capture the taste. So human will say I like that. I don't like that. That should be better. And now what you
want to do is you let an LLM run over all of that and you see where they where do they agree where do both the human and the LLM say this is good and this is bad and you'll get a score. So you'll
have a percentage. So let's say the alignment is 80%. Or maybe maybe even like 50%. So 50% of the time the LLM agrees with the human yes or no. This is baseline. And now once you have that
data this is where the interesting thing comes in. Now you can use AI again. So now you can say hey here's human data here's LLM data let's optimize the system prompt so we can create more
alignment you know now you can do loops so then the LLM is a judge is it's a system prompt and a model that's pretty much it and then um if you let an LLM review that like oh yeah I can see the
LM things a little bit different about this and this and that and I thought this was good but actually the human thought this was not correct so I'll change that in the system pro you run it
again alignment is at 75 5%. Cool. Let's do another round. 80% 90% 95 99%. And now if you have a large enough sample size and you do this occasionally to avoid model drift, you'll have an LLM
that with two degree of certainty agrees with how a human would review it. That's generally how it is done on real world projects. Coming back to your video editing example, you would follow a same
process, but I would say it's probably even trickier because assessing what good looks like in an edit or an animation or a cut, there are some things that are
obvious like some you can make an error, but if like a title has like a certain animation pattern or something like that and you don't really like that, that's tricky.
But it's mostly because of the LLM's ability to inspect the visuals, >> right? I think that's what makes it more tricky. So, as multimodal capabilities get better, you can apply this exact
same process even to optimizing and training your video editing agents. >> Mhm. Yeah. Yeah, I think the interesting thing there too is like let's say you have worked on refining this LLM as a
judge >> and it's really really good >> and then if you switch the model it might not be as good anymore because the model might interpret it differently.
But what's cool about that is you're putting in that time which is a tedious process because you're essentially creating these standards but then you can use sort of that loop that you know
auto research loop on it to have it continuously optimized which I think is >> very very cool >> and it's it makes me think of it makes me
think of like sports teams. They'll have these scouts that will go out and watch, you know, high school games or college games or whatever it is. And there are stats like height, weight, you know, how
many times can they bench press 225. There's stats like that that are objective. But then that's also like the team trust the scouts opinion to say this person has like this guy has
potential. He's explosive. He has great game sense. Like that's stuff that you can't pick up on paper as much. And it's like how do you get your LLM to have the taste and the judgment of that scout or
of you? You know what I mean? And I think that that is >> super super cool. Um, now as we transition into now we've been running some
verification, we have something that we trust that's working. What if we want to turn this from a oneperson app or a team app, what if we really want to scale it? Like what are the things that you start
thinking about? Um, and we don't have to get super super technical, but what are the high level things you start thinking about around infrastructure, databases, security,
that sort of things. And then if you have any like examples of maybe landmines that you've stepped on when trying to scale something, >> that'd be super interesting.
>> Yeah, let's dive into it. This is my uh this is my fun zone pretty much. I like it. So um let's indeed make it a little bit more like tact tactical and therefore also technical for the
audience because up until this point also my um recommendations for people may have been quite obvious. Just use cloud code, right? Just ask the model, bro. And the funny thing is um that's
true. That's what you should do. But there is still a part when you really want to take things to the next level where um it is very worthwhile to like train yourself and to get a better
understanding of how software works. And I keep coming down to describing that as just the highlevel architecture of your application and the software that you're building.
And there are two distinctions between that. And this is very worthwhile to like research a little bit what I'm about to say. So this could even be you with like codeex with with cloud like
spend some time asking the the the following terms that I'm going to mention. So architecture first of all we have it at uh what I call the system level. And this means how do all of the
individual components like your back end, your front end, and your database and potentially even other services, how do they talk together? Because most software products
are a combination of those things, right? And it's very it's very important to understand what the role is of each and every one of those how they communicate to each other and what are
some of like the traits the unique things and also the things that you need to care about when it comes to those individual things. Right? So this depends heavily on first of all what are
you building? Are you building a web application, a desktop application, a mobile application? uh something that combines all of those. So it depends. It also depends on what language do you
use. Do you for example use languages where you have a very clear separation between your back end let's say that is built in Python for example or in Rust or in C and do you have a front-end
application so the visual layer that is maybe in JavaScript you're using Nex.js JS. So then you have usually like completely different code bases. Now you can also have projects that for example
just work in one stack. So you do everything in TypeScript for example. So TypeScript that whole project it is your back end and it is also your um like your front end your visual component to
that. So those are all things that matter based on what you're building. So now that you get a little bit more serious, that is a good like first question to ask your AI agents. Hey, I'm
building XYC. What would be the best stack? And then stack is the important word here. What would be the best stack in order to build this? Do I need a separate back
end and a front end? What kind of database should I use? Can I put everything together? So those are then questions that you can go through and it will give you examples and you can just
ask like hey what does that mean? What's the simplest solution? what fits the best for kind of like what I'm building and because that is a really important starting range because once you log in
on a on a programming language like within the language itself you can do a lot right you can scale up you can scale down you can refactor you can build but switching a project to a different
language even though with coding agent it becomes easier and easier and easier that is usually not a trade that you that you want to make right we had to do it with glido at some point um it was a
lot of like we started out on a different stack than what we use right now because in the beginning we didn't do our research properly. It was also a little bit because of team structure. We
had someone working on that and the other one working on that and then we decided to go in a direction and then later we figured out >> um we need to do this differently. So
that's that's a landmine that uh that I that that we stepped on. it was choosing the kind of like things we're we're familiar with rather than picking uh the tool or the stack that was really like
most optimized for what we eventually wanted to build. And in the past um this would pretty much have not been possible. So if you are comfortable with a with a stack, you've been developing
that for 10 years, you most likely want to use that, right? But I think that now changes. You could now very well say, "I'm confident with that stack, but there is there's evidence there's
actually evidence that this stack is way better for what we're trying to do. Let's let's go with that stack." So, architecture at the system level, backend, front end, database, how does
everything talk to each other? Then you also have architecture at like the project level. So, this is when you go inside, let's say, your GitHub repository and how you structure your
projects in there. This is less important than the higher level system architecture, but it's still important to have like a rough understanding of how do you structure projects in terms
of files and folders. So, what do you put in there? And how do you structure your code in terms of functions, classes, and modules that you create? So when you're creating code and these
agents get better at it every month, but you can still have these like spaghetti code bases. You know, you build something here, then you build something there, then you build something there.
And this uh can happen quite quickly when you are vibe coding and you go from idea to idea to idea and you experiment a lot, which is a new way of building, right? You just ask it to build
something and it might build something. Now you have this artifact in there. >> Then you decide, let's leave it there. I don't really like it. let's come back to it later. You build something else. You
forget about it, you know. So now you have this mess. You have this junk sitting in there and that might have >> some logic in there which you still really use and which you still really
need, but it's got all of this bloat around it that was just a test feature that you wanted to build. Now you start to build on top of that and you create these new features. It's all great, but
they still depend on this kind of like messy little part that's really deep way into your codebase. So this is how you get spaghetti code codebase, right? So over time it gets harder for your AI
agents to manage and to find where where everything is. And this is where you you'll run into bugs at scale. So all of a sudden things stop working, right? It it worked fine for 3 months and then all
of a sudden >> things don't work anymore. And it's because you removed the feature that was >> not no longer needed, but it contained a little part that you actually still
needed. So >> understanding how that works at a high level is >> very valuable to do. And I'm going to give people like one tip to look into.
There's a really good skill for this and it's called um I think it was recently changed but it's from Matt BCO. So this is like he's famous for his skills, right?
>> Great engineering skills. >> Yeah, great great engineering skills. So, it used to be called improve codebased architecture, but I think he refactored that a little bit to I think
codebased design or something like that. But if you >> we'll find it, we'll link it in the description. >> Yeah, if you search for Matt PCO and
then find some of his skills where he talks about uh improving architecture about how to create deep modules and locality and how to work with with the seams. That is a skill that I very often
uh use to review my code bases and that uh he even like mentioned that he created that skill to fight AI slop and make code bases that are easier to navigate by AI
>> and imagine how cool that really is where I just said pretty much there there's two components that I still are that are still I think very high leverage to learn more about
architecture at like the system level and the codebase level. For the codebase level, there's literally just a skill that you can use. And if you just read that skill and use it in your coding
agents, you'll get better at it. >> To me, that's just amazing that that's how you get how you get better at it. And then the and then the the like the front end database back end,
>> spend a day re researching that. >> Like if you're serious serious about building stuff, just like ask questions. like even do it on like lunch break, go out, take a walk, like start to learn a
little bit about what that means, how they communicate to each other and also what the different um security aspects are of those different levels because security applies to like your entire
application. But there are specific things that your database handles u your back end handles, your front end handles and the communication layers between those.
>> Mh. Yeah, I think it's really cool that you brought up the skills of Matt PCO because one of the things that I was thinking about as you were going off
there was what you mentioned at the beginning which which was that the fact that really under the hood software engineering is still the same but the human role has changed
>> because of the fact that these things are so smart and can move so fast but still the principles of building good code are still the principles of building good code. And for someone like
me or for a lot of people probably watching this, maybe when you started saying like Python, C, Rust, they were like, "What are those things?" You know, but that's been around for so long. And
people like Matt PCO, people like you know what it looks like to have a good codebase. And that means that you can leverage the subject matter expertise and experience of other people if you
ask the right questions, if you have it do research, if you leverage skills like that. And I think that that part is really cool and hopefully gives people a lot of a lot more comfort in in the fact
that they're not alone in building this app because there's so much stuff out there from people that understand what what does good look like when maybe you can't define good as well as someone
else can, you know? >> Yeah. >> So, the last piece I wanted to touch on then is I know you hit on a little bit, but
what should people be thinking about when it comes to the security stuff like not only from like a data privacy but also how do you think about what's the potential of your app getting
hacked you know that sort of thing too how do you think about that especially if you have no background in any sort of like cyber security >> sort of stuff
>> so the cool thing about this is that with um very little uh like ju with just the the basics you can go really are. So, of course, security is this big domain and
there's different levels to it, but I also don't come from like a security background. I wouldn't even consider myself a security expert. Uh we do have yours on our team who knows way more
about that and I've picked up most of the things from him uh over the years. But like I've said, the cool thing is there are actually like if you do a hand uh a handful few things, you already are
it's almost already impossible for you to get hacked. So let me give you a couple of those things to look into and there is a little bit of overlap between like what we would call infrastructure.
So that is the whole concept of okay we talked about architecture at like the system level backend front end database right infrastructure pretty much means like where do all of those services live
where are they deployed and how do they talk to each other and what are for example the firewalls around them there's a little bit of overlap in there and again um very um high lever thing
that you can look into even if it's just like from a research curiosity perspective ive to learn more about this. So let me walk you through some examples to make this a little bit more
tangible. So let's start with like a database. For most people building something, you want a database, right? Most applications need a database. You need to store user
accounts, passwords, any information that you might need in your database. And right now the most popular option for that is Superbase. Superbase is a really popular database. And Superbase
is amazing. If I would say to anyone, if you don't have a very strong reason to not use uh Superbase, use Superbase. Meaning that if you're nontechnical, if you're just starting out, just use
Superbase. It is flexible enough that you can do anything with it. Don't be like uh bothered by people saying, "Oh, you really need like an unstructured database for this use case," or like,
"Oh, you need a dedicated factor database." Like Superbase can do all of that. Just use that. And then like I've said, if you have a very strong argument as to why you don't like Superbase, then
you're probably technical enough to make the decision on your if you get what I mean, right? So >> that makes sense. Yeah. >> Yeah. So database, use Superbase.
>> So Superbase um it's you can also self-host that by the way, but for most people I would recommend just use it in the cloud. That means go to superbase.com, create an
account, create a database. There you can get on a uh a plan and you have your database. Now then what I recommend to do is again spend a couple of hours talking about the security aspects and
best practices that you can set up around Superbase. Superbase is great out of the box. But there are some things you need to be aware of. This mostly has to do with rowle security. Again I'm
just putting out these terms in here not to go into them but for people to like research into that. So rowle security is important. like look up what that means, how you can work with that. Uh make sure
that your database has like a strong password, like common sense, strong password. Make sure that your user account that you can log into on Superbase, strong password and also
potentially two-factor authentication. This is all very simple stuff, right? But this is just avoiding like people and random bots being able to like randomly guess a password and can get
into something. Now then also, so that's your database. So now your data lives in there. If you use Superbase in the cloud, you put on rowle security and you have strong passwords and you make sure
that all your services that connect to it use the credentials in like environment variables without like actually putting it into into code, you're already in a good spot. There's
more that we can do, but this is already from a database perspective a good start. Now then when it comes to your uh back end which is the second most important thing because for your back
end usually you have data flowing right so your front end application um may load data directly from your your database or it can also go uh through your back end right so your back end
talks to your database and then your back end like uh uh puts that uh or like flows that data through to your front end. So the back end is another part where you need to be aware of first of
all like what language do you use and then second where do you deploy that? So where does that code live? So when you start building something it's on your laptop it's local host. You're running
things you're testing things but when you deploy something you actually put it in the cloud and this is where people can get access to it. So there are of course various a lot of different
services that you can use. You have tools like Railway and Render that make it really easy one-click deployment. Um, you can rent a virtual private server. You can use Azure, AWS, GCP. So,
different types of ways that you can set this up. Um but the most important thing is that when you deploy your back end that you set up ideally some type of firewall
rule around this where you restrict certain traffic to it and this is again something that you just need to do some research in depending on which platform do you use which language do you also
use uh and then use your AI coding agents to talk about okay what is like a firewall how can I set that up now this also applies applies to your your database and you can do this in the
superbase uh dashboard. But why this is important is usually there is a part of your application that is userfacing. That's typically your front end meaning that's the that's what people actually
see. They go into the browser or in a desktop application and they use that and then your back end and your database no one should be able to touch that. only your user application is you should
be able to pull information from that and uh your front- end application is then also deployed somewhere again can be any of the services that you use maybe you use it on for sale uh the
thing is that deployment there uses an IP address so that is a specific address from which it reaches out to either your database or to your back end and I know it gets a little bit technical but
Firewall pretty much means you set up a rule where you say in your back end and in your database only open the door if the request is coming from the IP address that I
whitelisted which is my known front end or desktop application. And now there is very different rules depending on how you set up your like your infrastructure and how you set up your architecture and
your applications. But that is the like general uh best practices around security. Setting up the proper firewalls and then making sure secrets, API keys, credentials, all of that are
handled correctly. So you cannot read them in your application code. people cannot read them uh by for example in a web application inspecting the code in the browser right so if you protect your
secrets and your credentials you have rowle security on and you put proper firewalls on your database your back end and whitelist it for your like front end application that is security in a
nutshell and again it's technical but it's more so for people like to take this snippet summarize it put it into like a chat and then reason through this what that means for your application
Yeah, I love that. That was a master class. And I think one of the things that >> have become very clear throughout this conversation with different technical
concepts that you've brought up is that a lot of this sounds like it's just about awareness. If you can bring up this conversation to your agent and let it go do the thinking and the
understanding of >> implementing, >> but you were the one who had to say, "Hey, think about this and do this." Right. I think that's very cool.
>> Yeah. It's it's those unknowns unknowns that you in the beginning as a new builder developer need to become aware of so that you can ask the right questions to your AI agents. It's not
about the skills or even the intelligence or uh the years of training. It's just the awareness being able to like ask the right questions and then also with the base level
understanding that you have being able to somewhat reason over those answers right where you can say yeah that is important and let's not get into this right now because those are not kind of
like the basics that goes way deeper that's not important for my application right now at this stage >> I love it let's let's wrap up here with with one final sort of like
big statement from you what I want to hear from you is basically I want you to start the sentence like this. If I was starting today with no technical experience, I
would be most excited about this. Like what is the opportunity and what gets you excited like thinking about the future of where AI is headed and what you're able to do with it in this, you
know, software engineering or building apps sort of space. >> Cool. That's the I really like this. So, um, yeah, here's I would answer. So, if I were just starting out and I see what
what's going on around me with all of this technology, what I would be most excited about is the opportunities it can create for each and every one of
us. So I out of university quite randomly happened to land on a freelance gig and worked self-employed pretty much ever since then. Started to build businesses off of that and that
has given me insane amounts of freedom and getting to work on exciting things that I want to build. And I think that is now within reach for more and more people because of this gigantic
transformation that we as the world will be going through in this AI transformation. And you might be thinking, yeah be when the tools get easier, everyone can do
this. True, but we still need implementers. We still need builders. The fact that it is possible and that we can do it doesn't mean that everyone and every business will actually take the
initiative to start to start doing this, right? So there are just going to be so much opportunities to for like pretty much um entrepreneurial things to build things
on your own to to sell that to make that available to make content to help local businesses or maybe not even local but to help larger businesses to be able to be excited about the technology about
the automation about the transformation and then getting better at that craft as you do it and then being able to like monetize off of that. And if that is exciting to people watching, which I
know it probably is because I know your audience, right? Then I would say like go go all in on that. And if you even if you're not just starting out, but you may already have a job, like figure out
how you can do this on the side, right? Um, I for example have an entire community of freelance developers and data professionals and I also share that with people because the opportunities
are real. You can do this next to a full-time job. You can pick up a project and while you're doing your day job, you can just kick off another agent and let it do the work, right? You can even use
your phone to talk to Claude on lunch break. Give it a master prompt and when you're back home like it has built the automation for your client. So I would say that's the most exciting thing. Um I
recently watched a podcast uh it was on Lex Fritman and we had DHH the I don't even like it's David blah blah blah. DHH is is is what he goes by online typically. And he described it as having
a genie in a bottle. Like we as developers now have a genie in a bottle. I like that. >> Meaning that you can just think about it >> and you can prompt it into existence.
>> And you're not even limited to three wishes. You can just keep asking. >> You're not you're just limited to your tokens. >> Yeah. That's that's what you got to be
careful >> to your weekly token budget. Yeah. Yeah. But I think that is that that is a great like description and you know this as well Nate because I see all of these
videos from you when whenever every time a new model releases like the stuff that they can do just gets crazier and crazier and crazier and it used to be on like this yearly timeline where if you
looked one year back like the models were like extremely way way better. I think now we have it already like on a quarterly basis where you have these like really holy this is so much
better than what we had right and that will that will continue I I don't see a world where that is going to stop >> so you just need to learn how to like use these tools and then build stuff
with it and then use that to ultimately create the life that you want because like building stuff just for the sake of it is fun but I It's a we have a great opportunity to like help yourself, help
your family, and to create a life around these tools that was just not possible years ago. >> Mhm. Yeah. I think the the only way we see the the progress slow down is if
this whole like pacing the frontier discussion that's going on right now, if there's an actual standard in place for regulation and for >> I guess kind of like a a national and
global coordination. So, we'll see what happens there. But >> there go f They go f steam hats. There's no stuff. >> Oh man, we could do we could probably do
a whole another hour talking about this stuff. I think it's really interesting as well. But >> um this space has been, you know, so exciting, so fun. I'm so glad that I've
been able to connect with people like you and hang out in person and just, you know, you're super smart guy. So I appreciate you coming on. This has been a super informational
episode. So really appreciate you coming on. Dave, where can people get in touch with you or learn more from you if they're interested? >> Cool. Appreciate it, Nate. Uh, just go
to my YouTube channel, Dave Ablar. Mostly videos for a more technical audience. But that said, what does that matter nowadays? Like I make sure that my
tutorials, I also create these kind of like handbook guides for them nowadays because it's so easy. I used to just create tutorials and teach them. Now I create a tutorial and I just say to AI
like create a whole entire documentation page for it so people can walk through it step by step. So the cool thing is I mostly do kind of like big builds how to build this. For example, I just launched
a video how to build an entire company knowledge base and then actually do it properly like something not just like the toy project but actually something that you could like offer to a company
and it's for a technical audience but you could also just use your AI agent and point it at the GitHub repository in the handbook and it can build it for you. So yeah, YouTube Dave Ablar that's
where you find me. >> Sweet. I love it. Well, thanks so much for hopping on today Dave and maybe we can do it again sometime. My pleasure, Nate. Talk soon.
>> Awesome. All right. See you, Dave.