September 9, 2025 • 50 mins
Join the Tool Use Discord: https://discord.gg/PnEGyXpjaX
Build full-stack apps from a single prompt with Fastable, the revolutionary AI tool from AI consultant Richard Abrich. In this episode, we dive deep into how you can go from an idea to a deployed web application using AI, and learn how Richard built the tool to accelerate his own development workflows.
Richard shares his expert approach to context engineering, hallucination mitigation, and creating a powerful feedback loop by piping logs directly into the AI agent to debug and iterate faster than ever. We explore Fastable's tech stack (FastAPI, Python, React, Postgres) and how it offers a more flexible, vanilla alternative to tools like Lovable, giving developers the control they need. If you're interested in AI-powered development, the future of disposable software, or building your own tools to solve real problems, this is a conversation you can't miss.
Try Fastable for yourself: https://fastable.dev
Connect with us
https://x.com/ToolUsePodcast
https://x.com/MikeBirdTech
https://x.com/abrichr
00:00:00 - Intro
00:03:57 - Fastable's Tech Stack vs Lovable
00:07:33 - Context Engineering for Non-Technical Users
00:17:32 - Fastable Demo
00:31:08 - Mitigating AI Hallucination
00:45:53 - The Future of Disposable Software
Subscribe for more insights on AI tools, productivity, and AI development.
Tool Use is a weekly conversation with the top AI experts, brought to you by ToolHive.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
The value of code has plummeted because now you can generate
code instantaneously for fractions of a cent, but it
doesn't mean the value of software has plummeted.
As software becomes more and more accessible to people, the
value of software is going to increase because people are
going to make more software to solve even more specialized
problems. That's a real opportunity of
creating a tool that somebody like my brother can use to
(00:21):
actually solve their own problems.
What does it take to do something useful while you have
to build some software? The way that I've been doing
that, and I think it works extremely well, is by having the
the model build its own tooling.If you can avoid using agents,
you should. Tools that build tools are the
ultimate unlock for productivity, but how do you
build them? Today we're joined by Richard
Abridge, an AI consultant who previously was on tool use back
(00:42):
in episode 10. He's recently built Fastible.
It's a tool that allows you to build full stack apps from a
prompt in your browser. So in episode 56 of Tool Use,
brought to you by Tool Hive, we're not only going to learn
about Fastible, but how Richard built it, his development
workflows, advice on context engineering, and his approach
for hallucination mitigation. I always have a great time
talking to Richard. He's a super smart guy and he
(01:04):
built this tool for himself. So it solves real problems.
And you'll be surprised how his approach seems to make way more
sense than what the big names inthe space do.
So please enjoy this conversation with Richard A
Bridge. So I've been building Fastible.
So I wrapped up a contract with Microsoft 3 months ago and on
that Crunch contracts we built basically this full stack web
application, agentic web application that would analyze
(01:26):
documentation and find errors. What really struck me about that
experience was like my productivity because that was my
first time using Vibe coding tools.
So I used Windsor and I was justblown away at how, how fast I
was building and not just me, like the engineers on the team
were also like, how are you doing this so quickly?
What's happening? And, and so that's, that's when
(01:48):
I started thinking like, like these are some pretty good
engineers I'm working with. They, they know a thing or two.
Like one of them won the 2nd place at the World AI Fair
hackathon in New York City. And he was telling me that my
productivity was like amazing. And I was like, you know, it
wasn't, it wasn't like anything that I was doing in particular.
It was just, I think the processof it was, it was the vibe
(02:09):
coding, but not just vibe coding, but it was the process
of basically integrating logs like, so I would prompt, you
know, Windsor to build some feature and it would, you know,
do it's thing. Well, you know, it wouldn't just
be like, build this feature. There's, there's more to it than
that. But after it was finished, it
would say it's done. And then I would test it and it
was broken. And so I, I quickly found that
(02:31):
the easiest way to, to basicallyget it to fix itself was just to
copy and paste logs, like the relevant logs, either from the
browser console, if it was frontend or from the docker container
if it was back end, back into the, into the context.
And I was just amazed at how much time I was spending just
(02:52):
doing that. You know, there was, there was
like such brain dead work that Iwas doing.
I was just copying and pasting logs like I had to know where to
look for the logs, but that's what it was.
And so it occurred to me that, you know, this is obviously not
something that a human should bedoing.
This is something we can automate.
And then I learned about, you know, Lovable.
(03:14):
Lovable is like the fastest company in history to go to 100
million ARR, right? And I was looking into sort of
common sort of complaints, like on Reddit forums about users
experiencing with Lovable. And it was basically exactly
what I described, that you wouldgive it some instructions and it
would go away and sort of execute on those instructions
and come back and tell you that it's done, but it wasn't done.
(03:35):
And then you'd have to sort of do it over and over and over
again. And especially for non textable
users, they get really, really frustrated.
And so it just became clear to me that like you can solve this
problem fairly easily by just closing the loop and piping the
logs directly into the agent. And so that was really the
motivation for building Fastible.
So that's what I've been building for the last three.
Months. Nice, very cool.
Yeah. And they gave it a test spin and
(03:55):
it is a really cool set up. Could you talk a little bit
about the difference outside of just like the log loop being a
full stack app rather than just like a nice GUI that people can
put together? One of the other limitations I
guess with with lovable and and clones are that they're, they're
basically all built on like pureJavaScript and super base of the
(04:17):
database. And I guess, you know, that
leaves out a whole, that leaves a lot of opportunity.
I think like not everybody wantsto use super base.
You know, it can be pretty expensive when you start scaling
and there's also some other tools that like you don't need
to use super base, super base, right, like Postgres for
everything is my motto, open source and it does everything.
And so that's that's probably one of the most significant
(04:39):
differentiators is is the text stack.
So we're using fast API, which is Python framework and we're
actually using the official fullstack fast API template, which
uses React on the front end. That's not too dissimilar on the
front end from global, but on the back end we're using fast
API and for the database we're using doc Postgres and it's,
they're all deployed via Docker.So that's sort of, I think one
(05:01):
of the big differentiators is that it's using, I would say
like more vanilla text stack then then Lovable and, and Co.
And so everyone who is more familiar with that text stack
and you know, is more comfortable building in it and
wants to have the advantages of not being locked into Superbase,
that's really who festival's for.
That's the differentiating. Nice.
And one thing I did see also comes right out-of-the-box is
(05:24):
e-mail authentication, because anytime you get into the realm
of security or off, when you getnon-technical or non experienced
people vibe coding up at their own project, it's just something
you don't consider. So by including it, you really
allow people to kind of skip therisky part and just say, hey,
like I can make sure only a subset of people can actually
access this or that you authenticate them ahead of time.
Are there any other limitations that you see using Festival
(05:46):
versus, you know, of just like opening up cursor or windsurf
and just going nuts on a project?
So I think the main limitation, but I, I see it, it's not really
a limitation, it's a deliberate design choice is that it's, it's
a significant constraint. So when you're using cursor, you
can write anything, right? You can write Rust, you can
write C++. I mean, your mileage may vary
because the training of the models, you know, the data might
not, might not be there. So they might not do as well in
(06:08):
those languages. But the idea with like Cursor
and these sort of general purpose tools is that their
general purpose. So you can build anything you
want, whereas Fastible is reallyfocused on building full stack
web applications now like you don't.
It doesn't have to be full stacklike you can, you can just, you
know, focus on the back end and just deploy the back end if you
want. But it is constrained to fast
(06:29):
API and Postgres and Docker. So if you don't want to use
those things, then you should probably not use fastible in the
future. We might extend that for now.
That's, that's the that's the limitation.
And it's a deliberate design choice for two reasons.
One, it's part of the full stackfast API template, which is, you
(06:50):
know, it's a really, really popular project that I've worked
with a lot over the years and lots of other people work with.
And it's pretty good product to start to build applications
from. And second, yeah, it uses these
languages that large language models really excel at, which is
TypeScript and Python. So if you want to build on Go or
(07:11):
REST, you might have more trouble using large language
models because they don't have the same amount of training data
in those languages. No, absolutely one thing in
terms of the usage. When you were on episode 50, you
mentioned garbage in, garbage out and the importance with
context engineering. As soon as you start opening up
these tools to people who aren'tas experienced with prompting,
there is the risk of when they're interfacing with the
chat aspect of it that they do put garbage in because they
don't really know what they're asking for.
(07:32):
They may be too abstract. How does either Fastible help
prevent that or mitigate it, or just like assist users to be
able to be as natural as they want without having to know
their correct terminology? Yeah, that's a great question.
Right now it does not. It's all right.
It's still a work of progress. So the goal, yeah, the goal is
to make it available to non-technical users.
So I'll back up. Actually.
Like part of the reason I started building it was because,
(07:56):
again, it was because of my brother.
My brother will start vibe coding his own.
So my brother's an electrophysiologist and he had
some new requirements around like billing.
He had to enter in billing codes.
And so he started vibe coding his own web app, which was then
accepted into a conference. You know, I was sort of helping
him along sort of along the way if he had any questions.
But it just occurred to me that that's a real opportunity is
(08:19):
creating a tool that somebody like my brother can use to
actually solve their own problems.
And so that's the motivation I want to make it so that
non-technical users can use that.
But so we're not there yet, maybe next, maybe next time.
So the way that's I'm thinking about going about solving that
just something that's other people have already started
building is essentially like a design assistant.
(08:41):
So before going off and like actually converting the prompt
into code, the first thing that you should do and that I do when
I'm by coding is converting my prompt into a better prompt.
So using a large language model to like assist me in building
this prompt. And that's actually how I built
Fastable as well. It was actually before I started
coding anything, I spent over a week just iterating on a design
(09:04):
document and the document said if we can wait too long.
And I had to eventually like pair it down.
But it really helped in basically setting the context
for the model. So that's basically every time I
wanted to build it. You know, you're not gonna do
the whole thing in a single context.
You have to create a new contextevery time.
And so you need to have some sort of shared contacts that
(09:26):
you're moving between these different conversations.
And so basically just manually created a Google Doc by
prompting a large language model.
The goal is to make is to build that into Fastible so that
before you start actually coding, the agent is going to
help you through creating the design.
And ultimately the goal is that,you know, we don't even have to
(09:49):
be aware of what's happening in the background.
I don't know if that's going to be possible.
And maybe I shouldn't want that to be possible because then
we're all out of a job. But that's that's the goal.
Excellent. Yeah.
And my my day job at Box 1 doingthe AI Academy, I've been trying
to teach everyone how to build their own tools using cursor
clod code. And one of the issues we've run
into is just the fact that non-technical people with
Infinity opportunity through these things, I can steer like
(10:12):
they can go off the rails. It can do things that are
unintended, like had unintended side effects.
So by being able to put these guardrails on and say here is
going to be a well structured web app that you can deploy
automatically sync up to your GitHub.
I feel like that's really going to alleviate a lot of the issues
where allowing people to have like the Wild West of AI
tooling. Do you envision Fastible mostly
(10:34):
being in the zero to 1 stage of the development life cycle?
Or is it something that if I have an existing project,
whether I built it on Fastible or otherwise, I can iterate,
refactor and try to build upon it?
Yeah. Thank you for asking that
question. So one of the features that I
just deployed was Biscuit project import feature.
So if you already have a project, and again, this is this
is for my brother who I've codedhis app, but who wants to use
(10:57):
Fastible. So now if you already have a
project, whether it's vibe code or not, you can just specify the
GitHub URL and Fastible will clone that, the GitHub
repository and then convert whatever it is into the Fastible
stack so that you can have sort of whatever it is that you have.
Even if it's like something in acompletely different language,
you can convert that into into the same stack.
(11:19):
Zero to, I guess zero to 1. It depends how you define one.
So Lovable defines 1 as like an MVP, right?
So where it's not even, it's more like a almost a mock up
where it's just basically like the, there's sort of like AUI
and maybe some basic back end functionality.
But most people are finding thatthey have to move off of Lovable
to actually bring it to production.
So the goal with Fastible was toremove that sort of limitation
(11:42):
so that users can just stay in the platform and build the full
the full application there, actually deploy it and
everything. We don't have deploy like we
have the the live staging environment where you can share
that with your friends. But that's sort of like on our
hosting environment. Eventually we're going to be
building it so that it actually helps you deploy into your own
hosting environment as well. But still A to do.
(12:03):
But yeah, the goal is to is to make it so that you can build
the full application from start to finish in Fastible.
Very cool. I did see that it's bring your
own API key. So it's nice where I don't have
to worry about paying a monthly SAS subscription right now.
I can just kind of control my usage.
Do you have a general estimate? I know with like projects,
there's such a wide range, but how much will it cost someone to
(12:24):
do something from like a basic to do app to something a little
more complex? So we're looking at like
dollars, 10s, hundreds, thousands.
How much can they expect to spend on API costs?
Yeah, I'd say for A to do that maybe around $10, you know,
depending on how, how, how complex your to do app is, like
just add it like relatively simple stuff, it's like $0.10.
Like adding like some animated background is like $0.10.
(12:47):
And so yeah, you might have to do that a few times to make a
dodo app. So you can get to like a dollar
to $10.00 for a basic app. Yeah.
It really depends what you're building though.
Nice, and you did mention the pre prompt, the prompt
optimization. You can chat UBT.
Are there any other tools that you think people are either
using or should explore that would help augment and
supplement using fastball? Well, like I said, I mean, I, I
(13:10):
want fastible to be sort of the platform where you can build
like I'm building this for myself really.
Like I've done a lot of full stack applications as part of my
job. And so I'm really building it
for myself to make me go faster.And one of that's why one of the
things I want to build is this sort of design iteration tool,
so I don't have to do it with Google Docs and ChatGPT.
(13:31):
But yeah, until that's there, you can always go to ChatGPT or
any other model. And just that's why there's a
copy button in the agent's chat window.
So you can just easily copy the full agent context and paste it
into another model. To give you sort of a second
opinion, there are some tools that I've come across just
recently in the last few days I just saw on Twitter.
(13:52):
I haven't actually had a chance to reuse them yet though.
But there, there is at least onetool that's basically what I'm
describing. That's it's just basically like
a design assistant where you type in like, oh, I want to
build this thing and it sort of leads you through sort of
engineering design. At the end you get sort of a
design document. I'll I'll see if I can dig up
that name for you and send it toyou afterwards.
Perfect. Yeah, we'll include it down
below. Another, another big difference
(14:12):
between fastible and lovable is the fact that it doesn't try to
hide the complexity from you. So lovable, I think it's really
intended for non-technical users.
And as a technical user like that was I found out a
limitation and so did other folks that I that I spoke to
about it. So with Fastible, the goal is
that you shouldn't ever have to look at code if you don't want
to, but you can't if you do. And so we have like a full,
(14:32):
there's a full editor in there, like a file browser.
You can view the diffs and you can accept the reject diffs by
file if you want. You don't have to.
You can just do it by the cowboystyle and just not look at
anything. But if you want to, it's there.
And I think that's useful for technical people who might have
an opinion about how something should be implemented.
Or more importantly, the reason I built it was because sometimes
(14:53):
the model will just screw up something very, very minor and
you don't want to have to like spend let's say like $0.10 or
weights, you know, a minute for it to fix it.
You just want to press like backspace and fix it yourself.
So that's what that's there for.I think that's the other key
differentiator. Nice.
And one thing I do like about the deploy to GitHub aspect is
on a lot of my projects, I've actually installed either Mentat
(15:14):
or Claude code in in the GitHub action.
So if there's APR pushed up, it'll actually review it, give
some feedback. I can kind of guide a little
that way. So actually curious what what
models or model or models are powering Festival?
Yeah, right now it's just cloud code.
Nice. And the reason is because when I
started building it, that was the one with the best API.
I, I looked at a few other ones like Open Hands was the first
(15:35):
one because I wanted to make it open source initially, but I had
some trouble integrating Open Hands and there were a few other
ones. But then I looked at the Cloud
Code API and it was clearly likethe most advanced and well
documented. So that's the one that's enough
going with. But now since then, there's been
open AI codecs has been releasedand as well there's, I think
(15:56):
Gemini has something I don't know, but I haven't looked at
the APIs though for those ones. But the goal is to integrate
those as well. So you can sort of pick which
pick and choose you know what model provider you want.
Very cool. We actually had Graham new big
from open hand on here back in the day.
So we got a little message get him to step it up.
Yeah, yeah, it's really cool. Actually just this past week
I've I've took the switch to codecs to give it a try because
(16:17):
I heard a lot of good things. One thing I dislike about it is
if you ask it to do corrections or explain the justification for
the code, it suggests it will rewrite the code and you have to
accept or decline it before it'll give you the explanation.
And I really like with cloud code, it'll do like like
conversation first, code second.But opening I sent to flip that
just a small little user thing. But when I upgraded, I think I
(16:38):
was on 0.9 and then it got up to0.28.
So they're, they're shipping fast, they're making big
improvements. So yeah, I definitely hope more
people try it out just to see like you got to explore these
different tools and see, see what works with you.
Yeah, exactly. I think another big
differentiator in terms of the models is the clock code is like
probably the most expensive one out there.
So yeah, we've already had some comments from users that like,
oh, this is this is adding up. So that's that's one of the
(17:00):
reasons why I want to switch or at least add the option to
switch. Yeah, having the the toggle bowl
or there's like a drop down listtends to be helpful, but it's
tough when you're when you're looking for certain results.
It's really tough to beat the state-of-the-art.
We just get spoiled with it. We get used to being like, oh,
you know, 4.1 Opus can output this, this is what I want.
Turn on Max mode and cursor and you know, deal with the cost.
Yeah, especially because really the most expensive thing is your
(17:22):
time, so. Save time and if you compare it
to the salary of another engineer or outsourcing to a
consultant, if you're able to work through it, it is a massive
reduction. Yeah, yeah, when you log in,
you'll see the screen where you can create a project.
So you can create a new project here.
You can just describe whatever you want it to be, like my
social media app or something like that.
(17:43):
And if you have an existing project, here is where you can
paste it, get a repo and you canimport it.
All right, so once you've created an application, this is
sort of the screen that you'll see.
This will take a couple of minutes to load up.
One of the things on my very long To Do List is to speed this
up. But while it's going, let's
describe quickly what's happening.
Basically, there's there's a bunch of containers that need to
(18:04):
be speed up in the background, like the back end container, the
database. And as they spin up, you'll
start to see them here. So here's where you see like the
Postgres of the database and youhave like the full the full logs
here. Here's where you get browser
logs, which is this is pretty powerful.
And it took a little bit of hacking to make this work.
But basically what you're seeinghere is actually once it's
loaded anyways, this is an iframe.
So it's not, it's actually loading it from a separate
(18:27):
website, your website, it's creating a new website just for
this project. And that website is gonna be
loaded here. And the logs for this website
for that website is what you're seeing here.
So on the browser, there's nothing happening cuz it hasn't
booted up yet. But you can see the front end.
It's like installing dependencies.
The back end as well. It's faster after the first time
cuz it doesn't have to install everything from scratch while
(18:49):
it's going. I can also show you this stuff
here. So here's where you see like
this is sort of like the power user features here.
If you, if you really care aboutcode, you can come look at it
here. I'll open up the login route so
we can have something to look atreal easily.
And so you can see there's like a nice syntax highlighting here,
right? So this is this is now your
website and you can see like it already has this login form.
And so given these credentials here, these credentials are
(19:09):
generated automatically for you.If you want to log in, you can
log in. And here's here's sort of like
your application. You can see there's not much
here yet. This is just the the standard,
the default fast API template. And you can see also there's
these access URLs. So if I go here, for example,
you'll see that it's actually loading up like this.
This is the website that you seehere and, and it's it's being
(19:32):
hosted in this domain name here.And yeah.
So if we go to like, let me log out here and go back to that,
that login route. Give a demo here of how this
works. So I can, I can, I can just edit
and it's live reloading. So I'll just say like hello, you
can see immediately it shows up there.
(19:54):
And so you have your hello up here and then you have like your
syntax highlighting and you alsosee this diff here.
So if I, if I open this, you cansee that it shows me the diff
and I can also just go back and edit it.
All right, so that's that's sortof like the power user feature.
But if you want, you can just like hide that all together and
not pay attention to it. And you can just say like add a
(20:15):
giant emoji to the login page and this will just take a
second. But on the background, it's
starting up like a cloud code context and Cloud code's running
inside of the container that's running the application and
actually modifying the the live code.
There you go, added a giant emoji.
And so if I go, I can open up this guy here, you'll see that
(20:36):
the should be. There you go.
Here's the depth of what it added.
And so now if I want to, I can, I can just start it or I can
commit it. So if I commit it, you'll see
it'll generate a commit message for me.
Add rocket emoji and hello text to login page.
And I can commit that. And there you go, it's
committed. So there's no state changes.
(20:56):
And now if I want, I can go to my project and I can say, push
to GitHub. That's new.
My demo. Yeah, exactly.
Yeah, but normally this works and and you can can, you know,
export your project to GitHub and and do what you will with
it. And I did really show the, the
value of the of the logs here. But one thing I I wanna demo
(21:20):
just real quick is let's say in the login page, I want to say
console dot log hello world. And you can see it's it's it's
grabbing the logs there. And so this is useful because if
something was broken, the, the console would throw an error.
And then I can just copy that and paste it back into, into the
agent. And so this is basically closing
(21:41):
the loop for, for the agents to,to ground it in the actual
environment. And then, as I mentioned, you
have this sort of copy feature here.
You can copy just the, the, the top level messages, or you can
also expand. And there's much more details in
here. You can see for each message and
also get to the cost, which is something that's I think for
some reason most of the not for some reason I think to encourage
(22:01):
usage. Most of the provide like the the
other tools, they sort of hide this cost, which I find sort of
some optimal. I'd like to know how much I'm
spending. So there you go.
It costs $0.15 to add this emojiusing cloud code.
Yeah, the transparency is alwayshelpful just to get a better
understanding of what you're actually doing.
And yeah, I agree. Yeah.
And then you can also see, you know, let's give an example of
(22:24):
like an error. If I just say food here, we
should get an error. There you go.
Something is not defined, Food is not defined.
And so if I just copy this and then I can create a new chat
because this this chat, let's say it's not relevant.
So use a fresh context and I canjust paste it in and hopefully
it'll pick it up if there's an error and try to fix it.
(22:48):
There you go. Can see there's a reference
error, can see the issue unto myvariable Foo.
Well, you can see it remove Foo.But I still haven't given it the
the tool to re to restart the environment.
So I think if I refresh it, willthat fix it?
Yeah, There you go. Yeah, I have to give it.
I still have to give it that tool to to do the refresh.
That's not implemented yet. But there we go.
(23:09):
There's a quick demonstration ofFestival.
Awesome. Thank you so much for showing
us. My pleasure.
One thing you mentioned was thatthe idea of making this big
project design dock to kind of guide things and get started.
Do you do any other like either markdown files or like project
docs that go out throughout yourproject, for example, like a
scratch pad or To Do List? Do you have any other assets
(23:31):
that help guide the LM throughout multiple
conversations? Yeah, so that's actually
something I didn't mention aboutone of the differentiators as
well. You know, while building this, I
built it on the same stack. So you know, it uses the full
stack fast API templates to deploy user applications, but
it's actually also built on the full stack API template.
(23:51):
And that's a template that I've been using for years now.
And so I'm pretty comfortable with it and I'm also pretty
comfortable with prompting models for working with it.
And so as I've been going, I've been creating this big long
system prompt that actually still has not been integrated,
but it will be very shortly to to basically help the model work
with the existing templates. It was best practices, you know,
like after modifying the back end, you should run the the open
(24:16):
API script to automatically generate the front end, for
example, rather than trying to implement a front end yourself,
like to prompt the model to implement the front end
yourself. So that's, that's one of the
pieces of text. I think that's going to make a
big difference. And then for myself, I also just
have like A to do to do file that's I just add to and that's
just something that I look at myself and that's not something
(24:38):
that I use with the models. It's just for me to keep track
in like a really quick way. I mean, I like using GitHub and
you know, something more professional if I'm working with
a team, but this one I'm just hacking on my own so far and
just minimum overhead of the text files.
So I just have A to do text fileand then of course there's a
read me. So I think that's really
(25:00):
important both for users and forthe model.
And so as as I'm going like, especially when it comes to
stuff like deployments, you know, you want that to be rock
solid. And so I always put into a read
me. So it's very, very clear, like
what's the right way to do this?Yeah, I've gone to the.
Habit where I've I've back on team mono repo used to do a lot
(25:20):
more micro services and try to separate some concerns, but now
just having everything in the same repository just makes it
that much easier to have AI makethe connections.
And I do a read me for each individual app as well as an
entire project, one with more like deployment best practices
things and always try to frame it with the the LLM pretend that
a new developer is going to comeon tomorrow.
Do they have all the informationthey need?
(25:41):
And then just let it update it each time.
Also with the caveat that like Iwant to prune update information
because it's so easy at a pending a pending and all of a
sudden you get a jarbled file that really doesn't help guide
because it stands so many directions.
So it is an iterative process. But I like the idea of a manual
To Do List. That's your document that you
know is accurate. Yeah, it actually.
Reminds me that I do have additional read me's throughout
(26:04):
the throughout the project, likefor for very complex or like
more complex features, I'll havethe model actually generates an
MD file that describes how that feature works so that if the
model in the future needs to understand more about it so it
can just read the the MD file. You don't want to smash that all
into the readme because I think it's too long like you said.
So it's all about that context, context engineering.
(26:25):
Yep, it's it's always. Comes down to that.
One thing you mentioned is that you use the the Fast API to
build Fastible. Is Fastible capable of building
another fastible? Like could it be a self
replicating thing? Yeah it's a great question.
I have to. Think about that one actually.
So I think ultimately the goal is for that to be the case.
But I think right now there, there's probably some
(26:48):
limitations around restarts, like starting and restarting
environments. So like sometimes, for example,
you know, the docker will run out of memory or something like
that and you have to like just kill the demon and restart it.
Like, yeah, as I was hacking on this, I was like creating new
projects because I was testing it and you know, I wasn't like,
(27:10):
I hadn't implemented like the, the, the project clean up logic,
right. And so eventually, like there
was no, there was no more room left on the image and I had to
like purge my, my docker system resources.
So that's something that's like could like theoretically be
built in into festival so that it's aware of that.
But you know, I haven't done that yet.
And there's a whole lot, a wholelist of things that I have to
(27:33):
sort of more high priority than that.
Eventually I think Fastible willbe able to build Fastible, but
not yet nice. Exciting times when we get
there. Just on that note with the with
the docker, do you know of any tools or systems workflows for
the dev OPS SRE level stuff? Because most of my interaction
(27:53):
with LMS is either on the codingside or just a general like Q&A,
but I've yet to find a system where it assists me with
deployment other than copy the logs, get advice, and then I
manually run commands. Do you know anything that helps
with that aspect? Yeah.
So the way that I've been doing that, I think it worked
extremely well, is by having themodel build its own deployments
(28:15):
tooling. And so that's how I deploy
Fastmo right now. It's just a deploy dot PY file.
Actually, I built something similar for the Microsoft Setup
Mark repo as well as the Microsoft Omniparcel repo.
It's just a deploy dot PY that has like a bunch of functions.
It's a good command line utilitythat you can call to like first
provision a server and then deploy the software to the
(28:38):
server and then like monitor logs or restart it like whatever
you would normally do. You have the model build its own
utilities for doing that and then it can easily interact with
the server or create a new one if it needs to because it has
this tool that I found has been very, very powerful.
That's super cool and it kind. Of goes along with a a a bigger
encouragement for people to explore docker because then you
(29:00):
can have the docker file and make sure that you have the
exact same environment set up every single time.
I actually really like that. I hadn't considered that.
Are there any other programmaticways of enhancing the developer
experience so you can leverage LLMS in like non coding ways?
Well, the one thing that comes to mind actually for me is, you
know, it's, it's basically, yeah, non coding ways.
(29:21):
So it's like as technical people, we're always very, very
focused on the tech, right. But you know, when you're
building, when you want to builda business, the technology is,
is generally not the limiting factor.
It's it's it's users and distribution.
And like, you know, understanding customer problems
is like a very orthogonal, just skill sets, technical stuff.
(29:42):
But luckily, you know, large language models have like a very
broad skill sets and so they're actually very helpful at that as
well. So when I was building fastible,
I use, you know, I think it was Chachi PT deep research as well
as Gemini deep research to do like a comprehensive review of
like the available tools that are similar, like not only
lovable, but like base 44 and the other ones.
(30:03):
And to really narrow in on what I could do that would be
different. And that was really, really
helpful because otherwise I would have had to do all this
research manually, right? And this way it was, it was done
for me very, very quickly. So basically I think it's useful
for anything. And my, my, my next step is is
going to be for the market, the distribution.
That's something I've never, I've never really cracked.
And so like I'm a complete novice at that.
(30:24):
And so I'm excited to start my my chat GPG education on on
distribution. Excellent.
Yeah. It's and it's, it's like you
said, it's a tough, tough egg tocrack because you can't rely on
the LM to do much like marketingcopy generation, because it's
clearly AI slop and it doesn't sound that good.
But there's ways you can leverage like automating e-mail
blasts as as an example. Like there are ways that you can
(30:47):
assist with it, but having the the strategic discussion with a
frontier model will probably help a lot.
One thing I want to pull back towith festival is you mentioned
with loveable. Sometimes it'll hallucinate
whether it's like packages, libraries kind of make things up
or use outdated. One thing I noticed is it
always, the LMS always tend to default to Beautiful Soup and
there's so many better web scrapers.
(31:07):
How do you, from the back end, either manage the prompts or
help with hallucination mitigation and try to keep it so
the code that's generated is using real libraries that are
the correct libraries? Like is there any validation
there? Yeah.
So it's similar to what we were talking about before with doing
the research. So basically when I'm building a
(31:28):
feature, what I'll do is I'll prompt the model to first do
research on like available libraries and tools that can
assist in building this feature.And then, you know, it'll, it'll
give me like some list and then I'll ask it to like, I can do it
myself, I can look at it, but it's taken to just OK, I'll pick
the best one and look up the documentation and then produce a
(31:49):
report on how to use this library for what it is that we
want to do. And this way again, it's
grounded in the, in the actual library's documentation.
So you can't rely on the models parameters to give you, you
know, useful results here. You have to have it grounded in
the actual library. And luckily, you know, models
have access to tools, so they can, you know, do a curl request
(32:09):
for example on the documentation.
And then that way it's grounded in in what library actually
does, as opposed to what it thinks it does.
Nice. And do you have some type of
storage or caching in case multiple users want to leverage
the same feature so you don't have to like curl the same docs
every single time? Yeah, that's a.
Really good. That's a good point.
So that's something I've been thinking about.
(32:30):
That's a tricky 1 though, because now like as soon as you
start doing that, then you know,users might I can imagine users
getting kind of miffed because there there was all sorts of
controversy around you know, I could have Co pilots reproducing
users code, right. So this is kind of a similar
thing where like I'm going to have one user build some feature
and then I'm gonna like cache that feature so that other users
(32:52):
can use it. You know, that first user might,
may not be too happy about that.So I think there's a way to do
this probably involves sort of like a manually curated set of
components. And that's what I was thinking
about doing for it cuz right nowwe, it just uses the e-mail
login that comes with the fast API template.
But I know a lot of people want like Google login, for example,
you know, I've built Google login before on this template.
(33:13):
It's easy to do, but like, why do it over and over?
So the user just wants Google login.
You can just be like, I want Google login.
It should be able to just pull it in without having to build it
up again from scratch, right? But then you have the problem of
invalidation. Like at what point does that API
become invalid and you have to update it.
So it's it's actually not such astraightforward problem, I
think. No, that's that's a very.
Good point. On the note of having the LLM
(33:37):
curl docs generate the report, alot of people would describe it
as a multi agent setup. Would you define it that way or
is it just like a series of APILMAPI calls that you control
the context for? How would you define the the
architecture in terms of how AI is implemented in Fastible?
Yeah. So that's a good question.
I always default when it comes to agents to anthropics
definition. I really like this idea of, you
(33:59):
know, an agents is basically piece of software that basically
decides what it's going to do next.
So it's, it's the model itself that's deciding what, what to do
next. So you basically have like this
wild true loop and then you justask the model, what do you want
to do next? And that's an agent.
So you're basically giving an agency it can control what it's
doing next. But the problem with that is
(34:20):
that the risk compounds, you know, language models
hallucinate, they have all sortsof limitations.
And so if you're just letting itgo off on it's own, it's going
to very quickly go off the rails.
So if you can avoid using agents, you should because it
depends what your goal is. If your goal is just to tinker
with agents, then sure, you can tinker with agents, but your
goal is to make working software, you know, or that
(34:42):
rather, let me back up. Your goal should never be to
make software. Your goal should be to make
something useful. And then what does it take to to
do something useful while you have to build some software and
you don't, you want to build as little software as possible for
it to be useful. You'll want to like go off and
build software for the sake of software, which I think agents
are really good at. So, you know, you tell them to
build software, they're going tobuild that software, a whole lot
of it. It's not necessarily going to be
(35:04):
helpful though. I think if you can get away with
just an API call, you should andand traffic defines us as work
flows. And I think that's a good,
that's a good term. So you basically as an engineer,
you know, what's what the what the proper sort of procedure is
for a certain type of user experience.
So you can encode that into the software.
(35:24):
But I guess this comes back a little bit to the better lesson.
So the better lesson is that like, you know, this, it was
Rich Sutton, I believe we coinedthis term.
And the idea is that, you know, AI researchers want to encode
their knowledge into AI to make the AI better.
And while that does improve the AIA little bit in the short
term, in the long term, it gets beaten out by just throwing more
(35:45):
data and more parameters, more compute at it.
That's sort of the, the, the tricky situation we find
ourselves in that's if you're going to use agents, you might
have a more like you're basically your software is going
to be more flexible in the long run.
And so it is very, a very fine line to, to draw, I think.
And it I, I'm still not, I'm not100% convinced about, you know,
(36:06):
I don't think there is any sort of like hard and fast rule.
I think it comes on a case by case basis.
What's the right approach? So right now everything in
fastible is very much a workflowexcept the Asian chat itself.
So like there's we're using likelarge language models calls
behind the scenes. So for example, create commit
messages, that's not an agent that's doing that because like I
(36:28):
know that I need to create a commit message.
So I'm just going to prompt a while to create a commit.
The only thing that's the the agent is is the is the user chat
when the user's trying to describe the feature that they
want to build. And then that's the agent in the
behind the scenes that's going in, you know, building the
software so that we give it access to some tool calls.
Like, you know, you can read theexisting files, you can write
(36:52):
files, you can restart the environment.
And then we give it like some budget, like you can go for 10
steps and then, you know, do whatever you're going to do in
those ten steps. You're going to read some files,
you're going to write some files.
I don't know, just go ahead. But I think it is important to
you have to cap it because otherwise it can go on for like
forever. And then you're going to have
like this massive bill and you're going to have a whole
(37:12):
bunch of useless software. We, we give in festival, we give
the user an option. Like we can say you can go for
like 10 steps, 1030 steps, 100 steps or some custom number of
steps. Very cool.
One thing since you brought the better lesson that I am
internally like conflicted aboutis creating tools for the LMS
because you get way more success.
Like the the likelihood of a tool called resulting in a
(37:34):
successful output is much higherthan having the LM just try to
generate the output by itself. But by creating tools, we as the
developers are kind of guiding it, directing it, imparting our
knowledge. What for you is the threshold to
develop a tool versus letting the LLM figure out the problem
on its own? Yeah, I, I think.
Probably the. It's a similar rule that's used
(37:55):
for refactoring, I would say. So if you're doing a thing once,
you should just do that thing once and then don't think about
it again. If you're doing it twice, make a
note of it. Make a note the hop.
I did this twice, maybe I shouldthink about not doing this
again. And then when you come around to
doing it the third time, I mentioned refactory.
Now you should probably refactorit into like a reusable
(38:16):
component, maybe not all the time, but I think a similar
thing is with with tools. So if you find that it's
something that you're you're youwant your model to be doing on
some like regular cadence, then you probably want to package
that up into a tool. Similarly, if it's like a very
(38:36):
complex thing that you can breakdown into a series of steps,
like you don't want to use models for everything because
they're expensive and they're not deterministic.
You want to use them just as little as possible, actually,
just where they're needed. And so then you want to sort of
create a tool that's deterministic and give that to
the model so they can call it when it wants to.
Yeah, no. And I fully agree as little LM
(38:58):
as possible in the work flows, fuzzy input to something
structured or allowing the output to be customized, but
through the middle, as much codeas possible just so you know
exactly what's going to happen. Other advice that I'd love to
hear from you is you, you were talking about context
engineering on a past episode, but specifically for building
full stack apps. It feels like there's so much
(39:19):
variability in what people couldbuild, but also because you put
guard rails on it. Do you have any advice for
people who say they're they're prompting to make their own full
stack app? What type of context engineering
should take into account? Like you mentioned the
documentation, but is there anything else that's relevant?
Well, so I mentioned. Like finding like the the target
market, like so I had when I wasdoing this, when I was building
(39:40):
fastball, I had two documents. One was the architecture
document, which describes the functionality and like how the
different pieces should fit together.
And the other one was the what Icall the economics document,
which was like, who is using this and why do they care?
And I think that was really helpful because certain, like I
think it came down to prioritization.
(40:00):
There was all sorts of stuff I wanted to build and like, I
still want to build, but you know, this is me sort of like
doing my, my engineering thing and users don't necessarily care
about these things. So I, I thought it was very
helpful to be ruthlessly like pragmatic and cutting scope.
So I would, I would have like this, this document would
(40:21):
describe all this functionality.And then I'd have this document
describing the users and what dothey care about.
And then I could use that to both of them together to sort of
figure out what should, what should I build next.
So to use that to prioritize thedevelopment as you build your
own. Apps to solve your own work
flows. You're going to want to power
the real data using MCP, and that can be a little bit scary,
but that's why I've been testingout Tool Hive.
(40:42):
Tool Hive makes it simple and secure to use MCP.
It includes a registry of trust MCP servers and lets me
containerize any server with onecommand I can install in the
client in seconds and secret protection and network isolation
are built in. You can try Tool Hive too.
It's free and it's open source and learn more at Tool Hive dot
dev. Now back to the conversation
with Richard. Since Fast World develops assets
that people ideally deploy to the web and actually use, how
(41:04):
much security concern do you have to manage versus how much
is on the responsibility of the user?
Are there things built in to help prevent security risks, or
is it one of those things peopleshould talk to a ChatGPT or
Claude to get a better understanding so they can put
these garters on before it's deployed to that could cause
actual harm? Yeah, that's a really good
question. So there's a couple of places
(41:25):
where we're handling that. One is in usage of secret, like
Castable itself has a bunch of secrets, like for example, your
API key that you're putting in there.
So to mitigate any security riskthere, we're actually not
storing them, we store them in GitHub.
So what's actually happening on the back end is we're creating
private repos for every product that's created.
(41:45):
And then we're just using the GitHub repository to store all
the secrets. And that way, I mean, there's a
big dependence on GitHub, but that way, you know, we're sort
of relying on Microsoft and they're like armies of engineers
to to make sure that's your secrets are safe.
When it comes to the agent itself and what it's building,
This is still a work in progress, but we're we're using
(42:07):
a similar, I guess, an approach that the full stack fast API
template takes, which is just a dot N file.
So the in the Git ignore you have like it's we're basically
explicitly telling gets to ignore this particular file,
this dot end file. And the dot end file contains
all the secrets. And this is part of the the
system prompt that I mentioned earlier so that the model knows
(42:28):
that, hey, if I need to create secrets, they should be stored
here. And you know, that dot end file
gets populated by by the application at runtime.
I'm sorry, the the environment variables get populated via the
dot end file at runtime. Yeah, you're not ever committing
any secrets to get. Now that's not obviously like a
(42:50):
hard and fast, like it's still possible that if you tell, if
you paste a secret into the chatand you explicitly give it
instructions like, hey, put thison the front page.
Well, it's going to do that. So there's no, there's it's hard
to mitigate against that. There, there there is.
Perhaps like I have some ideas around that, like for example,
just filtering everything that goes through some level of
(43:10):
application. You can just do some search and
replace for for for secret names.
So anything that ends with like API key or something as some
sort of fall back. But even that's not foolproof,
right? So I think at the end of the
day, somebody's going to do, somebody really wants to do
something that's insecure, like we're going to let them, we're
not going to prevent them. And there's no there's no way to
do it actually. Yeah, and and similar.
(43:31):
Most leaks, most vulnerability say are it's the human's fault
we're we're the weakest link in the whole security apparatus.
The fact that by default these GitHub repos are private allows
it to be contained at least for someone to audit.
If you have one of those GitHub action bots running to kind of
scan your code, there's another layer of of security people can
add. There's always risk when you
start putting stuff up there andthe best thing we can do is try
(43:52):
to educate people and put some degree of guard rails on.
But if they just vibe code theirown thing anyway, it's going up
on the Internet. So at least this way you have a
bit of control over what we can prevent.
Just a few general thoughts. Back in the day I worked for a
no code app company and now withall of these tools like Fastible
and other prompting to app output, do you see no code as as
(44:14):
reaching it's end or do you still see a place for it?
Yeah, it's interesting. I was talking.
To a friend of mine who is a bigproponent of bubble.
So if bubble is this sort of no code application builder and you
know, a lot of people built likeentire dev shops and in careers
on, on building on bubble. So I, I've got the, I guess that
I think they probably have theirplace.
I think I was asking him why he likes it so much and he was
(44:36):
saying he really likes the idea of just being able to point and
click. So like, I want a widget here
and you can just click here and you get a widget here as opposed
to like you have to describe to the model like, oh, I put it
like on the left of this other. So, but I think there's a, this
is another feature I want to build into Fastible.
It's basically just you can justyou can build the same thing
where you just click on whereveryou want a thing and then prompt
(44:58):
like, oh, I want a thing here. And so that shouldn't be too
hard to build. It's not implemented yet.
So I think that eventually thesethings are going to converge.
I think. I think Bubble already has some
sort of AI tools they're building and, you know, it's
just the first level, right? They're going to continue
expanding on it. And you know, these AI builders
like Fastball, we're going to build in these no code features
like point and click. So I think they're going to
(45:20):
probably converge. Yeah, Yeah, the ability.
To have, whether it's a coordinate system or just a way
to capture where the user clicksand then feed that through, I
think that'll work once it's implemented.
So one thing that tools like Fastible enables is this idea of
disposable software where you get an idea, you spin up
something really fast, you try it out, if it doesn't work,
whatever, you can try again, throw it away.
(45:41):
You lost, you know, a couple dollars, a little bit of time.
But ultimately the idea that software doesn't have to be as
have the same longevity as it used to because there's a lot
less sunken cost. What are your thoughts on that
as a general trend? Do you think it's a good thing,
a bad thing? And where?
Where are we going with disposable software?
Yeah. Andrew Ng gave a talk on this
recently, the Y Commodator Startup school that they liked.
(46:05):
People were saying what he was saying, that's people are saying
that's now the time to stop training people to write
software because the value of software has has plummeted.
And he said it's true that the value of code has plummeted
because now you can generate code, you know, instantaneously
for like fractions of a cent, but it doesn't mean the value of
software has plummeted. And he, he actually thinks that
(46:26):
it's the opposite. He thinks that now as software
becomes more and more accessibleto people, the value of software
is going to increase because people are going to make more
software to basically solve likeeven more specialized problems.
So I mean, it's impossible to tell the future.
And obviously I'm biased becauselike I like building software
(46:48):
and I don't want to go away. So but I sorry, I like what
Andrew and entering is biased too, because you can create
course 0. Course 0 is all about learning
how to code, right. So yeah, it's really, it's
really hard to predict the future, but at least for the for
now, until you know, AGI is, is here, which I don't think it
necessarily is yet. I don't think there's, I don't
think that the value of softwareis going away.
(47:09):
I think, I think we're, I think we're safe for a little while.
I agree and I think. There's there's a couple other
principles that I think we'll tie into this too.
I'm a big proponent of Obsidian,the whole file over app
principle because if you can control your data and keep your
information on your computer andjust develop different types of
software to interface with that data, it doesn't matter.
Like I'll use Obsidian for my note taking, but I had someone
who didn't like the way the tasks were able to be
(47:32):
prioritized and want some a little more automated.
Instead of making a plug in, they just spun up an entire app
where it read the same vault, took in the markdown files, look
for the the dash in the square brackets that designate a task
and then just brought them all in.
And then a nice draggable interface that you could add
tags to to prioritize just a a anew wrapper around the data.
So I think people just need to get into the habit of start
(47:53):
finding ways to make your data portable because the way that
you interface with it is going to be, you know, whatever you
want it to be soon. Interesting.
Yeah, I, I, I could see that being a conflict with the with
like a bunch of big companies that, you know, their entire
business model is around like having your data and giving you
access to it. So that might be, so there might
be some friction there. Yeah, do do you?
(48:13):
Think SAS is going to be affected by products like
festival so I I heard. Already that's it.
It already is being affected because yeah, it is so, well, I,
I, I've heard a couple of different, different claims
about this. So 1 is that it's already being
affected because it's becoming so, so simple to spit up new
SAS, new software products. And so like, there's like an
(48:37):
people are claiming that there will be an inundation of people
would be sort of overly saturated with different
products. But then there was this report
that was released recently with suggested the opposite.
And if somebody had done some empirical analysis showing, I
can't remember which data sources, but they basically
suggested that, you know, despite the fact that the value
(48:57):
or the, the, the energy requiredto create software has decreased
so much, the actual amount of software being produced is not
changing that much. It's still sort of on the same
trend as it was before LOMS cameon the scene.
I think it's still too early to tell.
Yeah. It's.
People can't predict the future and now it's it's harder than
ever. Richard, this was a blast.
(49:17):
I'm I'm pumped on fastball. I hope more people try it out
Before that you go. Is there anything else you want
the audience to know? Just check it out.
It's free to use other than the API key.
So go to fastball dot dev and you need to GitHub account.
For now I'm going to be adding in Google login so you won't
need that and just give it a shot.
Thank you for listening to this.Conversation with Richard A
bridge. I'm so glad he came back.
(49:38):
I always have a blast talking tohim and he always provides some
insight that I just didn't really consider.
If you're looking to build your own app, I suggest you check out
festival. It's free with your API key so
you're only paying for the usage.
And this way you can start getting into the habit of
building disposable software, software that's made for your
specific use case at the specific point in time.
Maybe you'll change in the future, maybe you'll just throw
(49:59):
it away, but the act of building, exploring and seeing
what's possible is very rewarding in itself, let alone
the productivity gains from getting a tool that's hyper
customized to your use case rather than generic off the
shelf stuff. So I want to give a quick shout
out to Tool Hive for supporting the show so I'm able to have
conversations like this and please let me know what else
you'd like to see, what has inspired you?
What are you building these days?
(50:20):
And if you could like and subscribe, it would really mean
a lot. So thank you and I'll see you
next week.
The value of code has plummeted because now you can generate
code instantaneously for fractions of a cent, but it
doesn't mean the value of software has plummeted.
As software becomes more and more accessible to people, the
value of software is going to increase because people are
going to make more software to solve even more specialized
problems. That's a real opportunity of
creating a tool that somebody like my brother can use to
(00:21):
actually solve their own problems.
What does it take to do something useful while you have
to build some software? The way that I've been doing
that, and I think it works extremely well, is by having the
the model build its own tooling.If you can avoid using agents,
you should. Tools that build tools are the
ultimate unlock for productivity, but how do you
build them? Today we're joined by Richard
Abridge, an AI consultant who previously was on tool use back
(00:42):
in episode 10. He's recently built Fastible.
It's a tool that allows you to build full stack apps from a
prompt in your browser. So in episode 56 of Tool Use,
brought to you by Tool Hive, we're not only going to learn
about Fastible, but how Richard built it, his development
workflows, advice on context engineering, and his approach
for hallucination mitigation. I always have a great time
talking to Richard. He's a super smart guy and he
(01:04):
built this tool for himself. So it solves real problems.
And you'll be surprised how his approach seems to make way more
sense than what the big names inthe space do.
So please enjoy this conversation with Richard A
Bridge. So I've been building Fastible.
So I wrapped up a contract with Microsoft 3 months ago and on
that Crunch contracts we built basically this full stack web
application, agentic web application that would analyze
(01:26):
documentation and find errors. What really struck me about that
experience was like my productivity because that was my
first time using Vibe coding tools.
So I used Windsor and I was justblown away at how, how fast I
was building and not just me, like the engineers on the team
were also like, how are you doing this so quickly?
What's happening? And, and so that's, that's when
(01:48):
I started thinking like, like these are some pretty good
engineers I'm working with. They, they know a thing or two.
Like one of them won the 2nd place at the World AI Fair
hackathon in New York City. And he was telling me that my
productivity was like amazing. And I was like, you know, it
wasn't, it wasn't like anything that I was doing in particular.
It was just, I think the processof it was, it was the vibe
(02:09):
coding, but not just vibe coding, but it was the process
of basically integrating logs like, so I would prompt, you
know, Windsor to build some feature and it would, you know,
do it's thing. Well, you know, it wouldn't just
be like, build this feature. There's, there's more to it than
that. But after it was finished, it
would say it's done. And then I would test it and it
was broken. And so I, I quickly found that
(02:31):
the easiest way to, to basicallyget it to fix itself was just to
copy and paste logs, like the relevant logs, either from the
browser console, if it was frontend or from the docker container
if it was back end, back into the, into the context.
And I was just amazed at how much time I was spending just
(02:52):
doing that. You know, there was, there was
like such brain dead work that Iwas doing.
I was just copying and pasting logs like I had to know where to
look for the logs, but that's what it was.
And so it occurred to me that, you know, this is obviously not
something that a human should bedoing.
This is something we can automate.
And then I learned about, you know, Lovable.
(03:14):
Lovable is like the fastest company in history to go to 100
million ARR, right? And I was looking into sort of
common sort of complaints, like on Reddit forums about users
experiencing with Lovable. And it was basically exactly
what I described, that you wouldgive it some instructions and it
would go away and sort of execute on those instructions
and come back and tell you that it's done, but it wasn't done.
(03:35):
And then you'd have to sort of do it over and over and over
again. And especially for non textable
users, they get really, really frustrated.
And so it just became clear to me that like you can solve this
problem fairly easily by just closing the loop and piping the
logs directly into the agent. And so that was really the
motivation for building Fastible.
So that's what I've been building for the last three.
Months. Nice, very cool.
Yeah. And they gave it a test spin and
(03:55):
it is a really cool set up. Could you talk a little bit
about the difference outside of just like the log loop being a
full stack app rather than just like a nice GUI that people can
put together? One of the other limitations I
guess with with lovable and and clones are that they're, they're
basically all built on like pureJavaScript and super base of the
(04:17):
database. And I guess, you know, that
leaves out a whole, that leaves a lot of opportunity.
I think like not everybody wantsto use super base.
You know, it can be pretty expensive when you start scaling
and there's also some other tools that like you don't need
to use super base, super base, right, like Postgres for
everything is my motto, open source and it does everything.
And so that's that's probably one of the most significant
(04:39):
differentiators is is the text stack.
So we're using fast API, which is Python framework and we're
actually using the official fullstack fast API template, which
uses React on the front end. That's not too dissimilar on the
front end from global, but on the back end we're using fast
API and for the database we're using doc Postgres and it's,
they're all deployed via Docker.So that's sort of, I think one
(05:01):
of the big differentiators is that it's using, I would say
like more vanilla text stack then then Lovable and, and Co.
And so everyone who is more familiar with that text stack
and you know, is more comfortable building in it and
wants to have the advantages of not being locked into Superbase,
that's really who festival's for.
That's the differentiating. Nice.
And one thing I did see also comes right out-of-the-box is
(05:24):
e-mail authentication, because anytime you get into the realm
of security or off, when you getnon-technical or non experienced
people vibe coding up at their own project, it's just something
you don't consider. So by including it, you really
allow people to kind of skip therisky part and just say, hey,
like I can make sure only a subset of people can actually
access this or that you authenticate them ahead of time.
Are there any other limitations that you see using Festival
(05:46):
versus, you know, of just like opening up cursor or windsurf
and just going nuts on a project?
So I think the main limitation, but I, I see it, it's not really
a limitation, it's a deliberate design choice is that it's, it's
a significant constraint. So when you're using cursor, you
can write anything, right? You can write Rust, you can
write C++. I mean, your mileage may vary
because the training of the models, you know, the data might
not, might not be there. So they might not do as well in
(06:08):
those languages. But the idea with like Cursor
and these sort of general purpose tools is that their
general purpose. So you can build anything you
want, whereas Fastible is reallyfocused on building full stack
web applications now like you don't.
It doesn't have to be full stacklike you can, you can just, you
know, focus on the back end and just deploy the back end if you
want. But it is constrained to fast
(06:29):
API and Postgres and Docker. So if you don't want to use
those things, then you should probably not use fastible in the
future. We might extend that for now.
That's, that's the that's the limitation.
And it's a deliberate design choice for two reasons.
One, it's part of the full stackfast API template, which is, you
(06:50):
know, it's a really, really popular project that I've worked
with a lot over the years and lots of other people work with.
And it's pretty good product to start to build applications
from. And second, yeah, it uses these
languages that large language models really excel at, which is
TypeScript and Python. So if you want to build on Go or
(07:11):
REST, you might have more trouble using large language
models because they don't have the same amount of training data
in those languages. No, absolutely one thing in
terms of the usage. When you were on episode 50, you
mentioned garbage in, garbage out and the importance with
context engineering. As soon as you start opening up
these tools to people who aren'tas experienced with prompting,
there is the risk of when they're interfacing with the
chat aspect of it that they do put garbage in because they
don't really know what they're asking for.
(07:32):
They may be too abstract. How does either Fastible help
prevent that or mitigate it, or just like assist users to be
able to be as natural as they want without having to know
their correct terminology? Yeah, that's a great question.
Right now it does not. It's all right.
It's still a work of progress. So the goal, yeah, the goal is
to make it available to non-technical users.
So I'll back up. Actually.
Like part of the reason I started building it was because,
(07:56):
again, it was because of my brother.
My brother will start vibe coding his own.
So my brother's an electrophysiologist and he had
some new requirements around like billing.
He had to enter in billing codes.
And so he started vibe coding his own web app, which was then
accepted into a conference. You know, I was sort of helping
him along sort of along the way if he had any questions.
But it just occurred to me that that's a real opportunity is
(08:19):
creating a tool that somebody like my brother can use to
actually solve their own problems.
And so that's the motivation I want to make it so that
non-technical users can use that.
But so we're not there yet, maybe next, maybe next time.
So the way that's I'm thinking about going about solving that
just something that's other people have already started
building is essentially like a design assistant.
(08:41):
So before going off and like actually converting the prompt
into code, the first thing that you should do and that I do when
I'm by coding is converting my prompt into a better prompt.
So using a large language model to like assist me in building
this prompt. And that's actually how I built
Fastable as well. It was actually before I started
coding anything, I spent over a week just iterating on a design
(09:04):
document and the document said if we can wait too long.
And I had to eventually like pair it down.
But it really helped in basically setting the context
for the model. So that's basically every time I
wanted to build it. You know, you're not gonna do
the whole thing in a single context.
You have to create a new contextevery time.
And so you need to have some sort of shared contacts that
(09:26):
you're moving between these different conversations.
And so basically just manually created a Google Doc by
prompting a large language model.
The goal is to make is to build that into Fastible so that
before you start actually coding, the agent is going to
help you through creating the design.
And ultimately the goal is that,you know, we don't even have to
(09:49):
be aware of what's happening in the background.
I don't know if that's going to be possible.
And maybe I shouldn't want that to be possible because then
we're all out of a job. But that's that's the goal.
Excellent. Yeah.
And my my day job at Box 1 doingthe AI Academy, I've been trying
to teach everyone how to build their own tools using cursor
clod code. And one of the issues we've run
into is just the fact that non-technical people with
Infinity opportunity through these things, I can steer like
(10:12):
they can go off the rails. It can do things that are
unintended, like had unintended side effects.
So by being able to put these guardrails on and say here is
going to be a well structured web app that you can deploy
automatically sync up to your GitHub.
I feel like that's really going to alleviate a lot of the issues
where allowing people to have like the Wild West of AI
tooling. Do you envision Fastible mostly
(10:34):
being in the zero to 1 stage of the development life cycle?
Or is it something that if I have an existing project,
whether I built it on Fastible or otherwise, I can iterate,
refactor and try to build upon it?
Yeah. Thank you for asking that
question. So one of the features that I
just deployed was Biscuit project import feature.
So if you already have a project, and again, this is this
is for my brother who I've codedhis app, but who wants to use
(10:57):
Fastible. So now if you already have a
project, whether it's vibe code or not, you can just specify the
GitHub URL and Fastible will clone that, the GitHub
repository and then convert whatever it is into the Fastible
stack so that you can have sort of whatever it is that you have.
Even if it's like something in acompletely different language,
you can convert that into into the same stack.
(11:19):
Zero to, I guess zero to 1. It depends how you define one.
So Lovable defines 1 as like an MVP, right?
So where it's not even, it's more like a almost a mock up
where it's just basically like the, there's sort of like AUI
and maybe some basic back end functionality.
But most people are finding thatthey have to move off of Lovable
to actually bring it to production.
So the goal with Fastible was toremove that sort of limitation
(11:42):
so that users can just stay in the platform and build the full
the full application there, actually deploy it and
everything. We don't have deploy like we
have the the live staging environment where you can share
that with your friends. But that's sort of like on our
hosting environment. Eventually we're going to be
building it so that it actually helps you deploy into your own
hosting environment as well. But still A to do.
(12:03):
But yeah, the goal is to is to make it so that you can build
the full application from start to finish in Fastible.
Very cool. I did see that it's bring your
own API key. So it's nice where I don't have
to worry about paying a monthly SAS subscription right now.
I can just kind of control my usage.
Do you have a general estimate? I know with like projects,
there's such a wide range, but how much will it cost someone to
(12:24):
do something from like a basic to do app to something a little
more complex? So we're looking at like
dollars, 10s, hundreds, thousands.
How much can they expect to spend on API costs?
Yeah, I'd say for A to do that maybe around $10, you know,
depending on how, how, how complex your to do app is, like
just add it like relatively simple stuff, it's like $0.10.
Like adding like some animated background is like $0.10.
(12:47):
And so yeah, you might have to do that a few times to make a
dodo app. So you can get to like a dollar
to $10.00 for a basic app. Yeah.
It really depends what you're building though.
Nice, and you did mention the pre prompt, the prompt
optimization. You can chat UBT.
Are there any other tools that you think people are either
using or should explore that would help augment and
supplement using fastball? Well, like I said, I mean, I, I
(13:10):
want fastible to be sort of the platform where you can build
like I'm building this for myself really.
Like I've done a lot of full stack applications as part of my
job. And so I'm really building it
for myself to make me go faster.And one of that's why one of the
things I want to build is this sort of design iteration tool,
so I don't have to do it with Google Docs and ChatGPT.
(13:31):
But yeah, until that's there, you can always go to ChatGPT or
any other model. And just that's why there's a
copy button in the agent's chat window.
So you can just easily copy the full agent context and paste it
into another model. To give you sort of a second
opinion, there are some tools that I've come across just
recently in the last few days I just saw on Twitter.
(13:52):
I haven't actually had a chance to reuse them yet though.
But there, there is at least onetool that's basically what I'm
describing. That's it's just basically like
a design assistant where you type in like, oh, I want to
build this thing and it sort of leads you through sort of
engineering design. At the end you get sort of a
design document. I'll I'll see if I can dig up
that name for you and send it toyou afterwards.
Perfect. Yeah, we'll include it down
below. Another, another big difference
(14:12):
between fastible and lovable is the fact that it doesn't try to
hide the complexity from you. So lovable, I think it's really
intended for non-technical users.
And as a technical user like that was I found out a
limitation and so did other folks that I that I spoke to
about it. So with Fastible, the goal is
that you shouldn't ever have to look at code if you don't want
to, but you can't if you do. And so we have like a full,
(14:32):
there's a full editor in there, like a file browser.
You can view the diffs and you can accept the reject diffs by
file if you want. You don't have to.
You can just do it by the cowboystyle and just not look at
anything. But if you want to, it's there.
And I think that's useful for technical people who might have
an opinion about how something should be implemented.
Or more importantly, the reason I built it was because sometimes
(14:53):
the model will just screw up something very, very minor and
you don't want to have to like spend let's say like $0.10 or
weights, you know, a minute for it to fix it.
You just want to press like backspace and fix it yourself.
So that's what that's there for.I think that's the other key
differentiator. Nice.
And one thing I do like about the deploy to GitHub aspect is
on a lot of my projects, I've actually installed either Mentat
(15:14):
or Claude code in in the GitHub action.
So if there's APR pushed up, it'll actually review it, give
some feedback. I can kind of guide a little
that way. So actually curious what what
models or model or models are powering Festival?
Yeah, right now it's just cloud code.
Nice. And the reason is because when I
started building it, that was the one with the best API.
I, I looked at a few other ones like Open Hands was the first
(15:35):
one because I wanted to make it open source initially, but I had
some trouble integrating Open Hands and there were a few other
ones. But then I looked at the Cloud
Code API and it was clearly likethe most advanced and well
documented. So that's the one that's enough
going with. But now since then, there's been
open AI codecs has been releasedand as well there's, I think
(15:56):
Gemini has something I don't know, but I haven't looked at
the APIs though for those ones. But the goal is to integrate
those as well. So you can sort of pick which
pick and choose you know what model provider you want.
Very cool. We actually had Graham new big
from open hand on here back in the day.
So we got a little message get him to step it up.
Yeah, yeah, it's really cool. Actually just this past week
I've I've took the switch to codecs to give it a try because
(16:17):
I heard a lot of good things. One thing I dislike about it is
if you ask it to do corrections or explain the justification for
the code, it suggests it will rewrite the code and you have to
accept or decline it before it'll give you the explanation.
And I really like with cloud code, it'll do like like
conversation first, code second.But opening I sent to flip that
just a small little user thing. But when I upgraded, I think I
(16:38):
was on 0.9 and then it got up to0.28.
So they're, they're shipping fast, they're making big
improvements. So yeah, I definitely hope more
people try it out just to see like you got to explore these
different tools and see, see what works with you.
Yeah, exactly. I think another big
differentiator in terms of the models is the clock code is like
probably the most expensive one out there.
So yeah, we've already had some comments from users that like,
oh, this is this is adding up. So that's that's one of the
(17:00):
reasons why I want to switch or at least add the option to
switch. Yeah, having the the toggle bowl
or there's like a drop down listtends to be helpful, but it's
tough when you're when you're looking for certain results.
It's really tough to beat the state-of-the-art.
We just get spoiled with it. We get used to being like, oh,
you know, 4.1 Opus can output this, this is what I want.
Turn on Max mode and cursor and you know, deal with the cost.
Yeah, especially because really the most expensive thing is your
(17:22):
time, so. Save time and if you compare it
to the salary of another engineer or outsourcing to a
consultant, if you're able to work through it, it is a massive
reduction. Yeah, yeah, when you log in,
you'll see the screen where you can create a project.
So you can create a new project here.
You can just describe whatever you want it to be, like my
social media app or something like that.
(17:43):
And if you have an existing project, here is where you can
paste it, get a repo and you canimport it.
All right, so once you've created an application, this is
sort of the screen that you'll see.
This will take a couple of minutes to load up.
One of the things on my very long To Do List is to speed this
up. But while it's going, let's
describe quickly what's happening.
Basically, there's there's a bunch of containers that need to
(18:04):
be speed up in the background, like the back end container, the
database. And as they spin up, you'll
start to see them here. So here's where you see like the
Postgres of the database and youhave like the full the full logs
here. Here's where you get browser
logs, which is this is pretty powerful.
And it took a little bit of hacking to make this work.
But basically what you're seeinghere is actually once it's
loaded anyways, this is an iframe.
So it's not, it's actually loading it from a separate
(18:27):
website, your website, it's creating a new website just for
this project. And that website is gonna be
loaded here. And the logs for this website
for that website is what you're seeing here.
So on the browser, there's nothing happening cuz it hasn't
booted up yet. But you can see the front end.
It's like installing dependencies.
The back end as well. It's faster after the first time
cuz it doesn't have to install everything from scratch while
(18:49):
it's going. I can also show you this stuff
here. So here's where you see like
this is sort of like the power user features here.
If you, if you really care aboutcode, you can come look at it
here. I'll open up the login route so
we can have something to look atreal easily.
And so you can see there's like a nice syntax highlighting here,
right? So this is this is now your
website and you can see like it already has this login form.
And so given these credentials here, these credentials are
(19:09):
generated automatically for you.If you want to log in, you can
log in. And here's here's sort of like
your application. You can see there's not much
here yet. This is just the the standard,
the default fast API template. And you can see also there's
these access URLs. So if I go here, for example,
you'll see that it's actually loading up like this.
This is the website that you seehere and, and it's it's being
(19:32):
hosted in this domain name here.And yeah.
So if we go to like, let me log out here and go back to that,
that login route. Give a demo here of how this
works. So I can, I can, I can just edit
and it's live reloading. So I'll just say like hello, you
can see immediately it shows up there.
(19:54):
And so you have your hello up here and then you have like your
syntax highlighting and you alsosee this diff here.
So if I, if I open this, you cansee that it shows me the diff
and I can also just go back and edit it.
All right, so that's that's sortof like the power user feature.
But if you want, you can just like hide that all together and
not pay attention to it. And you can just say like add a
(20:15):
giant emoji to the login page and this will just take a
second. But on the background, it's
starting up like a cloud code context and Cloud code's running
inside of the container that's running the application and
actually modifying the the live code.
There you go, added a giant emoji.
And so if I go, I can open up this guy here, you'll see that
(20:36):
the should be. There you go.
Here's the depth of what it added.
And so now if I want to, I can, I can just start it or I can
commit it. So if I commit it, you'll see
it'll generate a commit message for me.
Add rocket emoji and hello text to login page.
And I can commit that. And there you go, it's
committed. So there's no state changes.
(20:56):
And now if I want, I can go to my project and I can say, push
to GitHub. That's new.
My demo. Yeah, exactly.
Yeah, but normally this works and and you can can, you know,
export your project to GitHub and and do what you will with
it. And I did really show the, the
value of the of the logs here. But one thing I I wanna demo
(21:20):
just real quick is let's say in the login page, I want to say
console dot log hello world. And you can see it's it's it's
grabbing the logs there. And so this is useful because if
something was broken, the, the console would throw an error.
And then I can just copy that and paste it back into, into the
agent. And so this is basically closing
(21:41):
the loop for, for the agents to,to ground it in the actual
environment. And then, as I mentioned, you
have this sort of copy feature here.
You can copy just the, the, the top level messages, or you can
also expand. And there's much more details in
here. You can see for each message and
also get to the cost, which is something that's I think for
some reason most of the not for some reason I think to encourage
(22:01):
usage. Most of the provide like the the
other tools, they sort of hide this cost, which I find sort of
some optimal. I'd like to know how much I'm
spending. So there you go.
It costs $0.15 to add this emojiusing cloud code.
Yeah, the transparency is alwayshelpful just to get a better
understanding of what you're actually doing.
And yeah, I agree. Yeah.
And then you can also see, you know, let's give an example of
(22:24):
like an error. If I just say food here, we
should get an error. There you go.
Something is not defined, Food is not defined.
And so if I just copy this and then I can create a new chat
because this this chat, let's say it's not relevant.
So use a fresh context and I canjust paste it in and hopefully
it'll pick it up if there's an error and try to fix it.
(22:48):
There you go. Can see there's a reference
error, can see the issue unto myvariable Foo.
Well, you can see it remove Foo.But I still haven't given it the
the tool to re to restart the environment.
So I think if I refresh it, willthat fix it?
Yeah, There you go. Yeah, I have to give it.
I still have to give it that tool to to do the refresh.
That's not implemented yet. But there we go.
(23:09):
There's a quick demonstration ofFestival.
Awesome. Thank you so much for showing
us. My pleasure.
One thing you mentioned was thatthe idea of making this big
project design dock to kind of guide things and get started.
Do you do any other like either markdown files or like project
docs that go out throughout yourproject, for example, like a
scratch pad or To Do List? Do you have any other assets
(23:31):
that help guide the LM throughout multiple
conversations? Yeah, so that's actually
something I didn't mention aboutone of the differentiators as
well. You know, while building this, I
built it on the same stack. So you know, it uses the full
stack fast API templates to deploy user applications, but
it's actually also built on the full stack API template.
(23:51):
And that's a template that I've been using for years now.
And so I'm pretty comfortable with it and I'm also pretty
comfortable with prompting models for working with it.
And so as I've been going, I've been creating this big long
system prompt that actually still has not been integrated,
but it will be very shortly to to basically help the model work
with the existing templates. It was best practices, you know,
like after modifying the back end, you should run the the open
(24:16):
API script to automatically generate the front end, for
example, rather than trying to implement a front end yourself,
like to prompt the model to implement the front end
yourself. So that's, that's one of the
pieces of text. I think that's going to make a
big difference. And then for myself, I also just
have like A to do to do file that's I just add to and that's
just something that I look at myself and that's not something
(24:38):
that I use with the models. It's just for me to keep track
in like a really quick way. I mean, I like using GitHub and
you know, something more professional if I'm working with
a team, but this one I'm just hacking on my own so far and
just minimum overhead of the text files.
So I just have A to do text fileand then of course there's a
read me. So I think that's really
(25:00):
important both for users and forthe model.
And so as as I'm going like, especially when it comes to
stuff like deployments, you know, you want that to be rock
solid. And so I always put into a read
me. So it's very, very clear, like
what's the right way to do this?Yeah, I've gone to the.
Habit where I've I've back on team mono repo used to do a lot
(25:20):
more micro services and try to separate some concerns, but now
just having everything in the same repository just makes it
that much easier to have AI makethe connections.
And I do a read me for each individual app as well as an
entire project, one with more like deployment best practices
things and always try to frame it with the the LLM pretend that
a new developer is going to comeon tomorrow.
Do they have all the informationthey need?
(25:41):
And then just let it update it each time.
Also with the caveat that like Iwant to prune update information
because it's so easy at a pending a pending and all of a
sudden you get a jarbled file that really doesn't help guide
because it stands so many directions.
So it is an iterative process. But I like the idea of a manual
To Do List. That's your document that you
know is accurate. Yeah, it actually.
Reminds me that I do have additional read me's throughout
(26:04):
the throughout the project, likefor for very complex or like
more complex features, I'll havethe model actually generates an
MD file that describes how that feature works so that if the
model in the future needs to understand more about it so it
can just read the the MD file. You don't want to smash that all
into the readme because I think it's too long like you said.
So it's all about that context, context engineering.
(26:25):
Yep, it's it's always. Comes down to that.
One thing you mentioned is that you use the the Fast API to
build Fastible. Is Fastible capable of building
another fastible? Like could it be a self
replicating thing? Yeah it's a great question.
I have to. Think about that one actually.
So I think ultimately the goal is for that to be the case.
But I think right now there, there's probably some
(26:48):
limitations around restarts, like starting and restarting
environments. So like sometimes, for example,
you know, the docker will run out of memory or something like
that and you have to like just kill the demon and restart it.
Like, yeah, as I was hacking on this, I was like creating new
projects because I was testing it and you know, I wasn't like,
(27:10):
I hadn't implemented like the, the, the project clean up logic,
right. And so eventually, like there
was no, there was no more room left on the image and I had to
like purge my, my docker system resources.
So that's something that's like could like theoretically be
built in into festival so that it's aware of that.
But you know, I haven't done that yet.
And there's a whole lot, a wholelist of things that I have to
(27:33):
sort of more high priority than that.
Eventually I think Fastible willbe able to build Fastible, but
not yet nice. Exciting times when we get
there. Just on that note with the with
the docker, do you know of any tools or systems workflows for
the dev OPS SRE level stuff? Because most of my interaction
(27:53):
with LMS is either on the codingside or just a general like Q&A,
but I've yet to find a system where it assists me with
deployment other than copy the logs, get advice, and then I
manually run commands. Do you know anything that helps
with that aspect? Yeah.
So the way that I've been doing that, I think it worked
extremely well, is by having themodel build its own deployments
(28:15):
tooling. And so that's how I deploy
Fastmo right now. It's just a deploy dot PY file.
Actually, I built something similar for the Microsoft Setup
Mark repo as well as the Microsoft Omniparcel repo.
It's just a deploy dot PY that has like a bunch of functions.
It's a good command line utilitythat you can call to like first
provision a server and then deploy the software to the
(28:38):
server and then like monitor logs or restart it like whatever
you would normally do. You have the model build its own
utilities for doing that and then it can easily interact with
the server or create a new one if it needs to because it has
this tool that I found has been very, very powerful.
That's super cool and it kind. Of goes along with a a a bigger
encouragement for people to explore docker because then you
(29:00):
can have the docker file and make sure that you have the
exact same environment set up every single time.
I actually really like that. I hadn't considered that.
Are there any other programmaticways of enhancing the developer
experience so you can leverage LLMS in like non coding ways?
Well, the one thing that comes to mind actually for me is, you
know, it's, it's basically, yeah, non coding ways.
(29:21):
So it's like as technical people, we're always very, very
focused on the tech, right. But you know, when you're
building, when you want to builda business, the technology is,
is generally not the limiting factor.
It's it's it's users and distribution.
And like, you know, understanding customer problems
is like a very orthogonal, just skill sets, technical stuff.
(29:42):
But luckily, you know, large language models have like a very
broad skill sets and so they're actually very helpful at that as
well. So when I was building fastible,
I use, you know, I think it was Chachi PT deep research as well
as Gemini deep research to do like a comprehensive review of
like the available tools that are similar, like not only
lovable, but like base 44 and the other ones.
(30:03):
And to really narrow in on what I could do that would be
different. And that was really, really
helpful because otherwise I would have had to do all this
research manually, right? And this way it was, it was done
for me very, very quickly. So basically I think it's useful
for anything. And my, my, my next step is is
going to be for the market, the distribution.
That's something I've never, I've never really cracked.
And so like I'm a complete novice at that.
(30:24):
And so I'm excited to start my my chat GPG education on on
distribution. Excellent.
Yeah. It's and it's, it's like you
said, it's a tough, tough egg tocrack because you can't rely on
the LM to do much like marketingcopy generation, because it's
clearly AI slop and it doesn't sound that good.
But there's ways you can leverage like automating e-mail
blasts as as an example. Like there are ways that you can
(30:47):
assist with it, but having the the strategic discussion with a
frontier model will probably help a lot.
One thing I want to pull back towith festival is you mentioned
with loveable. Sometimes it'll hallucinate
whether it's like packages, libraries kind of make things up
or use outdated. One thing I noticed is it
always, the LMS always tend to default to Beautiful Soup and
there's so many better web scrapers.
(31:07):
How do you, from the back end, either manage the prompts or
help with hallucination mitigation and try to keep it so
the code that's generated is using real libraries that are
the correct libraries? Like is there any validation
there? Yeah.
So it's similar to what we were talking about before with doing
the research. So basically when I'm building a
(31:28):
feature, what I'll do is I'll prompt the model to first do
research on like available libraries and tools that can
assist in building this feature.And then, you know, it'll, it'll
give me like some list and then I'll ask it to like, I can do it
myself, I can look at it, but it's taken to just OK, I'll pick
the best one and look up the documentation and then produce a
(31:49):
report on how to use this library for what it is that we
want to do. And this way again, it's
grounded in the, in the actual library's documentation.
So you can't rely on the models parameters to give you, you
know, useful results here. You have to have it grounded in
the actual library. And luckily, you know, models
have access to tools, so they can, you know, do a curl request
(32:09):
for example on the documentation.
And then that way it's grounded in in what library actually
does, as opposed to what it thinks it does.
Nice. And do you have some type of
storage or caching in case multiple users want to leverage
the same feature so you don't have to like curl the same docs
every single time? Yeah, that's a.
Really good. That's a good point.
So that's something I've been thinking about.
(32:30):
That's a tricky 1 though, because now like as soon as you
start doing that, then you know,users might I can imagine users
getting kind of miffed because there there was all sorts of
controversy around you know, I could have Co pilots reproducing
users code, right. So this is kind of a similar
thing where like I'm going to have one user build some feature
and then I'm gonna like cache that feature so that other users
(32:52):
can use it. You know, that first user might,
may not be too happy about that.So I think there's a way to do
this probably involves sort of like a manually curated set of
components. And that's what I was thinking
about doing for it cuz right nowwe, it just uses the e-mail
login that comes with the fast API template.
But I know a lot of people want like Google login, for example,
you know, I've built Google login before on this template.
(33:13):
It's easy to do, but like, why do it over and over?
So the user just wants Google login.
You can just be like, I want Google login.
It should be able to just pull it in without having to build it
up again from scratch, right? But then you have the problem of
invalidation. Like at what point does that API
become invalid and you have to update it.
So it's it's actually not such astraightforward problem, I
think. No, that's that's a very.
Good point. On the note of having the LLM
(33:37):
curl docs generate the report, alot of people would describe it
as a multi agent setup. Would you define it that way or
is it just like a series of APILMAPI calls that you control
the context for? How would you define the the
architecture in terms of how AI is implemented in Fastible?
Yeah. So that's a good question.
I always default when it comes to agents to anthropics
definition. I really like this idea of, you
(33:59):
know, an agents is basically piece of software that basically
decides what it's going to do next.
So it's, it's the model itself that's deciding what, what to do
next. So you basically have like this
wild true loop and then you justask the model, what do you want
to do next? And that's an agent.
So you're basically giving an agency it can control what it's
doing next. But the problem with that is
(34:20):
that the risk compounds, you know, language models
hallucinate, they have all sortsof limitations.
And so if you're just letting itgo off on it's own, it's going
to very quickly go off the rails.
So if you can avoid using agents, you should because it
depends what your goal is. If your goal is just to tinker
with agents, then sure, you can tinker with agents, but your
goal is to make working software, you know, or that
(34:42):
rather, let me back up. Your goal should never be to
make software. Your goal should be to make
something useful. And then what does it take to to
do something useful while you have to build some software and
you don't, you want to build as little software as possible for
it to be useful. You'll want to like go off and
build software for the sake of software, which I think agents
are really good at. So, you know, you tell them to
build software, they're going tobuild that software, a whole lot
of it. It's not necessarily going to be
(35:04):
helpful though. I think if you can get away with
just an API call, you should andand traffic defines us as work
flows. And I think that's a good,
that's a good term. So you basically as an engineer,
you know, what's what the what the proper sort of procedure is
for a certain type of user experience.
So you can encode that into the software.
(35:24):
But I guess this comes back a little bit to the better lesson.
So the better lesson is that like, you know, this, it was
Rich Sutton, I believe we coinedthis term.
And the idea is that, you know, AI researchers want to encode
their knowledge into AI to make the AI better.
And while that does improve the AIA little bit in the short
term, in the long term, it gets beaten out by just throwing more
(35:45):
data and more parameters, more compute at it.
That's sort of the, the, the tricky situation we find
ourselves in that's if you're going to use agents, you might
have a more like you're basically your software is going
to be more flexible in the long run.
And so it is very, a very fine line to, to draw, I think.
And it I, I'm still not, I'm not100% convinced about, you know,
(36:06):
I don't think there is any sort of like hard and fast rule.
I think it comes on a case by case basis.
What's the right approach? So right now everything in
fastible is very much a workflowexcept the Asian chat itself.
So like there's we're using likelarge language models calls
behind the scenes. So for example, create commit
messages, that's not an agent that's doing that because like I
(36:28):
know that I need to create a commit message.
So I'm just going to prompt a while to create a commit.
The only thing that's the the agent is is the is the user chat
when the user's trying to describe the feature that they
want to build. And then that's the agent in the
behind the scenes that's going in, you know, building the
software so that we give it access to some tool calls.
Like, you know, you can read theexisting files, you can write
(36:52):
files, you can restart the environment.
And then we give it like some budget, like you can go for 10
steps and then, you know, do whatever you're going to do in
those ten steps. You're going to read some files,
you're going to write some files.
I don't know, just go ahead. But I think it is important to
you have to cap it because otherwise it can go on for like
forever. And then you're going to have
like this massive bill and you're going to have a whole
(37:12):
bunch of useless software. We, we give in festival, we give
the user an option. Like we can say you can go for
like 10 steps, 1030 steps, 100 steps or some custom number of
steps. Very cool.
One thing since you brought the better lesson that I am
internally like conflicted aboutis creating tools for the LMS
because you get way more success.
Like the the likelihood of a tool called resulting in a
(37:34):
successful output is much higherthan having the LM just try to
generate the output by itself. But by creating tools, we as the
developers are kind of guiding it, directing it, imparting our
knowledge. What for you is the threshold to
develop a tool versus letting the LLM figure out the problem
on its own? Yeah, I, I think.
Probably the. It's a similar rule that's used
(37:55):
for refactoring, I would say. So if you're doing a thing once,
you should just do that thing once and then don't think about
it again. If you're doing it twice, make a
note of it. Make a note the hop.
I did this twice, maybe I shouldthink about not doing this
again. And then when you come around to
doing it the third time, I mentioned refactory.
Now you should probably refactorit into like a reusable
(38:16):
component, maybe not all the time, but I think a similar
thing is with with tools. So if you find that it's
something that you're you're youwant your model to be doing on
some like regular cadence, then you probably want to package
that up into a tool. Similarly, if it's like a very
(38:36):
complex thing that you can breakdown into a series of steps,
like you don't want to use models for everything because
they're expensive and they're not deterministic.
You want to use them just as little as possible, actually,
just where they're needed. And so then you want to sort of
create a tool that's deterministic and give that to
the model so they can call it when it wants to.
Yeah, no. And I fully agree as little LM
(38:58):
as possible in the work flows, fuzzy input to something
structured or allowing the output to be customized, but
through the middle, as much codeas possible just so you know
exactly what's going to happen. Other advice that I'd love to
hear from you is you, you were talking about context
engineering on a past episode, but specifically for building
full stack apps. It feels like there's so much
(39:19):
variability in what people couldbuild, but also because you put
guard rails on it. Do you have any advice for
people who say they're they're prompting to make their own full
stack app? What type of context engineering
should take into account? Like you mentioned the
documentation, but is there anything else that's relevant?
Well, so I mentioned. Like finding like the the target
market, like so I had when I wasdoing this, when I was building
(39:40):
fastball, I had two documents. One was the architecture
document, which describes the functionality and like how the
different pieces should fit together.
And the other one was the what Icall the economics document,
which was like, who is using this and why do they care?
And I think that was really helpful because certain, like I
think it came down to prioritization.
(40:00):
There was all sorts of stuff I wanted to build and like, I
still want to build, but you know, this is me sort of like
doing my, my engineering thing and users don't necessarily care
about these things. So I, I thought it was very
helpful to be ruthlessly like pragmatic and cutting scope.
So I would, I would have like this, this document would
(40:21):
describe all this functionality.And then I'd have this document
describing the users and what dothey care about.
And then I could use that to both of them together to sort of
figure out what should, what should I build next.
So to use that to prioritize thedevelopment as you build your
own. Apps to solve your own work
flows. You're going to want to power
the real data using MCP, and that can be a little bit scary,
but that's why I've been testingout Tool Hive.
(40:42):
Tool Hive makes it simple and secure to use MCP.
It includes a registry of trust MCP servers and lets me
containerize any server with onecommand I can install in the
client in seconds and secret protection and network isolation
are built in. You can try Tool Hive too.
It's free and it's open source and learn more at Tool Hive dot
dev. Now back to the conversation
with Richard. Since Fast World develops assets
that people ideally deploy to the web and actually use, how
(41:04):
much security concern do you have to manage versus how much
is on the responsibility of the user?
Are there things built in to help prevent security risks, or
is it one of those things peopleshould talk to a ChatGPT or
Claude to get a better understanding so they can put
these garters on before it's deployed to that could cause
actual harm? Yeah, that's a really good
question. So there's a couple of places
(41:25):
where we're handling that. One is in usage of secret, like
Castable itself has a bunch of secrets, like for example, your
API key that you're putting in there.
So to mitigate any security riskthere, we're actually not
storing them, we store them in GitHub.
So what's actually happening on the back end is we're creating
private repos for every product that's created.
(41:45):
And then we're just using the GitHub repository to store all
the secrets. And that way, I mean, there's a
big dependence on GitHub, but that way, you know, we're sort
of relying on Microsoft and they're like armies of engineers
to to make sure that's your secrets are safe.
When it comes to the agent itself and what it's building,
This is still a work in progress, but we're we're using
(42:07):
a similar, I guess, an approach that the full stack fast API
template takes, which is just a dot N file.
So the in the Git ignore you have like it's we're basically
explicitly telling gets to ignore this particular file,
this dot end file. And the dot end file contains
all the secrets. And this is part of the the
system prompt that I mentioned earlier so that the model knows
(42:28):
that, hey, if I need to create secrets, they should be stored
here. And you know, that dot end file
gets populated by by the application at runtime.
I'm sorry, the the environment variables get populated via the
dot end file at runtime. Yeah, you're not ever committing
any secrets to get. Now that's not obviously like a
(42:50):
hard and fast, like it's still possible that if you tell, if
you paste a secret into the chatand you explicitly give it
instructions like, hey, put thison the front page.
Well, it's going to do that. So there's no, there's it's hard
to mitigate against that. There, there there is.
Perhaps like I have some ideas around that, like for example,
just filtering everything that goes through some level of
(43:10):
application. You can just do some search and
replace for for for secret names.
So anything that ends with like API key or something as some
sort of fall back. But even that's not foolproof,
right? So I think at the end of the
day, somebody's going to do, somebody really wants to do
something that's insecure, like we're going to let them, we're
not going to prevent them. And there's no there's no way to
do it actually. Yeah, and and similar.
(43:31):
Most leaks, most vulnerability say are it's the human's fault
we're we're the weakest link in the whole security apparatus.
The fact that by default these GitHub repos are private allows
it to be contained at least for someone to audit.
If you have one of those GitHub action bots running to kind of
scan your code, there's another layer of of security people can
add. There's always risk when you
start putting stuff up there andthe best thing we can do is try
(43:52):
to educate people and put some degree of guard rails on.
But if they just vibe code theirown thing anyway, it's going up
on the Internet. So at least this way you have a
bit of control over what we can prevent.
Just a few general thoughts. Back in the day I worked for a
no code app company and now withall of these tools like Fastible
and other prompting to app output, do you see no code as as
(44:14):
reaching it's end or do you still see a place for it?
Yeah, it's interesting. I was talking.
To a friend of mine who is a bigproponent of bubble.
So if bubble is this sort of no code application builder and you
know, a lot of people built likeentire dev shops and in careers
on, on building on bubble. So I, I've got the, I guess that
I think they probably have theirplace.
I think I was asking him why he likes it so much and he was
(44:36):
saying he really likes the idea of just being able to point and
click. So like, I want a widget here
and you can just click here and you get a widget here as opposed
to like you have to describe to the model like, oh, I put it
like on the left of this other. So, but I think there's a, this
is another feature I want to build into Fastible.
It's basically just you can justyou can build the same thing
where you just click on whereveryou want a thing and then prompt
(44:58):
like, oh, I want a thing here. And so that shouldn't be too
hard to build. It's not implemented yet.
So I think that eventually thesethings are going to converge.
I think. I think Bubble already has some
sort of AI tools they're building and, you know, it's
just the first level, right? They're going to continue
expanding on it. And you know, these AI builders
like Fastball, we're going to build in these no code features
like point and click. So I think they're going to
(45:20):
probably converge. Yeah, Yeah, the ability.
To have, whether it's a coordinate system or just a way
to capture where the user clicksand then feed that through, I
think that'll work once it's implemented.
So one thing that tools like Fastible enables is this idea of
disposable software where you get an idea, you spin up
something really fast, you try it out, if it doesn't work,
whatever, you can try again, throw it away.
(45:41):
You lost, you know, a couple dollars, a little bit of time.
But ultimately the idea that software doesn't have to be as
have the same longevity as it used to because there's a lot
less sunken cost. What are your thoughts on that
as a general trend? Do you think it's a good thing,
a bad thing? And where?
Where are we going with disposable software?
Yeah. Andrew Ng gave a talk on this
recently, the Y Commodator Startup school that they liked.
(46:05):
People were saying what he was saying, that's people are saying
that's now the time to stop training people to write
software because the value of software has has plummeted.
And he said it's true that the value of code has plummeted
because now you can generate code, you know, instantaneously
for like fractions of a cent, but it doesn't mean the value of
software has plummeted. And he, he actually thinks that
(46:26):
it's the opposite. He thinks that now as software
becomes more and more accessibleto people, the value of software
is going to increase because people are going to make more
software to basically solve likeeven more specialized problems.
So I mean, it's impossible to tell the future.
And obviously I'm biased becauselike I like building software
(46:48):
and I don't want to go away. So but I sorry, I like what
Andrew and entering is biased too, because you can create
course 0. Course 0 is all about learning
how to code, right. So yeah, it's really, it's
really hard to predict the future, but at least for the for
now, until you know, AGI is, is here, which I don't think it
necessarily is yet. I don't think there's, I don't
think that the value of softwareis going away.
(47:09):
I think, I think we're, I think we're safe for a little while.
I agree and I think. There's there's a couple other
principles that I think we'll tie into this too.
I'm a big proponent of Obsidian,the whole file over app
principle because if you can control your data and keep your
information on your computer andjust develop different types of
software to interface with that data, it doesn't matter.
Like I'll use Obsidian for my note taking, but I had someone
who didn't like the way the tasks were able to be
(47:32):
prioritized and want some a little more automated.
Instead of making a plug in, they just spun up an entire app
where it read the same vault, took in the markdown files, look
for the the dash in the square brackets that designate a task
and then just brought them all in.
And then a nice draggable interface that you could add
tags to to prioritize just a a anew wrapper around the data.
So I think people just need to get into the habit of start
(47:53):
finding ways to make your data portable because the way that
you interface with it is going to be, you know, whatever you
want it to be soon. Interesting.
Yeah, I, I, I could see that being a conflict with the with
like a bunch of big companies that, you know, their entire
business model is around like having your data and giving you
access to it. So that might be, so there might
be some friction there. Yeah, do do you?
(48:13):
Think SAS is going to be affected by products like
festival so I I heard. Already that's it.
It already is being affected because yeah, it is so, well, I,
I, I've heard a couple of different, different claims
about this. So 1 is that it's already being
affected because it's becoming so, so simple to spit up new
SAS, new software products. And so like, there's like an
(48:37):
people are claiming that there will be an inundation of people
would be sort of overly saturated with different
products. But then there was this report
that was released recently with suggested the opposite.
And if somebody had done some empirical analysis showing, I
can't remember which data sources, but they basically
suggested that, you know, despite the fact that the value
(48:57):
or the, the, the energy requiredto create software has decreased
so much, the actual amount of software being produced is not
changing that much. It's still sort of on the same
trend as it was before LOMS cameon the scene.
I think it's still too early to tell.
Yeah. It's.
People can't predict the future and now it's it's harder than
ever. Richard, this was a blast.
(49:17):
I'm I'm pumped on fastball. I hope more people try it out
Before that you go. Is there anything else you want
the audience to know? Just check it out.
It's free to use other than the API key.
So go to fastball dot dev and you need to GitHub account.
For now I'm going to be adding in Google login so you won't
need that and just give it a shot.
Thank you for listening to this.Conversation with Richard A
bridge. I'm so glad he came back.
(49:38):
I always have a blast talking tohim and he always provides some
insight that I just didn't really consider.
If you're looking to build your own app, I suggest you check out
festival. It's free with your API key so
you're only paying for the usage.
And this way you can start getting into the habit of
building disposable software, software that's made for your
specific use case at the specific point in time.
Maybe you'll change in the future, maybe you'll just throw
(49:59):
it away, but the act of building, exploring and seeing
what's possible is very rewarding in itself, let alone
the productivity gains from getting a tool that's hyper
customized to your use case rather than generic off the
shelf stuff. So I want to give a quick shout
out to Tool Hive for supporting the show so I'm able to have
conversations like this and please let me know what else
you'd like to see, what has inspired you?
What are you building these days?
(50:20):
And if you could like and subscribe, it would really mean
a lot. So thank you and I'll see you
next week.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Paper Ghosts: The Texas Teen Murders
Paper Ghosts: The Texas Teen Murders takes you back to 1983, when two teenagers were found murdered, execution-style, on a quiet Texas hill. What followed was decades of rumors, false leads, and a case that law enforcement could never seem to close. Now, veteran investigative journalist M. William Phelps reopens the file — uncovering new witnesses, hidden evidence, and a shocking web of deaths that may all be connected. Over nine gripping episodes, Paper Ghosts: The Texas Teen Murders unravels a story 42 years in the making… and asks the question: who’s really been hiding the truth?
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com