Your Dev Team Just Adopted AI Coding. Here's How to Keep It Secure.

Last November, I told a group of founders that within 12 months most teams would be doing about 95% of their coding with AI. At the time, several people thought I was exaggerating. This week, one of those founders told the group he had been a skeptic, he was happy to admit he was wrong, and his three-person dev team now loves working this way. A project he expected to take six months is on track to take three weeks.

Then he asked the question that matters most once the excitement wears off: what should he actually be worried about from a security standpoint? The answers from the other founders on the call were some of the most practical I have heard on the subject, so I want to lay them out here. Speed is real, and so are the new risks that come with it.

Start with the basics you can fix today

The founder had already done the first piece of cleanup. His team moved every hard-coded key out of the codebase and into a managed key vault. That is the right first step, because an AI tool that reads your whole repository will read anything sitting in it, including secrets that should never have been there. Once the keys are out, you have removed the easiest way for a mistake to turn into a breach.

The next layer is configuration. A few of the founders pointed out that the tools have settings that determine whether your data can be used to improve the vendor's models, and you should check them on day one. Beyond that, the group landed on a handful of habits that cost almost nothing.

• Remove secrets from the repo. Put keys, tokens, and passwords in a vault so the tool never sees them.
• Check the data-sharing settings. Make sure your account opts out of having your work used for model training.
• Limit what the tool can touch. Give the AI the narrowest access it needs to do the job, and no more.
• Keep source control behind a human. One founder's team lets the AI queue changes but never lets it check them in on its own.

None of this is exotic. It is basic hygiene, and it matters more now because the tool is reading and writing far more code than any single developer ever did.

Put humans at the gates that matter

The most useful part of the conversation was about where people sit in the process. One founder's rule is simple: the AI never has direct access to source control. It can prepare changes, but a human does a line-by-line review of every file before anything is checked in, and nothing runs unattended. He still does the final code review himself, which he admits has become a real burden because of the acceleration.

That burden is worth taking seriously. He is spending two to three hours a day on review now, and that is a lot more than a few weeks ago. One of the other founders suggested running the human and the AI side by side for a while, so the AI reviews every change and the human compares notes. After a couple of weeks you either build trust in the AI reviewer or find the specific issues you disagree with.

• No unattended runs. Every action the AI takes starts with a human request.
• A human delta check before merge. Someone reads every changed file before it reaches source control.
• Run AI review alongside your own. Compare the two for a few weeks to learn where the AI is reliable.
• Watch the review load. If review time keeps climbing, treat that as a signal to change the process, not to work later hours.

The review load matters because it eventually breaks the model. I run a one-person development shop right now, and I had 857 pull requests merged to production in five days, roughly one every ten minutes. I cannot imagine reporting that up a chain to someone who has to read every one. My advice to the founder was that he will soon need to automate part of the review or delegate it, because one person reading everything does not scale at this pace.

Use a second AI to check the first

Another founder described a setup I liked a lot. His team has one model write the code and a different company's model check that code for vulnerabilities. The logic is that a model reviewing its own output tends to share its own blind spots, so a model from a different vendor catches a different set of problems. In his words, AI checks the AI, and then humans sit above both.

He also described what happened to his developers. Because they spend less time typing code, he moved some of that time into the security perimeter: more human attention at the hardware level, the interaction level, and the API level. Those are areas he says the team should have covered years ago and never had the hours for. It has also made the developers' jobs more interesting, since they now spend time on problems that need judgment.

• Pair two different models. Use one to write, and a model from another vendor to review for vulnerabilities.
• Reassign freed-up hours. Put the time saved on coding into API security, access controls, and infrastructure.
• Keep humans above the loop. People set the rules and handle the exceptions that models miss.

Cross-checking models will not catch everything, which is why the next section matters.

Plan for holes, and limit how far they reach

A technical founder in the group offered a mindset shift that I think is the most important idea in this whole topic. Stop trying to write software that cannot be hacked, and start assuming holes exist and work to shrink the blast radius of each one. In the past, development velocity was slow enough that fewer holes got created. With AI, velocity is much higher, so you should expect more of them.

He also made a point about how attacks are changing. In the past, a zero-day usually meant finding one specific flaw in one module. Agentic AI is now good at chaining several smaller issues together into a larger break-in. Fixing that takes people whose job is to chase these problems down, often using AI tools to play the red team. Best practices belong in the core dev team, and a dedicated security function sits alongside it.

The risk is already showing up outside our own code. One founder had just read about AI agents posing as human contributors to try to slip changes into a widely used open-source package, and they were only caught in the end. If you rely on shared packages, that deserves your attention.

• Assume you have holes. Design so that any single failure reaches as little of the system as possible.
• Expect chained attacks. The new risk is several small issues combined, so test for combinations.
• Hire or assign security ownership. Someone should wake up every day responsible for chasing issues down.
• Watch your dependencies. Open-source packages are now a target for AI-driven impersonation.

Thinking this way changes what you buy and who you hire, which brings us to the practical tools.

Buy independent testing, and make it continuous

Several founders came back to the same point: you need outside testing, because internal review and AI review will miss things. One founder's team is preparing for SOC 2 and used an automated penetration testing service that cost around four thousand dollars. It scanned their code and returned a frightening report, with roughly 150 findings and about 30 rated high. The good news is that you can feed that list straight back into your AI coding tool and have it work through the fixes. Their app is significantly harder to break than it was before.

The same service offers continuous scanning, so you get hygiene-level testing all year instead of one annual snapshot. Another founder added that when his pen test included a code review, it surfaced far more issues than reviewing with an AI model alone. Others use well-regarded firms for their annual tests, and one team has an AI bot continuously gathering logs and maintaining compliance documentation, though that founder admitted it burns plenty of tokens and he is waiting to see how the audit goes.

• Run an annual pen test with code review. Human testers find issues that automated review overlooks.
• Add continuous scanning. It costs little next to a breach and keeps the baseline healthy between audits.
• Feed findings back to your AI tool. A long report is a to-do list that your coding assistant can start on right away.
• Pick a compliance auditor carefully. One founder said his first-year auditor had heavy turnover and the second year went better, so ask about team continuity.

If your customers include larger enterprises or public agencies, the audit trail also helps close deals, which makes the spend easier to justify.

A short plan for the next 30 days

If your team has just adopted AI coding, the order I would follow is simple. First, clean the repository of secrets and confirm your data-sharing settings. Second, put a human between the AI and source control, and track how many hours that human spends on review. Third, add a second model from a different vendor to scan the code. Fourth, schedule an outside pen test and set up continuous scanning.

Then watch the review load closely. The acceleration is real, and it is exciting to see a six-month project shrink to three weeks. The founders who keep the gains are the ones who build the safety layer at the same pace as the speed.