AI lowered the barrier to build, not the bar.

A few months ago I took a screenshot with my own API key sitting in the frame.

It was late and I was moving fast. I was standing up a lab environment bound for AWS, the kind of project that would have been out of reach for me two years ago, with an AI assistant doing most of the wiring while I steered. Somewhere in that speed, the terminal echoed a key back in plain text and I didn't notice. I pasted a screenshot into Claude to ask about something else entirely, and the assistant flagged the secret before I saw it. Luck, not a control. I revoked the key, rotated it, and sat with the uncomfortable part: nothing in my setup would have caught that, because nothing had to. My lab has no bar to clear. My lab, my key, no harm done. That time.

That screenshot is the whole story of this moment in software. AI lowered the barrier to entry: I was building something genuinely beyond my old reach, and it worked. What it didn't lower is the bar: everything a thing has to survive before real people and real data depend on it. I had cleared the first. I wasn't even looking at the second.

A few weeks later the same lesson found me from the other side. I'd been testing publicly available MCP servers, the open-source connectors people plug into AI assistants, looking for the ways they go wrong: indirect prompt injection, tool descriptions that don't do what they say, excess agency. One of them had a flaw that dumped my API credentials in plain text where nothing should have been printing anything at all. I pulled the thread, it held, and I ended up filing the first coordinated disclosure of my career. A beginner's mistake and a career milestone, in the same month. Both came out of work AI accelerated.

Here's why I'm telling you this up front. I don't write code for a living. I never properly learned. And this year I built and shipped working software anyway, because the tools finally got good enough to carry me across the gap. That should sound wonderful to you, and it is. It's also exactly how a secret ends up in a screenshot.

The distance between a proof of concept and production

An engineer who came up the long way knows the bar is there because they've been held to it. They account for logging, resiliency, access, and recovery from the first architecture diagram, because without those the thing won't be accepted, or it will break in ways nobody can see. Someone new to technical work hasn't had to think about any of that. Not because they're careless: they're learning a dozen new things at once. And when it starts to work, the excitement is real. I know that feeling firsthand. But most of the time, what's working is a proof of concept.

The distance between a proof of concept and production is a set of skills mostly invisible to the newcomer, and every one of them slows you down. That's the same reason InfoSec, legal, privacy, and compliance have always felt like friction. They slow you down on purpose. Those steps are where an organization decides, deliberately, what it's willing to depend on. And right now, in a lot of organizations, proofs of concept are quietly being used as production tools by people who never went through any of that. Engineers and developers start accounting for this as early as the architecture and data flow diagram, which most newcomers would never think to draw.

No one is immune. Last July, an AI coding agent at Replit was told, in writing, to freeze all changes. It deleted a live production database instead, and then, by the account of Jason Lemkin, the founder running it, misrepresented what it had done (Business Insider). The person at the keyboard wasn't a database administrator. He was building the way a growing number of people build now: describe the thing, let the agent make it, ship it. Replit's CEO called the incident unacceptable and shipped fixes within days, which is to their credit. But the pattern is bigger than one platform, and what I'm seeing in the real world is that the pattern is closer to the default setting than an anomalous event.

It's the gap between cooking and running a kitchen. Cooking a great meal is a real skill, and AI just handed millions of people the ability to easily "cook up some code." Running a kitchen that feeds two hundred strangers a night without making anyone sick is a different job: fridge temperatures, the allergen list, who washed their hands and when. None of it is glamorous. All of it is the difference between a reputable restaurant and an incident report. We can suddenly cook far beyond our training. We haven't learned how to adhere to the health code.

It's already in your building

If you lead security somewhere, you don't have to imagine this. Odds are, someone automated a real workflow last week with a tool you've never reviewed. Maybe an engineer. Maybe someone in marketing who just got a quarter of their week back and is, reasonably, thrilled about it. They didn't run it past you, because to them it wasn't a security decision. It was a shortcut that worked. That's the trap: it works, and working is the lowered barrier. Whether it's defensible the day it goes wrong is the bar, and that question arrives later.

Organizations tend to answer this one of two ways, and both fail. Lock it down, and the building routes around you (the marketer doesn't stop; they stop telling you). Let it run, and you're accepting risk nobody has named. The third way starts with an admission: you are already accepting this risk. The only question left is whether you accept it deliberately or by default.

What I'm doing about it

I sit in an odd spot for this problem. I work with engineers, and I work in governance with the leaders who answer for what gets shipped. Most of my actual job is translation: taking the thing one side understands and making it land for the other. That's my goal here too.

So here's what you can expect from me: When an attack makes the news and I can't tell whether it's real or just noise, I'll take it into my lab and try to make it happen. If it reproduces, I'll work out the defense a real team could actually deploy: a control, not a framework citation. If the risk turns out to be more theory than threat, I'll tell you that too, because knowing what you can stop worrying about is worth almost as much as knowing what you can't. And when I make a beginner's mistake along the way, you'll hear about it so you can take the lessons I'm learning the hard way back to your org without repeating them.

And the part I most want to be honest about: the same tools that put a key in my screenshot are the reason I get to do any of this. AI builds my labs now. It puts experiments within reach that a year ago I couldn't afford on skill, on time, or on money. I'm not nervous about that. I'm thrilled, and I'd rather walk into this new world with my eyes open than stand outside it - there are risks worth taking.

Somebody down the hall from you built something real this week. That's not going to stop, and it shouldn't. But things are moving fast, more people are shipping than ever, and the work that makes any of it secure, resilient, and compliant isn't keeping up. Stuff is pouring through the cracks, and a lot of people seem paralyzed by what to do about it.

I can't fix that from here. What I can do is keep testing: take the attacks making headlines into my lab, find out what actually holds, and write down what I learn, mistakes included. This site is me building past my own training too.

I'm going back to the lab tonight either way. Subscribe to hear how it went.