The Offset Podcast - The Offset Podcast EP051: Vibe Coding For Post Production

Episode Date: March 16, 2026

In this installment of The Offset Podcast we're discussing vibe coding and its role in post production workflows.  You've likely heard this term before, but if not, vibe coding refers to the concept of using natural language via an LLM to program tools like websites, apps, plugins etc. The promise of vibe coding is that anyone - given good enough instructions - can program or code complex tools without specialized knowledge.  However, as you'll hear the promise and reality aren't always aligned.  Some of the specifics we'll explore in this episode include:Understanding APIs, SDKs and other high-level background information on programing'Analog' vs 'vibe' codingThe intersection of traditional programing and vibe codingVibe coding success is based on quality input and quality testingA few vibe coding examplesThe role of vibe coding platformsAnd moreCheck out www.offsetpodcast.com for our entire library of episodes. You can also follow us on Instagram & Facebook - just search for The Offset Podcast.  Be sure to like and subscribe to the podcast wherever you found it and be sure to check out our growing library of episodes.  If you like the podcast it'd mean the world to us if you'd consider supporting the show by buying us a cup of virtual coffee -https://buymeacoffee.com/theoffsetpodcastSee you in about two weeks for a new episode.

Hey, everybody, welcome back to another episode of The Offset Podcast. And today we're talking about that hip-cool phrase, vibe coding, and how it pertains to post-production workflows. Stay tuned. Support for this episode comes from Flanders Scientific and the XMP 270 and XMP 310, the accessible, lightweight, and versatile monitors helping to bring HDR monitoring on set while also being very well suited to post-production work. Learn more at Flanderscientific. Hey, everybody. Welcome back into another episode of The Offset Podcast. I am one of your host, Robbie Carmen, and with me as always is Joey Dana. Hey, Joey, how are you, man? Hey, everyone.

So, Joey, I just have to apologize up front. I'm probably going to use the word coding a lot here when it drives you absolutely insane and we should be using programming. So I apologize to you in our audience. I'm just going with the phrase de jour and that is vibe coding. Yeah, yeah. I hate the term coding because it's not a real word. You're not coding anything. You're not encoding a message. You're not encoding. It's wrong. It's called programming. And I don't even know what a vibe is. So I don't know what a vibe coding is supposed to be. So half of you this is going to be me screaming at the clouds saying, I don't like these newfangled words. But newfangled words or not, there are still powerful workflow technology.

technologies available to us now that are new and we should talk about. Yeah, totally. And our dear viewers will understand your get off my lawn attitude. I mean, after all, this is our 51st episode. So if they haven't gotten used to, you know, Joey getting on a soapbox about something, especially highly technical computer-based concepts, then, you know, you should go back and watch some previous shows because there's still on my lawn at this point. Well, yeah, there's some good rants to be had. But anyway, before we dive in the same unusual housekeeping as always, you can You can find us on social media just by heading over to Instagram or Facebook searching for the Offset Podcast.

You can find our complete library of episodes, including show notes, and in some cases, some additional downloads and such, over at the Offsetpodcast.com, where we have our whole library. And you can also find us, of course, on any major streaming platform like Spotify, Apple Podcasts, and the video version of the show is obviously available on YouTube as well, where we have a lot of you chiming in there. Please drop us a comment, like, subscribe, wherever you find the show, tell your colleagues and friends. every bit goes a long way. So Joey, let's start, I sort of want to talk about a little bit of the wayback machine

and a personal sort of anecdote about this. And we're not going to have to go that far back in the wayback machine. A couple years ago, probably five, six, seven years ago, I started realizing because I was seeing, you know, at the time I was doing a lot of international travel, a lot of speaking at events, you know, conferences and things of that nature. And I kept encountering this type of, of person that was involved in post-production somehow, right? They were an editor, they

may be an engineer here and there, they were a colorist, they were a DP, and you know, you'd be talking to them and they'd randomly just drop, oh, this app that I made, oh, this, this, this tool that I made, right? And yeah, sure, like the really sort of involved people in our industry have always done this level of tinkering, right? Something's not available, I'm gonna make it myself. And it used to be they did that with, you know, metal and plastic bits and a whole bunch of solder and, you know, like physically putting something together. And what I realized about five or six, seven years ago is that that shifted largely to application development. It's shifted largely to programming. And so, you know, I was, that's when I first

started hearing it. But at the time, this was people who had invested a lot of time in learning Python, JavaScript, you know, C or C++ or like any other range of languages and tool sets out there. And I started, I tried to get into that stuff, man. And, you know, my brain just, it's a limitation. Let's put it that way. Like, it's, I get the, I get the idea of order and syntax and whatever and calls and responses. And I get it on some level, but I just wasn't made, you know, there's, there's some people,

and I'm sure you've encountered these people who can look at programming language, or I'm going to use the word code here, or, you know, look at a whole thing laid out in front of them and go, oh yeah, I totally know what's going on. It's like the reading, you know, it always reminds me of like the, you know, the first matrix, right? When all the numbers are streaming down the screen and somebody's like, oh, see that guy running right there? And you're like, what? Am I crazy to think that that's like kind of old school programming takes a little bit of a different level, different mindset to kind of get your head around?

Yeah. And it's an important concept that I think a lot of people don't really know how to label, but the, because I've got a pretty decent programming background. I'm not the greatest programmer in the world, but I've always made my own tools, made my own kind of workflow enhancer, stuff like that, never made them to the level where they were good enough to really share among the world and support, because support is a whole other thing that you need to get into if you start selling software. But I have since early, early days, you know, people have always, there's always the fun story that I bring up is that I invented Dropbox three years before Dropbox incorporated existed, which is true. You can go to the wayback machine, internet archive.org,

and I can prove that to you. But even 20 years ago, I was writing some web-based applications to optimize the workflows for the post house I was working with at the time. And what you're really talking about is a concept called abstraction. And it's something that's used in programming,

