I accidentally launched 30 AI agents at once.
It wasn't some grand experiment. I was debugging, had Claude spin up sub-agents to tackle the issues, and before I knew it, 30 of them were running in the background, each chewing through tokens on their own task. I sat back and watched, expecting chaos. Instead, they just... handled it. One by one, bugs got squashed. Tests passed. The code was better than when I started.
That was the moment the whole game changed for me.
I Don't Have a CS Degree
Let me get that out of the way early because it's the thing that apparently matters to people. I don't have a computer science degree. I didn't grind LeetCode. I can't whiteboard a binary search tree from memory, and honestly, I don't care to.
What I can do is build things. Right now I'm managing around ten different applications across mobile and web. I run two businesses. I'm building production software that solves real problems for real people. And I'm doing it largely with AI as my execution layer.
By the old rules, I'm not supposed to be here. The gatekeeping around software development has always been thick. You need the degree. You need to know the "right" languages. You need to have opinions about frameworks. You need to suffer through the fundamentals before you're allowed to create anything.
I rejected all of that. Not out of arrogance, but because the tools changed and the rules didn't update to match.
What the Workflow Actually Looks Like
Let me kill the "vibe coding" stereotype right now. This isn't me typing "make me an app" and watching magic happen. There's a real process.
It usually starts with a general idea of what I want to build and the stack I want to use. I'll open Claude Code, load up the brainstorm skill in plan mode, and actually talk through the architecture. What are the core features? What's the data model? How should this scale? We build a plan document together, and that plan doc becomes the north star for the project.
One of the projects I'm building right now is Dymensions Dance, an online dance education platform featuring HD video lessons from Emmy-nominated choreographers. It's a real business with a real co-founder, real instructors, real revenue share models, and all the legal, operational, and technical complexity that comes with that. The platform has a web app, mobile apps in development, video infrastructure, payment systems, instructor onboarding flows, and studio partnership agreements. I'm building all of the technical side of that.
I say this not to brag, but to give you a sense of scope when I describe how I actually work.
From there, things get interesting. I don't use sub-agents the way Anthropic officially recommends. Instead, I have Claude itself spin up the sub-agents, each with their own specific goal or task. Depending on the complexity of the project, I could have eight to ten agents running asynchronously in the background, each burning through 100,000 to 180,000 tokens on their own. One might be standing up the entire backend. Another is building out the frontend component library. Another is setting up the database schema and migrations. They're all running at the same time, working through their piece of the puzzle independently.
Sometimes at the very beginning of a project, I'll have agents tasked with building the whole stack in parallel. It's not micromanagement. It's delegation. I set the direction, define the tasks, and let them run. When they finish, I open more tabs, review what landed, course correct where needed, and kick off the next wave. If the project has a mobile component, that's running in parallel too.
I typically set things up as a monorepo because it scales better and keeps everything in one place. That's not a decision AI made for me. That's architectural judgment from experience shipping projects and hitting walls with scattered codebases.
This is engineering. The execution layer just looks different than it used to.
What AI Is Genuinely Bad At
I'm not here to sell you a fantasy. AI-assisted development has real, frustrating limitations, and if you're going to do this, you need to know what they are.
The biggest one for me: AI jumps to code changes before fully understanding the context. You'll describe a problem, and before it's even finished processing the full picture, it's already rewriting files. Sometimes it fixes the thing you mentioned while breaking two things you didn't. Learning to slow it down, to force it to read and understand before it acts, is a skill in itself. You have to be explicit. "Read all of these files first. Don't change anything yet. Tell me what you think is happening." That kind of direction makes a massive difference.
The other major pain point, and this isn't just a Claude thing, is the visual and UX communication barrier. Describing what you want something to look like, the spacing, the feel, the subtle interaction details, is one of the hardest things in AI development. You can write a paragraph describing a layout and get back something that's technically correct but feels completely wrong. The gap between your visual intuition and what you can express in words is real, and AI hasn't bridged it yet.
These aren't dealbreakers. They're friction points. And being honest about them is important because if you go in expecting perfection, you'll quit the first time something goes sideways.
Human at the Gate
There's this phrase that gets thrown around a lot: "human in the loop." It makes it sound like you're a speed bump. Like the AI is doing the real work and you're just there to rubber stamp things and stay out of the way.
I think about it differently. You're not in the loop. You're at the gate.
The AI handles the volume. It writes the code, catches the bugs, manages the boilerplate, spins up the infrastructure. But you decide what gets built. You decide what ships. You decide what's good enough and what needs another pass. You're the one with context about your users, your business, your vision.
Even if AI gets dramatically better tomorrow, there's a layer of decisions that should always involve a human. Paying for services, handling sensitive data, agreeing to terms, making judgment calls about user experience, deciding what your product stands for. That's not a limitation of the technology. That's accountability. Someone needs to be responsible when things go wrong, and right now, that's you.
And honestly, that's the valuable position to be in. The code is becoming commoditized. Judgment isn't.
The Debate Everyone's Having Wrong
"AI is replacing developers" versus "AI will never replace developers." Both sides are wrong because they're arguing about the wrong thing.
The skill didn't disappear. It shifted. It used to be that the hard part was how to build something. Knowing the syntax, the patterns, the algorithms, the framework quirks. That knowledge was scarce and valuable because it took years to accumulate.
Now the hard part is what to build and why it matters. Having the taste to know when something feels right. Having the product sense to understand what your users actually need versus what they say they want. Having the judgment to prioritize ruthlessly when you could build in a hundred directions.
Those skills were always important, but they were overshadowed by the technical gatekeeping. You couldn't even get to the product decisions if you couldn't clear the engineering bar first. AI removed that bar, and what's left is the stuff that actually determines whether a product succeeds or fails.
The developers who will thrive aren't the ones clinging to their ability to implement a sorting algorithm from scratch. They're the ones who can look at a problem, envision a solution, direct AI to build it, evaluate the output with a critical eye, and ship something that matters. That's a different skill set, and it doesn't require a CS degree to develop.
The Barrier Moved
The barrier to building software isn't knowledge anymore. It's not what language you know, which framework you picked, or whether you understand Big O notation. The frameworks debate? In 2026, they're all good. It's like arguing about camera brands when every modern camera takes incredible photos. Pick the right tool for the job and get to work.
The real barrier now is time, focus, and the willingness to start. The willingness to open a terminal and describe what you want to build. The willingness to be bad at it at first. The willingness to manage ten projects at once because the cost of starting dropped to nearly zero and your ambition didn't get the memo.
If you're waiting for permission to build software, this is it. The gate is open. You just have to walk through it.
And if you're already through the gate? Stand there with intention. Know what you're letting through and what you're sending back. That's the job now.
That's being human at the gate.