Speaker 1Well, friends, it is officially time. Officially time to stop acting like coding with AI is something that is just for software engineers, because it is not. Now, obviously, throughout the course of the last year and a half, as tools like Lovable and Replit and then CloudCode and Codex came online, more and more knowledge workers outside of software engineering started to figure out how to use the power of writing code and building software to solve their own problems. And this is not just about all of a sudden those non-software engineers trying to act like software engineers. It's about finding new ways to do their jobs with the aid of software that they can build themselves. And yet for so many people, this still feels so inaccessible and out of range. But it doesn't have to be. The AI Daily Brief is a daily podcast and video about the most important news and discussions in AI. All right, friends, quick announcements before we dive in. First of all, thank you to today's sponsors, KPMG, Blitzy, Robots and Pencils, and HyperAgent. To get an ad-free version of the show, go to patreon.com.ai daily brief, or you can subscribe on Apple Podcasts. To learn more about sponsoring the show, send us a note at sponsors at ai daily brief.ai. Quick requisite shill for our upcoming super intelligent executive agent leadership program. This is the better supported led by Nufar Gaspar version of the agent OS and clock camp style program. that we've had in the past, focused on helping you not only learn how to build agents for work, but how to build these systems around them that allow them to intersect with your work in a safe, secure way. The next cohort starts just after Labor Day and is registering now. I was recently having a conversation with one of my daughter's friend's parents. And this is a person who has been using AI extensively for a couple of years. They have multiple subscriptions to multiple different services at high expensive levels and has moved a lot of their work into an AI assistant. So they've been using AI for a long time now. And they've been using AI for a long time now. And yet for them, even considering anything surrounding AI coding still seemed totally foreign. They were in short living that co-work life, never venturing over into the quad code side of the world. And I think losing quite a bit for it. With absolutely no value judgments placed on where people are, I do think not having AI coding tools in your toolkit as a non-software engineer knowledge worker does at this point leave you behind. Earlier this week, we did that episode about open source software. And we did that episode about open source software. And we did that episode about open source software. And we did that episode about open source software. And we did that episode AI's recent enterprise research that found that around the end of April, beginning of May, the percentage of tokens that were being consumed via API agentically had flipped the amount of tokens being used non-agentically through ChatGPT, and that number has done nothing but rise. We saw that the firms who were in the top 10% of enterprise users, as opposed to the average firms, were using about 8.3 times as much AI, and the use cases that they were deploying were a lot more sophisticated, getting much more into systems and overall disruption. And putting a fine point on the idea that this is not just a thing for software engineers alone, while starting from the February baseline, engineering-related users of Codex in the enterprise had grown 5x, basically every other function had grown significantly more. Finance and accounting was using Codex 20 times more than it had been in February, sales and accounting was using it 41 times as much, and legal was using it 108 times as much as it had been back in February. So what the heck are all these people doing with AI coding? One thing that they are not doing, in most cases, is all of a sudden trying to become the software engineers for their organization. This, I think, was a misconception of the early days of vibe coding that has still a bit stubbornly persisted with us, despite it being for a long time not really where people are. The real argument for deploying AI coding as part of your AI toolkit as a knowledge worker is not that you're going to become the software engineer, but because we're seeing that the people who are building are compounding their gains and their advantages relative to other AI users. That 8.3x gap that we saw between typical firms and frontier firms was up from a 2.6x gap back in January. But there's a lot more reasons that you should consider coding as well. You're already doing a lot of the activity that would be extremely well suited to being supported by software. And a lot of the barriers that you would have always assumed have kept you back are pretty much just now gone. And the reason to start now is that until you do, it's extremely hard to see which of your problems in work actually have software-shaped solutions. Although we're going to try to do a lot of the work that we're doing, we're going to try to do a lot of the work that we're going to try to do a bunch of that today. Now, when I run across folks like this friend that I was talking about before from my town, I hear some pretty common sets of reasons why they haven't fully dived in yet. A lot of them come down to self-perception, the idea that they're quote unquote, not a technical person, whatever that means. But if you're someone who's been using AI for a couple of years now and is splitting your time across multiple subscriptions, you're certainly technical enough to dive into this other field. Some folks have a fear of breaking something. They're worried that they'll make a mistake or they'll authorize AI to do something. That leads to some irredeemable error. And it's not that there's no rationale here, but there are, of course, ways to address those types of concerns. And certainly fear shouldn't be holding you back. For a lot of folks, it's still perceived barriers to entry. If they tried to use a terminal interface first, they might've taken one look at it and turned right around. And relatedly, maybe some of the on-ramps were wrong. If they tried to find some tutorial online, it might've been having them try to build something that wasn't relevant for their work. And I think that's the big one, that they're just not sure from where they're sitting, what building and using AI is going to do for them. So let's try to answer that question specifically. And we're going to start with three build patterns. You can think about a build pattern as the software that you're writing's relationship to work that already exists. I think it falls into three categories. Is it reproducing an old output, changing the way an old job gets done, or making a previously impossible job possible? So pattern one, let's call automation. Same job, same output. In this case, the output state is the same, but you stop making it by hand. This could be renaming files, syncing lists, filling templates, reworking exports, those types of things. You know that the work falls into this build pattern if someone who is receiving the output of that work wouldn't notice that anything had changed. If the software that you built to do it broke, you would simply go back to doing it by hand, doing the same steps manually. For some people, this is a good place to start because they already know what correct looks like. And a lot of this is the type of rote work that is time and energy draining relative to the things that you're working on. So this is a good place to actually want to be doing at work. The second pattern we'll call upgrade. So same job, but new output. An example of this would be a report becoming a live dashboard, a deck becoming a web application, a status email becoming a self-serve page. Whereas with automation, the receiver of that work wouldn't be able to tell the difference, the person on the other end of this one gets something that is distinctly different and presumably a lot better. Now, if your software broke for doing this, you could fall back to the old PDF spreadsheet or meeting but it would probably be pretty unsatisfying to do so. The payoff for upgrading work is not just saving time, but that one of these types of recurring tasks becomes an actual asset and a way to outperform and stand out. Pattern three is the most exciting, but the hardest to wrap our heads around until we're actually in it. And that is invention. In other words, new job, new output. This build pattern involves jobs that didn't exist before because doing it the old manual way was never practical or even possible. Interviewing, every person, monitoring hundreds of sources, testing thousands of different combinations of copy. All of these would have been completely outside the realm of the possible in the pre-software world. But now all of a sudden, thanks to building, something that wasn't possible before becomes unlocked. Now, in addition to it sometimes being hard to spot from the outside, what is going to be a good use of this type of invention, there is also a risk that because there is nothing proven to copy, you might sometimes find yourself building a capability that neither you nor anyone else ultimately uses. Certainly, I have built far more things than are actually part of my day-to-day routines, and that's just part of the cost of doing business. So, okay, we've got three build patterns now. Automate, upgrade, invent. Next up, let's talk about delivery classes. This is about the shape of the software that gets produced. It is about who is using it and for what. Understanding this is going to determine a lot about the type of software that you need to build. How much security, documentation, UI/UF, text consideration, support, whatever your building is actually going to need. And it turns out there is a significant range here. So let's talk about a handful of non-exhaustive categories. On one end of the spectrum, you have prototypes. This is a temporary build whose job is to answer a question or test some sort of interaction or idea or help move a decision to the next step. What you produce can actually be pretty disposable. You might be prototyping something for your own work or team or using prototypes as a new way to explain features you'd like to see. You might be doing this for your own work. You might be doing this for your own team. You might be doing this for your own team. These are builds that you're going to optimize for speed, clarity, representative examples, not security, depth, usability, anything like that. Moving up the ladder of durability, we have next what a lot of people are calling personal software. This is a tool that you've built for yourself or perhaps a small team around you that handles some particular need in an ongoing and reliable way. Whereas a prototype can just show the idea, personal software still needs to be good enough that it actually does the thing that you or your team needed to do, but you can still compromise on things like perfect UX, permissions considerations, visual polish, edge cases. Basically, because it is for you, anywhere a compromise feels worth it to you, you can make that compromise. This blurs a bit into the next category, one more up the ladder of durability, which we might call production grade software. This is software that's going to be used by other people that aren't you or your small team. It's where a failure could cost trust, time, money, access, et cetera. It needs to be good enough that users who, again, aren't you, can actually use it under realistic load conditions. There have to be pathways to solve problems that inevitably come up. It's got to have enough security, access control, privacy, et cetera, to meet the needs of whoever the users are. But you're still not talking about mass consumption. It is still extremely discreet for some specific purpose, for some specific group of people. Now, it's important to note that even though personal software and production software, as I'm defining them here, are more durable than prototypes, they still can be disposable. It's okay if your personal or production software is only useful for some specific goal for some specific period of time, and then you cease to use it. This is one of the things that's so different about building software now, is that we wouldn't have taken the time to build disposable software before. We would have solved it in other ways, because the cost of building that software wouldn't be justified by the amount of time or the specific use case that we were building it for. That equation changes, and it opens up a lot of interesting opportunities. The last category, all the way up the ladder of durability and significance, is an actual product that's meant to not just serve some specific group of people, but to serve a market overall. This is where you really are acting like a software engineer of yore and releasing something where people you don't even know are going to be using it in some way. And in that, it has all of the same considerations and burdens that building software for general consumption always had. Now, let me use a demonstrative example from AIDB. To give you a sense of this, one of the interesting things about the AI Daily Brief is that one of the things that I hear most that people enjoy about it is its information density. People really like the ratio of the amount of value they get per minute. However, for someone new, that information density can create a really big barrier to entry. So for a while, I had the idea of breaking every addition into smaller chunks. Since the most common growth pattern that I've seen is colleagues sharing the show with each other, I wanted to organize those chunks around these specific key quotes. Or themes, or ideas, or statistics that comprised any show so that a listener would be able to not just share the entire show, but the very specific part of the show that they thought would matter to their colleague. This is what became the current website that we have at AIDailyBrief.ai. But that process started with a prototype. Before I actually built the entire system for this, I did a bunch of testing to see, was the AI that I was using good enough to actually automate the extraction of these themes? And in short, it wasn't until we got Fable and GPT 5.6. But once I had it, I was able to do it. And once I had prototyped to figure out that indeed it was good enough, I could move it to the next category of personal software, where I actually built the extraction pipeline that could take a transcript and turn it into a new edition on the website. There were certain things that were non-compromisable here and certain things that I could compromise on. And then once I had that working for me, I needed to make it accessible for a small number of people on my team, which I still consider that personal software category. But the next problem that I had is that I just haven't invested enough in social. And while I don't believe that just automating a content pipeline is a sufficient social strategy, it is certainly the basis for any social strategy. The fact that there is so much content that I'm producing that now gets segmented in easily shareable ways, but wasn't being shared was just dumb. And so the next thing I built was another pipeline automation that would take the extractions for the website and turn them into social content for Twitter and LinkedIn, and then automatically post them. Now, in a lot of ways, this is still personal software because I wasn't actually having it serve others, but it starts to get blurry. And this is why it's so important because it interacts with real-world systems. Maybe a better example of production software for my world is the one that I'm actually not going to show you an example of, but is a new reporting system that I'm building for sponsors instead of emails or spreadsheets that have lists of statistics, it's going to be a sign on experience that sponsors can just click around in, get insights about the performance of different episodes that their ads were featured on. And that is one where it is absolutely in that category of production software that is not just for me and my small team, but for serving others, but where it's a very discreet set of others that I actually know. Now, of course, there could be a next step available. For example, if I wanted to turn that sponsor reporting software into a product that people could just buy, there would be a massive leap between the production software that I was sharing with my sponsors and the products which I was selling to others. So that's the difference between those two. A new study from KPMG and the University of Texas at Austin found that when people work with AI, similar skills don't guarantee similar outcomes. Researchers say that this is just a matter of time. Researchers studied more than 500 early career professionals and found that the best performers consistently amplified the value of AI by guiding, evaluating, and refining its outputs. These top performers, called AI amplifiers, weren't defined by what they knew alone, but by how they worked with AI. Learn more about what separates AI amplifiers from everyone else at kpmg.com slash US slash AI amplifiers. Every AI coding tool on the market does the same thing first. It starts writing code. Blitzy does the opposite. Before writing a single line, Blitzy spends days reverse engineering your entire code base. Thousands of agents ingest millions of lines, mapping every dependency, every undocumented constraint, every architectural decision made over the last decade. The result is a dynamic knowledge graph that understands your software the way a principal engineer would after 30 years in the building. Other tools guess at context with grep searches and markdown files. Blitzy never guesses. It builds true understanding first, then delivers over 80% of entire software epics autonomously. Validated. End-to-end tested. Production-grade pull requests. That's why Fortune 500 engineering teams trust Blitzy with the code bases that matter most. See for yourself at Blitzy.com. That's B-L-I-T-Z-Y dot com. I cover the capability gap between AI potential and AI reality every day on this show. Most companies are still figuring out how to start. Robots and Pencils is already launching and scaling. Agendic and generative AI in production at large enterprises in weeks. AWS Advanced Tier pattern partner more than doubled in a year. And they're hiring. 50 open roles. If you're someone who knows this moment is different, who wants to be inside it, not watching it, this is worth a look. At Robots and Pencils, the best ideas win, and the team is purposefully kept super high quality. This is the kind of place you look back on as the best decision you ever made. Take a look at robotsandpencils.com slash careers. This episode of the AI Daily Brief is brought to you by HyperAgent, where you run fleets of agents your team can manage together. New users get $1,000 in inference. Forget local agents and chat workflows waiting on your laptop to be prompted. HyperAgent deploys always-on agents in the cloud, doing real work across the tools your team already uses. Marketing's agent turns competitor moves into landing pages. Sales' agent enriches leads, drafts emails, and updates the CRM. Ops' agent chases the paperwork and tracks the budget. Every agent has access to shared context and follows your rules about scope and approvals. It's time you add agents that feel like teammates. Hire yours at HyperAgent, built by the team at Airtable. Claim your $1,000 in inference at HyperAgent. com slash AI Daily Brief. Okay, so now we've talked about the three build patterns and these four different delivery classes. But what about for you? Which parts of your work could be software? My big asterisk on this part of the episode is that no one from outside is going to be able to tell you exactly which of your work would be best suited to becoming software. But these are some common patterns that I've seen and that I've experienced. That could maybe get the juices flowing. I've organized it into six categories. Presentation work, content work, data work, document work, inbox work, and admin work. So presentation work. Pretty much all of us in some ways have to show things to people. And this is one of the best areas for that upgrade build pattern. Where the underlying job stays the same, but there is a totally new type of output. So think about these questions. Do you have some sort of presentation that would benefit from interactivity? Instead of doing a PDF, build an HTML page. In fact, I have a whole episode in the archive about why you should be using HTML instead of other content forms. Do you explain the same things to different people? If you've walked through the same set of information a hundred different times, that might be a good fit for an interactive explainer or a bot that answers the questions. Do you calculate the same things for different people? Again, that could become a self-managed calculator. Do you help people compare options, plans, vendors, scenarios, packages? That could become a comparison tool. Do you automate? If you give new clients or new hires the same tour every time, that could become a walkthrough, a checklist, or even a quiz. Do you tell people where things stand? Projects, orders, applications, and the any update emails that come along with them? That is waiting for an automated status page so they can just look at it and stop asking. Do you keep looking up the same reference material, rates, rules, contacts, specs? Again, that sounds to me like great fodder for a lookup tool. Next category is content work. Another very common category. One of the things that AI is the best at is turning content into other content. If you turn transcripts into summaries, or long things into short things, or one thing into five posts, that is not only well-suited for AI, and probably you are already using it for such, you should be building an automated pipeline for doing it. Think about the extraction pipeline that I built for the website. Could I, every day, take the day's transcript, plop it into ChatGPT or Claude, and ask it to extract all the key headlines and give me a list that I could then go, manually type it into the web page? Of course I could, and that would still be a lot faster than me manually extracting those parts. But there's no reason that that entire process can't be automated end to end. And that's where building software to do so came in for me. Now the next category is data work. And this is one of the most common starting points I see for non-technical knowledge workers who get into building software to help them. And this makes sense, given how many data analysts already had some experience writing Python to help with their work, it's not surprising that this is an entry point for a lot of others as well. So if you are doing any sort of recurring data analysis, pulling the numbers, making the same charts, answering how we're doing. building the application that has both the dashboard that answers it, as well as interactive tools to allow people to ask different questions of it, is an incredibly good use of building software. That basically describes exactly the sponsor portal that I was just discussing for AIDB. Now, another part of data work that kind of goes back to that content piece is data translation, where you export from one system, rework it by hand into a format that someone else needs, like a CRM export that becomes a sales sheet. If step one was automating parts of that process, step two is to build the software pipeline that just does it all end to end. And that pattern, again, shows up a lot in the next category, document work, where a lot of the starting point for knowledge workers building instead of just using AI is that if they had already figured out that on a thing they do over and over, AI can speed up doing that thing, there might be a further step to further automate it if you build software to do that automation. So filling in the same templates over and over, doing the same thing to a lot of different files like renaming, converting, or resizing, reading a lot of documents to find specific things, AI could help you manually, i.e. you put those things into AI each individual time, or it could be helping you in an automated ongoing way if you build the software to do so. Inbox work, do you collect things from people like applications, sign up requests, submissions? Now, in a lot of cases, there's probably existing software that solves that for you. But it's not at all inconceivable that there's some specific discrete need that you have that doesn't perfectly fit with one of those vendors now. And that would be a reason to consider building some intake system. And this, by the way, gets to another great point that I think is important. Just because you can build something doesn't mean that you always need to. One of the things that you will almost definitely find once you start your building and AI coding journey is that you'll be squinting at something that you pay for and think to yourself, I could just build that. Why am I paying for it? But there will often be good reasons not to. A team whose whole job and mission is to respond to the needs of their customers around a particular product has a lot more raw capacity to do software well than you do as the 68th thing on your to-do list. So if you're a software developer, you're going to have to do a lot more on your to-do list. Almost always, I'm checking to see if there's anything that exists out there that could be doing the thing for me before I'm committing to entirely building it myself. An example that came up recently when I was building the social pipeline is we could have done the automated posting directly via the X and LinkedIn APIs, but we found a service typefully that just had that capability natively and could interact really well with the pipeline that we had built. That saved me a huge amount of anguish and agony and tokens. And so even in the context of my personal software, that personal software was able to interact with very much non-personal software that someone else had built to be a complete solution. So let's close by trying to put this all together with six theoretical projects. And once again, these are humbly submitted just as thought starters for you, not as the paragon of the best type of build projects for knowledge workers or anything like that. Two projects each from each of the three different build pattern categories. First up is automation, with the first project being something I'll call the Friday export. This is turning the project into a Friday export. So I'm going to start with the Friday export. So this is turning that spreadsheet ritual that you can do with your eyes closed into a small inspectable transformation pipeline. So you've got a CSV or a spreadsheet from one system that you rename, filter, split, join, calculate, reorder, restyle, analyze. And what you're going to build is a local page where you drop the raw export, preview the transformation, see anything that needs attention, and download the finished file in the exact old format. It's the same trusted deliverable, but you don't have to give up your Friday afternoon anymore. A similar type of automation is the invoice pile. You've got invoices, receipts, statements arriving as PDFs or photos, plus a tracker where vendor, date, amount, category, and reference number are typed by hand. What you're going to build is a watched folder or drop zone that reads each document, normalizes its field, flags low confidence values, catches duplicates, and produces that same old key spreadsheet, but where you're just doing the review rather than the manual input. You can see here that the build pattern of automation really is about saving you time and agony and leaving you space to do other things. And that building software to do so is just another tool in your toolkit to win back your time. You invest a little upfront to build the software, and you get back a big time ROI on the other side. Now, the next projects we'll talk about fit into the build pattern of upgrade. And the first one is an idea that's come across a number of different times in this episode, which we'll call the live report. Anytime you owe someone some set of numbers or analysis at some specific regular interval, you could consider no longer sending them snapshots, but instead giving them one place, and then sending them snapshots. And that's what we're going to do. to see a continuously or regularly updated stream of data with the ability to ask questions of and interrogate that information without you having to be the interlocutor. So my sponsors are an example of this, but maybe you have a weekly or monthly numbers email, a deck, a PDF for a client, a boss, a board, a fund, or a sponsor, followed by requests for different date ranges, breakdowns. What you're going to build is a focused page that refreshes from the source of the data. It's going to show the user when the data was last updated. It's going to answer the most important questions automatically. It's going to provide some amount of automated analysis. And if you really want to push yourself, maybe you even allow them to use AI to interact with it in some way and try to get answers to their questions without having to go to you first. This is an example, not only of an upgrade where the job is the same, but the output is better. It's also an example of the production software delivery class, where you are building something that is going to be used by someone else, but a very specific and knowable someone else where you can still figure out based on that audience, what the right trade-offs can be. The second upgrade project we'll call the what-if slider, I'm sure some of you have some sort of projection, staffing plan, quote, scenario model, and deck that inevitably comes to a question of, well, what if we changed price, volume, timing, headcount? Now, maybe you can just use a spreadsheet for this. Again, we're not trying to build software just for the sake of building software. And Excel and Google Sheets are really good at allowing you to change the numbers and see what comes out. But Excel has its limits. And there might be a lot of additional variables that don't translate cleanly into numbers that a personal software style what-if slider can do. So, if you're going to build a software that's going to be used by someone else, i.e. a page that exposes the variables and allows people to interact and change them to see what outputs would change on the other end, could be a better fit for that sort of what-if scenario planning. Finally, two theoretical projects on the invention side. The first we'll call the watcher, and it's basically your personal agentic researcher. Let's imagine that you have some type of information or data that changes over time that knowing the changes about are integral to your work in some way. That could be competitor pricing, job posts, grant payments, pages, mentions, inventory, regulator guidance that changes unpredictably. Trying to keep track of all of that is something that can be done by hand, but especially if it's at all unpredictable when those things are going to change, that can take a lot of time and energy. You could build some checker that watches those data sources, cleans up for irrelevant noise, keeps track of history and changes, and automatically sends updates when it matters. Now, this is obviously a monitoring job that didn't exist before, but which can now help you do your work in a fundamentally better way. So, if you're going to build a watcher that watches those data sources, cleans up for a different way. Now, regular listeners might be thinking to themselves, gosh, that sounds kind of a lot like the type of thing you can do with personal agent software like OpenClaw or more recently Grokbot, and you would be right in that. One of the things that I think we will have to watch in the coming months and years is how many of what we might call build projects right now, where you would build custom software, get solved by agents with the right combination of pre-programming and customizability. As fun as building stuff is, we should obviously be cheering when simpler approaches allow us to solve that problem without spending all that effort. Another invention project, which honestly might end up the domain of agents, we'll call the pattern reader. Imagine that you have some big pile of information that nobody has the time to read. Support tickets, sales transcripts, reviews, applications, survey answers, interview notes, incident reports. You can build a local analysis tool that cleans it all, groups recurring themes, compares segments or time periods, links claims back to representative source passages, and provide some ongoing and updated analysis. Because that pattern reader is a regularly updating itself, you can intersect with it at any given point without having to do a bunch of work to get it ready to answer the questions that you have. Now, it's really important to note that while it's fairly easy for me to give you some examples of automation or upgrade style build patterns, when it comes to invention, there's pretty much no way to know what stuff you're going to invent until you start messing around. And I think this is ultimately the point in the recommendation. There is no reason anymore for you not to dive in and start experimenting with how AI coding could support your work. If you want to start with the most helpful training wheels, you can do Lovable or Replit. If you want to stay in the ecosystems that you're already operating in, try Codex or Cloud Code. In either case, take whatever seemed most vaguely interesting from all of what I just said, and just go see what it would take to build that thing. Maybe it amounts to nothing. Maybe you abandon it right away. Maybe after time and experimentation, you decide that there's actually nothing that existing software or agents can't do for you. But my strong belief is that building software, not for the sake of releasing software for other people to use, but for the sake of doing your own work better, is now just a foundational capacity that knowledge workers need to have. Hopefully, it feels less intimidating to start after this episode, but for now, that is going to do it for today's AI Daily Brief. Appreciate you listening or watching, as always, and until next time, peace. you
PodcastTranscript AI