but it's also something that I like to think about in kind of all things. What abstraction is, is you take specific things and you generalize them. With programming, that happens with programming languages. That happens with device drivers. That happens with what's called abstraction layers where, okay, for example, every single software that uses a Blackmagic hardware interface doesn't talk directly to the Blackmagic hardware.

They talk in a standard language. They basically say, hey, I know how to send video to a device. And then Blackmagic writes the software that actually handles, well, okay, this is a DeckLink 8K. This is a DeckLink 4K. This is a mini monitor. That's why After Effects, DaVinci Resolve, Premiere, Media Composer. None of them need to know the specifics of your Blackmagic output hardware. They just know we're using the Black Magic API that then abstracts all the technical nonsense that you don't want to have to do and then handles it.

So before we move on, Joey, can you just real quick? Because I think people have heard these terms before, API, SDK, SDK. Like, what are those terms mean? Because that's the sort of abstraction layer you're talking about and sort of the nice package that companies put their abstraction layer in. What are those terms? Because you hear those terms all the time. Go get the API key or go get, you know, or download the SDK. Like, what does that mean?

Yeah, that's actually a really, really good point because, you know, people might not know what these acronyms do. SDKs and APIs specifically. SDK is a software development kit. and an API is an application programming interface. People will sometimes interchange these things, but they're actually pretty different. An SDK is a set of libraries and base level source code and examples and ways of doing things that lets you use someone else's software. For example, Red provides an SDK that they give to Adobe, they give to Blackmagic, they give to Avid.

They, avid, Adobe, whatever, will write calls to the libraries in their software that says, hey, decode this R3D file and then give me back the image. Okay. So you're using Red's software intellectual property, but you're actually inserting it into your software. For the kind of tools we're going to be talking about, we're probably not going to be doing stuff like that. What we're really going to focus on in a lot of cases is in API, where you're using, you're using. using software to give commands to something else and get data back. Right. We're not actually, for example, if we were talking to frame I.O. to manage some assets or we were talking to DaVinci Resolve also to manage some assets, right?

We are not writing DaVinci Resolve into our program. We're not writing Frame I.O. into our program. We are just communicating with those outside entities. That's what the API does. And I think that's a really important, really early distinction to make as you go down this path, is that you inevitably, and as it will explain later, you'll get the potential for frustration exists because you're like, I want to do something, but it's not working or I can't do it. And that's not always bad logic.

That's not always bad thinking. That's not always bad programming. That can be as simple as this tool that you're trying to integrate with and get something to do doesn't expose these bits, these API calls or, you know, hooks to be able to hook into to do that very thing. And in fact, if you think about it, it sort of makes sense, right? If you, if you're a big company and you've spent millions or billions of dollars developing software, you're not all of a sudden just going to go, hey, sure, Joe Schmo, do whatever you want on top of to modify our software, etc. That's why there are certain

things that like you know in our world and you know resolve people would be like oh i'd love it if black magic would just expose that and what they're trying to say by that is i wish that black programmers at black magic would build in these API hooks so we can direct resolve or whatever the tool is to do something and sometimes that is for strategic money reasons sometimes that's just because nobody's ever thought that somebody would need that use or or do something like that so that's an important distinction right now, I think, to make is that just because, as we're going to discuss, coding has gotten and programming has gotten in some ways, in some ways not, much easier, you are still at the behest of the ecosystem around you that you're trying to control

with these programs, because not everything's going to expose these hooks to do exactly what you want. Yeah, because specifically what we're talking about with writing our own tools for post-production workflow, obviously we're going to be connecting to a lot of different existing tools and existing workflows. That's the whole point, right? We're not talking about I'm going to write my own color corrector here. I'm going to write my own nonlinear editor. If you want to do that, go with God, enjoy. But for practical purposes of what we're talking about today, making our post-production workflows faster, easier, more flexible with custom soft. We're really talking about using APIs to do clever things across multiple existing software and workflows.

Yeah, totally. So the thing I want to get into is this distinction between, and I'm going to use this term just because it's something that I've heard, but not necessarily the right way to deposit it. But it just, it'll kind of, I give the old versus new or the hybrid approach is some, some legs here. And that's sort of what is vibe coding and what's the opposite of vibe coding? And I will just, I have been in the habit recently of calling the non-vibe coding stuff analog coding. God, I hate that too. I know. I know.

I know you hate that. It's cheesy. Somebody I know and is well respected in the industry gave me that term. And I was like, oh, it kind of makes sense. All I'm going to say about analog coding, whether you hate it or not hated, it's just traditional programmers, right? People writing the actual code themselves, bug checking it, you know, running debug algorithms, looking at it, syntax, etc. versus sort of the newfangled way of vibe coding. And vibe coding is a relatively new thing.

The Google machine tells me that this word was sort of coined by this guy, Andre Carpathy, in February of 2025, actually. And he posted about it on Twitter. And he is just a, his definition is a style of programming where you essentially give yourself over to the AI, describing what you want in natural language and just go with the flow. You're not carefully reading or understanding all the code that the AI generates. You're just kind of viving with it and iterating based on what works and what doesn't work, right? You can see the steam coming out of Joey's head right now.

Okay, so let me give you a practical example of something like the vibe code. So let's just say that you wanted to, I don't know, do something really simple, like super simple. Like when you log into your Mac, you want a couple network drives to automatically mount, right? A lot of people do that through the built-in OS, but you could write like an Apple script. That's how I do it, right? I have a little Apple script. So through some trial and error, I wrote an Apple script,

trying, you know, various, I didn't know Apple script very well, some syntax, wherever. And it took me five, six, seven, eight iterations to do it. But then I realized, oh, but now I want it to give me a notification when it mounts these dry. And like, I got down this hole where I was sort of starting to go like, okay, I'm learning, I'm building, I'm learning, I'm building, and making mistakes.

And next thing, you know, I spent like a stupid amount of time. time, like four hours trying to get, you know, notifications on two drives to pop up, to mount, and, like, what I'm like, this is stupid. I go on Claude or chat GPT and I say, hey, here's what I'm trying to do. Can you do it for me? Finks? Bam. Here's your Apple script.

