This article is an update of a piece I wrote about six months ago on AI-assisted vibe coding in professional settings.
I’ve been consulting around machine learning for close to a decade. I was one of the first people to pay for ChatGPT in November 2022, when it launched. I’ve watched this frontier move, and I want to talk today about where it’s going as far as how it affects your workflows.
Below is just some data about me to help you see where I’m coming from.
In the last 18 months, I’ve built no fewer than 10 pieces of software. All of them are vibe coded. I don’t have zero software experience. I had originally gone to school for comp sci, a lifetime ago and I’m aware of my own shortcomings around this.
When I talk to developer friends, my analogy is that if Avid and Premiere were for professional editors, I’m a coder in the sense that Capcut is a professional tool. I’m going to promote myself here. SnapCursor on the The Windows version comes out in less than 2 weeks.
I also moderate /r/editors on Reddit, where we now have monthly dedicated threads for new tools – and open source tools.
And that’s where I saw the rise of these tools explode.
Through the eyes of Reddit: The astroturf problem
I know a lot of people building software. Much of it is low-hanging fruit.
On Reddit, I vomit in my mouth a little every time someone posts that they’ve built the perfect replacement for Frame.io. There are buckets of astroturfing: people showing up claiming to be post pros who just happened to solve a problem in their own unique way.
And yes? Sometimes they have.
The Gold Rush Lane
Easier to dismiss. They’ve built something they think is unique, and they’d like you to pay a subscription for it (that’s right, one more subscription in your life). They don’t understand the users in their rush to market. The dollar signs have blinded them to the reality of building. This is not the next billion-dollar Adobe acquisition.
The Problem Solver Lane
The small shop that hit a real problem and built the fix. If that’s you, and it’s your own tool, go for it. There’s little risk. It’s ready, and you’re probably fine.
Or it could be a vibe coder or other new company to the field.
I just saw a larger production trusting some small, usable piece of software. Right up until it generated thousands of small files on the SAN because nobody knew.
Both groups have the same problem. RISK.
So here are the five questions I ask before I trust a tool in a professional workflow:
-
Who maintains this if you/they disappear? For a solo developer: is this a codebase they will contractually hand over? Is it well commented and documented? Is it in a repository? If the answer is “it’s on my laptop,” that tells you everything you need to know.
-
What happens when an API or platform changes? Every tool that touches an external service is one API deprecation away from breaking. What roadmap does the developer have for ongoing compatibility, or is this a snapshot in time?
-
How was this tested? Not “does it work,” but “what did you try to break, and what happened?” If the developer cannot articulate their failure conditions, they have not looked for them. Can you say always in beta?
-
What are the security implications? Does it store credentials? Does it store personal information? Does it phone home or require network access? Anything touching content or client data demands clear answers here.
-
What is the update and support model? Is this a living product with version numbers and change logs, or is it a moment-in-time release? Is there a way to report bugs beyond a Discord server?
As I said, it’s about risk
None of these questions disqualifies a tool on its own.
What they measure is how much risk you’re taking on, and whether you and your client can absorb it when something goes sideways. The entire idea here is the conversation about the risk you’re now carrying on purpose.
I walk into facilities every day that have old documentation, old presets that nobody remembers the original creator or when. (P.S. Name your settings. Review your export and sequence setups!)
But that’s the pain around these new, vibe-coded tools. It’s addictive. A facility that quietly accumulates a dozen of these is now one API change or one bored developer away from breaking. In a world where reliability is the product, the leverage here is the risk.
So protect your exit. Limit your risk. Before you build a workflow on someone else’s tool, know how you get your work back out when it dies. What if the API behind them is a country your clients would have problems with? And then find out that your key tool’s backend has opted your client’s IP in for training. That could be video, audio, or yes, even transcripts.
Final thoughts
Just some extra thoughts. I’m seeing loads of open source too. I love really open open source, as I can evaluate someone else’s work. Yeah, really, it means I have Claude or ChatGPT analyze its weaknesses.
Another worthwhile conversation? Strategies for the manager or client who has already decided the answer is AI – but has zero idea what that really means.
At least for July, thanks for reading. I’m building constantly, and I’ll keep building.
And yeah, the answer here was never going to be “no.” It’s “yes,” with your eyes open and understanding what you’re dipping your (and your clients’) toes in.