Put it in your startup items, done, right? So I literally, in just natural language words, described to the system, the AI in this case, I think it was Claude at the time, and explained it what to do. And it spit out something that I had previously. spent a few hours trying to figure out. That's kind of vibe coding, right? And that's like an ultimate simple layer. This can extrapolate like leaps and bounds,

extrapolate exponentially how complicated it is. But that's basically the gist, using natural language to tell the machine, the AI, or the platform that you're using. We'll get into those in just a little bit. Hey, this is what I'm trying to accomplish. Can you help me do it and spit out something? Yeah, and I've kind of always said

since these AI and LLMs kind of first started becoming usable, that I consider them to be kind of the highest of high-level programming languages. When you talk about the level of a programming language, you're talking about the distance to the hardware, right? Again, how much abstraction are we doing between you, the operator, and the actual... This is that next level up, right? This is like you're taking something that's already abstracted through SDKs and APIs,

And it's layers upon layers, upon layers. You know, early days, the first computers were defined, you know, how do you go from, for example, a calculator to a computer? A calculator has a set of specific ins and outs, essentially, right? A computer follows instructions. So the first computers were programmed with very, very simple, low-level instructions that directly manipulated things like memory and CPU instructions and stuff like. that. Then we wrote assembly language to kind of abstract that a little bit easier. So you would say, okay, instead of pulling up the actual instruction value for what move memory is, now it's MOV. We can move this memory. But you're still really low level. You're talking about what bits

and bytes of memory to put in different places and then what instructions to call them CPU. You can see how that extrapolates up, right? But then we go and we write languages like, C and C++ that have almost English-looking syntax for while if things like that and that again gets compiled down to machine code and then binary and all that stuff later on but for the programmer it's easier then we came up with scripting languages Python JavaScript etc where you don't have to think about what the computer's doing the back end of the programming language is handling things like memory management and stuff like that great easy now we get to these LLMs where you don't actually need to write the instructions in a specific language.

You can write the logic out in English and ask it what to do, and it will extrapolate. And this is where it's important to kind of think about what these LLMs are good at and what they're not. What they're really good at is looking at gigantic data sets, because that's what they were trained on. Like you said, you were trying to write a specific, easy little Apple script to get notifications to work. Are you going to sit through reading all the documentation of how AppleScript handles notifications? Or was Claude already trained on all of that documentation and examples and such? And can just easily say, okay, he's asking for a notification in this format.

This is what a notification code looks like in AppleScript. Boop, boop, bo, bo, bo, put those two things together. Output the exact instructions you want. And if it's well trained, it also can. And so the interesting thing about this is that, to say in a slightly different way, these tool sets are only going to be as good as the training that they receive, right? And a little later on, we'll talk about some, because everybody knows about the chat GPs and the clods of the world or whatever, and those are perfectly fine for doing base level

thing, but there are platforms that excel at much more sophisticated, full-stack programming. And the reason that they're more sophisticated and more functional than, say, a chat GPT or a Claude or whatever is because they've been trained on this specific type of thing with a lot more nuance and a lot more information than, say, a generalized public kind of system like Cloud or ChatGPD does. That's not saying that those major LLMs can't do a relatively good job. But if you were, you know, like AppleScript or whatever, ChapT, fine, Claude, fine. If I was getting into something where like, oh, man, I have this specific FPGA board that I'm trying to, you know, I bought on, you know, Ali Express or whatever, and I'm trying to program and it's all hex code. Like, yeah, that's probably not going to work too well with these big, these big elements. And this is an important thing to kind of remember, too, when you're dealing with LLMs is they only exist in the world of already solved problems, right? Correct.

They're not going to come up with new algorithms. It's okay, you want to have a, you know, write, have Claude, write you a program to search through all your scripts and, you know, extrapolate certain things for your producer or something. Great post-production workflow use case. Okay. Fine. But if you want, and it's going to be great at that, because all of the kind of key intellectual parts of what you're asking it to do exist out in the world. already. You are not going to ask Claude or chat GPT or anything else how to make cold fusion work or how to get a or in a more, you know, reasonable example, how to optimize a sorting algorithm for performance on a new CPU that they don't know about. You know what I mean? So can I tell you some optimize it can do has already been done. If you are trying to come up with like, okay, color science, for example, if you're trying to come up with.

some kind of new and novel color matching function that nobody's done before. No, these LLMs are going to have no idea what you're talking about because there's no training data surrounding it. Support for this episode comes from conform tools. Conform tools allows you to translate timelines between Premier and Resolve and other NLEs while automatically solving common issues that normally need to be fixed by hand. Avoid time-consuming trim and transfer issues and securely send large media files to collaborators at a fraction of the size, and in minutes instead of hours. With a growing toolbox of features, let Conform Tools handle the tedious stuff so you can focus on the creative. Built by Post Professionals, Conform Tools helps editors, colorists, and conform artists move faster and finish stronger.

Learn more at conform. So what's interesting, one of the things that I think is an interesting development as these two, so obviously people over decades have built up their skill sets in programming and there's, you know, a huge repository of talent, of code, APIs, SDKs, whatever. Along come these LLMs and we get into this vibe coding world where it's just speak your mind, create a tool. I've always been interested where that combination exists, right? Because, like anything else like this, that there's no such thing as,

automagical perfection, right? Like, it doesn't, like, you're not going to just do something. And so, like, even in my own journey over the past year or so, I've been led down a lot, a lot of holes where it's just been like, oh, okay, we just spent three hours going through this and you forgot about this or you hallucinated this or that's not a thing, like, you know, or whatever. There's a myriad of problems that there. So it got me from the very beginning thinking about, well, what do real programmers do

in this? I mean, do they just revert back to the old ways and doing everything by hand? How do they leverage? So I started looking into this and I started talking to quite a few people. And one conversation popped out. We have a colleague that works at one of the biggest post-production and production installations in the world. And I was asking her about, you know, she had her role there. She was hiring people to do sophisticated, you know, programming work. And she said almost all the programmers that she's interviewed over the past, you know, half a so, you know, half a so decade, they use both. They are doing repetitive, difficult, tedious tasks with LLMs or some other sort of AI, but they are still doing the ideation, the bug, like the process, the thinking, the big picture, the 50, like, I want it to do this kind of thing. They're still doing a lot of that work by hand and utilizing. the LLMs as just another tool set, almost like another library in their world, or for us,

it would be like another plug-in or something like that to try to get, to push the ball faster. Because to them, it's not about, they're going to arrive at the same point probably, right? Maybe, you know, likely. It's just whether it's going to take them three months to do that or it's going to take them three weeks to do that, right? And that's where I think that a lot of, you know, people who already are good at programming are looking at these tools in vibe coding. It's like, okay, look, I can get 90% of the way there with this tool doing what I want,

you know, like doing it automatically. And then knowing with my knowledge, I can go in it, that's BS, no, that's what this is inefficient. You know, they're double checking that work. And that really makes a lot of sense to me, right? Is that, you know, both people like me who are newbies at it just go, wow, this is amazing. I can create this thing. But even in my short time, I've gotten more.

to me like, hold on a second. Like that, why are you doing it that way? That doesn't make sense. Like, think about it this way. And the more knowledgeable about it, it's actually like this weird, I don't even know what it would be, like inverse square law or something, right? Where like the more you get into vibe coding, in a weird way, the more you get into traditional programming, because you're like, you're wanting to like double check it,

figure it out, understand it better, rather than just accepting it as like the only way of doing it if that makes sense. Yeah, and this is kind of the most important concept, I think that anybody can get when it relates to using LLMs for programming or anything else, actually, which is the universal truth of garbage in, garbage out. You know, we deal with it in color grading. You give me DV cam footage from 1999 that's overexposed. I can only do so much.

So much. You give the LLM something stupid. Like, write me the next cool app that's going to make me rich. It's not going to give you anything actionable. So the most important thing of any of this is to be able to conceptualize and describe the totality of the problem you're trying to solve. And when I say totality, I mean how does it handle all different kinds of inputs? How does it do X? What does it do with Y? What do you want it to how do you want it to be structured and to ask the right questions and to give the right terminology and the right structure? You need to understand how computing works. Otherwise you're going to like you said go down these rabbit holes of hallucinations that don't get you anywhere. So if you can clearly define the problem and I mean verbosely to the point of not just okay, write me, something that will take my EDLs and clean them up for how my client wants them.

No, no, no. You need to be able to say, okay, the EDL consists of a tab separated list with source time code, record time code here. For our application, we might not care about source time code, but you still need to have it in the file. You might need to explain stuff like that. You know, you need to dig down to the base level concepts of what you're asking the computer to do.

And then, yeah, the LLM can do a really good. job of cross-referencing its bigigabytes of training data and putting all those pieces together. 100%. And it's actually really funny to me that that part of this movement, if you will, is no different than the analog, you know, regular programming. Like there's some big picture concepts that are, are unique. So as you said, clearly defining the problem in a way that's more than just, as you said, you know, make me some cool things. Like really explaining. it step by step. And not just defining the problem for the LLM.

You should be able to sit down and draw out a block diagram of exactly what you want this software tool to do by yourself first. That way when you start, because you're not going to try to one shot the whole thing and say, okay, give me this tool that does X, Y, Z and all these different things, right? You're going to probably want to break it down, be like, okay, here's the overall concept. Now write me a module that does this EDL processing. Write me another module that handles file I.O to send things to frame I.O. or Dropbox or whatever like that. You know, it's easier to break the problem down into smaller chunks and that you can then define those smaller chunks in their totality.

But in your head as kind of the virtual product manager, you need to understand what every component of this imaginary tool is going to do and describe how they all connect, not necessarily all in one easy description. Totally. And I would add on to that. It's also like, there's a, I know this is going to sound funny, but there's a level of like hubris breakdown that has to happen here to get the most out of these tools, right? Like if you're just like, oh, well, of course I know this or of course, like, I think it's also important as you're working through these problems. So to define and be honest with the platform, the LLM, what you do know and what you don't know, right? So like, if you know, like, hey, I know that this tool uses, I'm just picking one out of the hat, multi-part chunks to do an upload, right? Like, I know that, but I don't know how encryption works for multi-part uploads.

Can you tell me how, like, can you build that? Like, just kind of, you know, being aware of the things that you don't know and the things that you do know, I think also really give that, you know, the process a lot more validity. And the other thing I would add there, too, is that, like, I can't discount the idea that the more knowledge that you have about a subject, the better off you're going to be, as air quotes vibe coder right so if you understand how like in the example i just gave how html works how csss works how uh you know basic javascripting works whatever like you're going to be a leg up to know when that llm is doing something stupid it's hallucinating like it just can't

possibly work like that like i'll give you a great example of this uh a couple weeks ago i i was i was sick i had um uh i was you know in bed for a week or whatever and i was just playing i was like, oh, you know what, I'm going to build a new dashboard and home assistant for my, my ubiquity, my Unified network, right? And like, instantaneously, it gave me this, like, beautiful dashboard. And I'm like, oh, my God. And then I'm like, hey, this doesn't appear to be changing. Oh, that's just a placeholder because it looks cool. Um, really, like, you can tell me that information from this device? Nope, no access to that device. I'm just, like, it just looks cool, right? And You're like very easy.

I'm like, very quickly, I'm like, oh, so you don't have access to this sensor on this switch. Like, and just knowing some of that terminology, it's like, oh, you're correct. I don't have. But I do have access to this sensor, which we could have. You know, like, I'm just saying some of that baseline knowledge about whatever you're trying to do. Like, even if it's just conversant knowledge even, can really go a long way and helping build a better tool. Yeah. Even the best LLMs in the world, even a Star Trek level computer.

human interface that is like way beyond anything that we can even conceptualize, right? If that existed, it would still only be as good as your ability to describe a problem and describe a concept, right? And that's the most, like basically take your LLM and say, if I could just hire a programmer who is very good at this one particular niche thing to do this module, what would I be telling them? right it's the exact same skill set of managing people except you're managing robots right and and the last thing you said there is it really important too i think the other the other part about this is um evaluating output i think is a really is a really interesting is really interesting part of this because like you'll get something out of this but then what like your job as the human is to look at it like and i i've found in my experience too that like okay fine it outputs

something for me, I deploy that, I look at it, and I'm like, that leads to more iteration, more testing, more whatever. And here's the danger of it, right? Is that like all of these models and platforms, they have relative, I mean, not for most, most people, they have limits in how much you can press them, how much heavy lifting they're going to do in any given time period, right? So like, you'll save yourself money and be more efficient to if you can do this in an organized, this kind of work in an organized fashion, right? So instead of like, you get an output from an L.M for something, you deploy it, and instead of going, fix this, give me a new file, fix this, give me a new file. Just like you would, like a program, a product manager would

in the real world at a regular software company, they would build a report that says, here are all the problems, I'm ranking these problems and the orders that they need to be fixed based on severity. This is what I would like to see the outcome be and feed that back. You'll actually end up being a lot more efficient with the costs and the use of your LLM than just trying to one off and iterate things as they come up. Yeah, and that's where I think a lot of people fall down is they don't know how to essentially beta test, right? This is a specific skill to computing that I think a lot of people need to kind of get better at, which is how do you test something that you're not 100% sure of? What that means is, and this something on an LLM can't

you with. This is something that Google can't help you with. This is something, you know, you need to know, again, you assuming you already know the totality of the problem you're trying to solve. So you have it mapped out in your head or on paper what this tool does. Now how do we test it? Well, first we feed it ideal things. We feed it the most easy possible input, the most easy possible scenario and make sure that works. If that doesn't work, well, we got to start figuring out the base. level stuff, right? But then what you got to do is you got to start testing things what we call boundary conditions where, okay, everything makes sense except I'm going to do one thing that might be unexpected. I'm going to put a negative value here where it's only expecting a positive value. I'm going to put a special character in this string for the name of the timeline that this tool is going to manipulate. I'm going to see how it handles drop frame versus non-drop frame time code. I'm going to change the frame rate of this one source. And the way you do this testing needs to be both organized and methodical, methodical is the word. Because just like any other

kind of troubleshooting, you want to reduce the number of variables. So you built this awesome tool that you vibe coded to handle some kind of post-production, Let's say it does some kind of manipulation to a timeline. Okay? Great. Works on your first couple timelines you tested on. Cool. Now what's the next step? We need to go through and remove variables. We need to go through and test it with every frame rate. Okay. And test it with every frame rate, but nothing else changing, which means you need to go into your NLE and make five identical timelines of different frame rates, right? Test all of those, see what happens. And then that will introduce things, problems that you need to solve. Okay, great. Now we've got the frame rates solve. Then we figure out things like drop frame, non-drop frame, different time code formats. Do the same thing. Then you do great. Okay, I'm going to try it with different resolutions. Then I'm going to try it with different sources. Then I'm going to try it with different naming. But the big thing here is we're looking at the structure of what we want the tool to do and we're finding out what we can test that only changes one variable. We're not going to say, okay, I've got five different timelines from five different clients. I want to run through this tool. Just throw them willy-nilly. at there. You're going to end up with 15 different errors that aren't able to be tracked down. Yeah, you don't know what you're testing at that point. Exactly. So you need to, you need to be able to

build test cases to input into this tool you're making and understand how to do that where you're only changing or testing one variable. You want to be able to verify, okay, this timeline going through this tool works 100%. Right. That's kind of our base level. Then we change. one variable that works 100% great then we change that same variable again to another thing oh that broke now we figure out what we need to fix in that pathway and we figure out how to fix that before we start testing other things and throwing other random stuff at this so being methodical about your testing is something that the LLM can't really help you with what you know it comes down

to you understanding the problem and nobody else can do that for you That's how you kind of get from the, wow, I just told the LLM to write this and it came out with all this output that actually kind of works. Awesome. This is really cool to this is a tool I can actually use in my day-to-day work and trust. You know, that's how you bridge that. And I actually think there's, I actually think there's a couple middle milestone points on that process too. Like, so I'll talk about this in just a moment. one of the examples I want to give is something that I recently built using this methodology,

methodology, rather. But one of the things I was thinking about, and again, I think it's because I know the right questions to ask. So I built a tool, this client portal that we'll talk about in just a minute. And yeah, eventually I needed to test it, right, with various, and you've been testing it and various uploads and we've found some problems. But my point is, even before I was ready to go out and test various uploads and deliverables, I was asking it question like audit level questions like, oh, I noticed that you created this link that seems to be a public link.

Is this a security problem that I'm going to be facing, right? Or like I noticed that that took, you know, it seemed like it took a long time to produce that that page. Is this the most efficient way to do? Like, and those are just really super high level questions, right? But like security, performance, you know, redundancy, follow. back. If this doesn't work, what happens is this doesn't work? Is somebody presented with a warning? Is it a hard crash? Like all of those iterations as you're developing, you need to start thinking a little bit more like a developer. Like, okay, if this goes bad, what happens? You know, if this doesn't work,

what happens? And, you know, or like, or how can we get this better? And I think that's, I think that one of the problems right now, and it's not just unique to vibe coding, it's just our society in general, right? Is that like something, you know, computer does something cool and we think it's a Messiah. And it's just like, no, no, no, no, no, no. Like, it's not done. Yeah, you can get very dear and a headlight by some of this output. And you're like, oh my God, this is the coolest thing. And then you start banging on it and you realize that the LOM just made some placeholders for you like I earlier described. Or, oh, really, that secure upload portal, everything's totally not encrypted and available in the public. Like, you probably don't want to fix that, you know, things of that.

And again, that goes back to you need to. have a base level knowledge and you need to if you're trying to get into big making a tool that does something yes we don't have to go down on the the individual line by line code level anymore that's a great time saver but if you don't understand the overarching concept of what you're trying to do that's where you need to focus your self-education if you will so let's give a couple examples about this i know you have a couple of yourself that you've you've used these tools a little bit i'll start out with the one that i've been i've been teasing so um about two weeks ago three weeks ago i got a renewal bill from a vendor that we use for our client upload portal and go, oh, they're raising their

prices again, right? And it was one of those things that I was using this particular part of the portal. I was using specifically with a couple clients. I think you'd only use it once or twice. Like, it was just like, it really was turning out not to be worth the investment. And with this stuff in mind, I turned, you know, on a lazy Friday afternoon, when I turned to, I turned to Cloud and said, here's what I want to do. Here's the model of what I'm trying to do. Help me do. Help me it. And that was a pretty relatively straightforward set of instructions that I gave it. So number one, I knew that I wanted to use storage that was not local storage, like not a server running to my basement or whatever. I wanted to use something that was globally available at even at edge cases,

right? And so that kind of meant something like S3, Wasabi, Cloudflare R2 or whatever. So like before I even plugged, you know, went to, you know, Cloud.AI, I started looking at, okay, where are the costs involved with these services, right? Oh, this one has egress. This one doesn't have egress fees. Oh, cool. This one, this one over here, it doesn't charge me a fee whether, like, you know, this, you know, for whatever this operation is. I like that. And I started building this pros and cons lists of the different storage models that I thought could work, right? I then started thinking about, as you said earlier, like literally like a block diagram, I was like literally just drawing pictures of, okay, if this happens, I want this to happen or whatever. And then it took me like

pretty much all afternoon on a Friday to work out the, here's what I want, here's the tools that I would like to use, okay? Here's why I would like to use those tools. Is there anything I'm missing in connecting all these tools up? Go for it, right? And it asked me some questions about various, you already have an account. Are you already signed up for this? Can you go get the API key from this service so I can connect it to this service, right? And it, like, before I even got any output, it was probably a half a day of figuring out all the various pieces, what I was going to need from various pieces, etc.

And then when I got it to do the output, that part was incredibly fast, right? Like, within 24 hours, and you can attest to this. You were like, oh, what are you doing? You're like, we're going to break all the shit for it. I had had, it had developed, sorry, it had the storage. I ended up using Cloudflare storage for a couple different reasons,

but I had Cloudflare storage, and it created a multi-part chunk uploader that we could embed in our website that put stuff to the cloud storage automatically, but chunking it up and encrypting those chunks and presigning those chunks, just like, say, Frame I.O. does to pop it up in the thing and spit it out at, you know, a gig a second at line speed up to that server. But in that process, you started looking at it. I started looking at it and going, well, this is stupid. we're going to have to manage users and passwords. I don't like that. I don't want to have to manage something else.

Oh, maybe we could integrate it with our existing CRM system. Oh, yep, we can totally do that because there's an API available for the CRM system. Let me go get. And so, like, I had this idea and initiated it. It then brought, like, step two was a huge laundry list of questions, problems, and issues that, like, to you said, like, I wasn't, I couldn't roll it out in that current state. I needed to whittle those down. So I got authentication, user authentication working. I got encryption working.

I got all these various things. Like even to the point of like cleanup, like what happens if somebody cancels an upload? Where does that file go? I don't want to be charged for that and so on and so forth. And so it was only through some pretty rigorous testing, which we're still in, that we even got comfortable deploying something. And just this past week for the first time after a week of pretty much banging on straight, put it live in front of one trusted client and said, okay, try this out. see what you think. Reduce variables.

Right. And the first thing, they uploaded a file. And you know what the first thing I noticed? Not that the file was successfully delivered. I noticed a problem. I was like, ah, man,

they uploaded five files and it timestamped all of the file names. Like, it changed the file names. Like, that's not going to work because it changed the file names. Now the relinking in the project file in the XML they gave me is not going to work. So spent another hour or two going,

I don't I like you can put the file in the time stamp in a URL but don't put it on the file like things like that just kept popping up oh you notice one thing it does this it does that and so I think that there's this little bit of misnomer and what like should be a relatively easy project that vibe coding just means perfection out of the box and I will tell you it wrote a JavaScript worker for Cloudflare that was 1800 lines long it wrote a ht-toddhundred lines long it wrote a ht HTML interface or whatever UI part of this that was another 1700 code like I couldn't have done that work myself at all right but it wasn't like the first time it did it it was perfect right out of the box right it required a lot of questions a lot of digging I in fact I actually had to give it at one point because this was a surprise to me I always thought that LLMs were like knowledgeable all the time up to date to like that very moment right. Right. So Cloudflare came up with an update to how their UI works, and it kept giving me instructions that were dated instructions for how Cloudflare worked. Right. And I eventually got sick of it, went to Cloudflare and said, oh, here's the documentation, gave that to Claude and said, please read this and give me all further instructions with this new, because it was, its knowledge cut off at like the end of November of 2025. And here I was in the beginning of March of 26. And it didn't know about that, right?

So it's always a little bit of a give and take. Support for this episode comes from Flanders Scientific's XMP 551 and XMP 651, the flagship QD-OLED reference monitors that are reshaping modern grading rooms. Their large format and industry-leading viewing angles let clients see accurate images from anywhere in the room, and their true HDR and SDR reference performance makes single monitor room layouts possible. When everyone relies on the same display, you avoid the headache of explaining why the client and grading monitors don't match. Learn more at flanderscientific.com. You know, when we talk about garbage in, garbage out, if the data that it has available isn't current, well, it's not going to work.

And that's where you need to bring real knowledge of the actual situation, kind of, you know, conditions on the ground to the project and, you know, manage it accordingly like you did. And that's, you know, that's where these tools, I know I've probably been more skeptical than most. But I also use them for writing my own tools pretty regularly. You know what I mean? Let's hear about it. Because I know, I know one of the ones that you've done that I just think is just rad is that there's a, you know, you're often involved in these workflows with spot deliverables and like coming up next, next Thursday, next, Friday, like these cut, these cut sheets, right? Where it's just like, okay, you got one ad, but it's slightly different, 900 different ways, depending on when it's airing in the market, et cetera.

And like, that's a lot of manual, like, tedious work that like, God, I mean, yeah, I know you're getting paid for it, but like, why not just make, you know, work, work smarter, not harder kind of thing, right? Exactly. So some of the tools that I've done, and I can't go into super details because they relate to very large media companies and their internal work. close. But imagine you get a cut sheet. That cut sheet says, I have a promo that's, I have a 30 second version and a 15 second version. And the 30 second, there's a next Thursday at 10, Thursday at 10, tonight at 10, tomorrow at 10, next. Right. And they all have different tag language and they all

need simplest thing ever, slates made. Okay. Write me a script that parses through all of those data points in the cut sheet and uses you know image magic to make a P&G slate for each one that's named accordingly oh well I also have all this information and this company asks you to write a summary email of every spot that you shipped

including the promo ID number the tune in the campaign number oh well I already had you use all that information to make all these slates give me the email I need to send too with that same information, right? So we're taking all the information from different places, putting it,

and it's really just pointing these inputs to these outputs, but why would I manually do that? God, worst case, actually typing into the thing to make the slate, no, no, no, because that's how mistakes happen, right?

But even so, copying and pasting the same thing into three different places. Now, of course, some of this could be mitigated by the place it's being delivered to, being more efficient and having their act a little bit more together.

But as post-production vendors, we know that's never going to be the case. And we know we're going to be hitting a thousand different deliverable formats for a bunch of different companies everywhere we go. So every time we get hit with a weird challenge of, okay, now you need an Excel spreadsheet that has all the in and out time codes of these segments of this show, for example. You can literally just say, hey, whatever LLM, take this EDR, I just output from DaVinci Resolve, derive these segment times

based on these rules, and guess what? It'll actually work. It works really well, as long as you can define the problem clearly. That's why earlier, one of the things I mentioned was how do you actually make an EDL that works?

The LLM needs to understand things like source time code isn't optional, even if you're not using source time code. That was one of the problems I ran into with a very specific workflow that I talked about a little bit on some of our other episodes, basically I was given for a season of shows a massive amount of handwritten time code notes

from a producer in word docs right not an ideal way to go through your sessions and be like oh I got to type in this time code go here figure it out type in this time code go here figured out put it into chat gpt here's all the emails from the producer with the time codes and the episodes that we need notes for. What I really want is an EDL that has the note as the event comment, so the little starred line underneath the event, not the tape name, so that way you can get the full text. And I want you to take their time code, put it in the in and out of the record time code with a one frame duration, and then copy those to the source time code. And what this is going to do is it's going to give me a readable EDL that I can import into resolve as markers.

And it took a little bit of iteration of just explaining the output format, being able to clearly define this needs to be a compliant EDL with source time code, with record time code, with the character limits at the right times and the right fields and everything else, because it's more complicated than just saying, give me a tab separated list. But eventually, after about maybe 15 minutes of work, I had eight emails of notes that were handwritten all in my timeline and resolve with markers at the exact right. places, right? So that was one of those situations where me as the kind of director of all this needs to understand, everything needs to go in, everything that needs to go out from a conceptual place. And then once I can put that into a little prompt for the stupid robot, the stupid robot goes ahead and does all my tedious work for me.

That is. I'll give you another low level example of that because that's, that's brilliant. And I think you hit on a couple things that the biggest one being. And like I think everybody, not everybody, I think a lot of people tend to think about vibe coding, programming, whatever, as like, we're going to create the next most amazing tool. Like, remember like whenever, like, when, like, the app store from Apple and Android came out, right? Everybody's making the stupidest apps ever because they're like, there's a buck to be made.

And I think that some people are treating vibe coding a little bit like that. And I think what you said, you said in a roundabout way is that, like, it's this identification of a real-world problem that doesn't necessarily have to be the biggest biggest deal in the world. You're not solving cold fusion here. You're solving a small workflow thing. And I'll give you a personal example.

Recently, I've been on a string of a bunch of feature-length projects, and those projects have just a ton of deliverables, right? Like, you know, 10 different versions of the pro res. There's H2C5, multiple DCP versions. And I found myself creating these like sort of like drive inventory PDFs to like explain to the clients okay this is what's in this folder this is the best use of this this this is what's in this folder here's the but and I got like

I found myself you know sort of I had a sort of had a pseudo template working you know and then I would just change the client name change the but it was like it was so tedious to do and I was like this is a perfect job for something like an LLM to build for me so I had it build I said all I want to do is I want to prompt that I point you to the output folder, right? And it's a standard, because we use a pretty standardized naming structure in our project folders. Here is the basic definition of each one of these folders. I want you to take a screenshot of each one of these folders, insert it into PDF with the description with the file name,

and make a PDF for me that I can put on the drive. I still look it over, but it made, you know, 45 minutes in a work into, five minutes of work and all I have to literally do is point it to the source folder and it makes this drive inventory with nice formatting nice pictures and I just hand that off to the client and I'm done right and that's not really that's a compelling use case that we haven't had before which is hey I want a computer to do something for me but a program for it doesn't exist right and really it's a one off right right I don't need to write a app or a website or a whatever that does.

I don't need a dedicated app for this one producer's emails, right? Yes. But for this project, do I want to go through a thousand of them? No. You know, it kind of bridges the gap between fully baked, done, tested, marketable software products and base level, I need to get this task done. So that's a workflow one, but I'll give you a creative one too, right? So as I started off this conversation by saying that people at conferences were coming up to me and saying I'm writing an app for this and that.

And I think, you know, in the past decade or so, we've seen this cottage industry of DCTL plug-in type folks, you know, just pop up, right? Everybody in their mom has, it used to be Lutz, now it's DCTLs. I'm guessing at some point in the future, maybe it will be more, you know, O-FX, but that's infinitely more complicated with GPU tie-ins and stuff like that. But anyway, I got like sort of pseudo-gealous for a while of like, not, I didn't say pseudo-super is the right word, super jealous of a while. Of all these people I knew being like making DC. And I'm like, where did you learn? Like, and some people were just good at learning it, right? Like I know you picked up DCTL pretty easily because of your previous programming experience and like you were able to gronk real quick.

Like, oh, this is just the syntax. And I look at these things. I'm like, ah, right? So perfect need of vibe coding, right? I was doing a project maybe about two weeks ago, three weeks ago, where have you ever been watching, especially like on TNT or one of those kind of networks

that's always showing movies on like a Saturday afternoon where like at the end of the movie, instead of doing the full frame credit scroll, the image kind of just like bounces up to the bottom and there's like a big black bar at the bottom where like it just flows the credits. I needed to do that the other day. And I was like, this is manual.

I had to do it like four times. So this is stupid. Why am I doing this? So I just wrote a DCTL, and this is the stupidest DCTL ever in history of DCTLs. It literally just put a black bar on the bottom of the screen where I now had this bounded area where I could just put the credits on the bottom, right? But it saved me like five, six steps in resolve, finding that generator, putting it in, sizing it, or maybe I saved a preset or whatever.

Like, I just had this area now that I could just scroll text on it. and it was about it and like stupid right one off as you said but the ability to do those things quickly and like and who cares if I never use it again yeah exactly it can go in the trash you're done I put very little thought into it but I was able to explain it well enough for it to work and it worked right and so you know your level of sophistication with these things my point is is it doesn't have to be the coolest world changing thing ever think about small problems and how more efficient you could be if you solve those small problems. And I think that's really where honestly where vibe coding can step in for a lot of us is these small problems to fix, not the

huge ones, the small ones and workflow things. Yeah, I think it can definitely improve things. Yeah, absolutely. You know, it's one of those, like I kind of started with, I consider it the highest level programming language. It's an easy way to tell the computer what to do. And the real knowledge is in you being able to conceptualize what you want to do. Yeah. And I mean, so I just want to be wrapped this up by saying that this is its own sort of industry now, right? As people have sort of become to see this and as we talked about at the top, these models work depending on how well you train them, right? And so obviously some of the big players, Claude.a.I., chat GPT, you know, those are, you know, Gemini. Those are some of the big players from

the big players, right? But there's a lot of other smaller platforms. Some of the ones that come to mind are like lovable, Versel, Bolt, I'm trying to think of the other ones. I think it's replet or replit. These are different platforms that are, you know, LLM based,

but have specific levels of training for them, right? So, like, you know, if you're trying to do like a full, you know, full stack kind of thing, you know, web deployment for an app, right? Like you might go to something like Replit, right? Or if you're trying to do something like a portfolio site, you might go to another one of these platforms. The different vibe coding platforms kind of specialize in different things. So I would just say if you feel like you're not kind of getting it, the results that you want with one of the major platforms,

check out some of these more specific things. The other thing I would put out there too is that while a lot of these platforms can do this coding stuff, there's some quality of life things that the more code-specific platforms can do for you. GitHub integration, for example, dealing with, you know, different versioning of deployments, feature requests, things of that nature. Like, I've gotten really frustrated very quickly by, like, the base level chat, GPT, Claude kind of thing where it's like, you made me a version. I asked for a change.

And then you married that backup with an old version. Like, why did you do that? And like it required like that part got frustrating real quick. And then I made, I was like now I'm in the process of like setting up a GitHub so I can get, you know, better integrated with deployment and stuff like that. So there are different tools out there for for different things. And I think one of the other things that you'll find in this process is that you can be really more cost efficient once you get a better handle on how these different platforms work. So in other words, you might be able to use something like Claude as your your central platform. But then you're using some of these other platforms as you said earlier, Joey, like sort of module agents, right? They are really good at doing this one kind of thing. That doesn't mean that you can't combine all of them together. And it seems like you might be spending more money that way. You might not, actually. You might end up being more cost efficient in how you do this by getting things to focus on different areas too. Yeah. Very cool. All right. Well, that's a 90,000 foot view of vibe coding. Actually, in a couple of weeks,

weeks we're going to be really excited to have on a new sponsor of ours, the guys at conform. comform. Tools. And actually, Brandon Thomas, one of the principals there, I've had these conversations with him a bunch because he was, he kind of caught me on to some of this, like, you know, vibe coding stuff. And gosh, when we have those guys on, I think you're going to be really impressed with the things that they've done with image detection and image manipulation and all sorts of wild things, about 10,000 steps beyond what. this more complicated some of the things that we're talking about. So stay tuned for that.

Just as a reminder, you can head over to the Offsetpodcast.com for our full library of shows. This is our 51st show, so it'll take you a while to get through the previous 50 if you're new to the show. But wherever you find the show, please do us a favor and like and subscribe. Every like and subscribe goes a long way. And we'd love if you consider to buy us a cup of virtual coffee here at the link below on screen. Every dollar sponsor goes directly to supporting the show, helping them pay our overhead

costs or editor, et cetera. So anything that you can do there, we greatly, greatly appreciate. And a huge thank, as always to our sponsors, Flanders Scientific and Conform Tools. Without you guys, we couldn't do these episodes every two weeks, so we really appreciate that. Yeah, Joe, good stuff, man. I think that this is going to be really exciting where this goes, and I'm just, you know, I'm just along for the ride trying to figure it out as I go. But I do think for our workflows, our pipelines, you know, some of the small pain points and things, that we want to be more efficient at, vibe coding is a perfect match for it. Yeah, absolutely.

Very cool. So for the Offset Podcasts, I'm Robbie Carmen. And I'm Joey Deanna. Thanks for listening.