Software Engineering Principles When AI Writes the Code

As much as 30% of the new code at Microsoft is now written by AI. CEO Satya Nadella said so on stage, and Google’s CEO says 75% of its new code is now AI-generated. If you run an engineering team, that number should make you ask a fair question. When a machine does the typing, do software engineering principles still matter?

They matter more now than they ever have.

I know that sounds backwards, so let me explain why I believe it. I’ve started four companies and run engineering at three of them. I co-founded VinSolutions, which sold for $147 million in 2011. Today I run Full Scale, where a team of more than 350 builds software for our clients every day. Every one of those developers uses AI now. And the thing I keep telling them is that the old principles got more important.

The reason is simple. AI didn’t remove the hard part of building software. It moved it. It’s the same force behind how AI is collapsing the developer and engineer roles back into one job.

The bottleneck moved from typing to thinking

For most of my career, the slow part of software was writing the code. You knew what you wanted to build, and then you sat there and typed it out, line by line, for days. Typing was the tax you paid to ship anything.

That tax is mostly gone. AI writes a working function in seconds.

So the constraint moved somewhere else. What sets your pace now is how fast you can understand the problem and make a good decision about it.

Here’s the catch with all that speed.

AI is just as happy to generate a bad decision fast as a good one. It will give you a messy, duplicated, over-built solution in the same five seconds it gives you a clean one. The principles are what tell you which is which, and now you need that judgment at machine speed instead of typing speed.

The data already shows what happens when teams skip it. GitClear studied 211 million lines of code and found that duplicate code blocks jumped roughly eightfold after AI tools spread, while the amount of code being refactored fell off a cliff. Google’s DevOps Research and Assessment program (DORA) found in its 2025 report that AI amplifies whatever a team already is. A strong team with good practices gets faster and better with it, while a weak one just ships its problems quicker, because the extra code outruns whatever testing discipline it had.

The shift looks like this at a glance, and the sections below walk through each row:

What AI changed	What it means for your team
Typing stopped being the bottleneck	Hire and reward judgment over raw speed
Verification is now a huge share of the work	Treat QA and code review as core work
AI writes insecure code about 45% of the time	Security-review every generated change
The spec became the hard part	Write clear requirements before prompting
The classic principles are easier to break	Enforce them with more vigilance than before

The classic principles still hold, so know them

First, what didn’t change.

The textbook principles are still real, and your team should know them. Keep it simple, stupid (KISS) is about not making something more complicated than the problem requires. Don’t repeat yourself (DRY) is about not copying the same logic into ten places. You aren’t gonna need it (YAGNI) is about not building features nobody asked for yet. The SOLID principles, introduced by Robert C. Martin, are five rules for keeping object-oriented code flexible and easy to change. Separation of concerns, modularity, and abstraction are about splitting a system into pieces that each do one job well, with loose coupling between them.

I’m not going to re-teach all of those here. A hundred other articles already do, and most of them read like a textbook because they were written like one.

What matters for you is this: none of these software engineering principles became obsolete because AI showed up. If anything, AI makes them easier to violate, because it will cheerfully generate code that breaks every one of them and looks fine at a glance. The principles are the filter. Without them, you just produce technical debt faster than any team in history could before. Apply them well and AI becomes a powerful junior developer, one whose work you still have to check.

Let me be precise about the claim, though. The mechanical principles like DRY and SOLID didn’t suddenly matter more; they got much easier to break at scale, so upholding them now takes more vigilance than ever. The principles that genuinely rose in value are the human ones, and they run the rest of this article.

Quality assurance is now half the job

The biggest shift I’ve seen at Full Scale is in testing. Over the past couple of years, the fastest-growing part of the job on my teams has been checking code, because AI lets people produce so much more of it, and all of it still has to be verified by a human before anyone trusts it.

When your team ships far more code, somebody has to make sure far more code actually works. The writing got faster while the checking stayed exactly as slow as it always was. So the weight of the work moved onto quality assurance (QA), and a lot of teams haven’t caught up to that yet.

The developers themselves feel it. In Stack Overflow’s 2025 developer survey, the single biggest frustration with AI tools, named by 66% of developers, was code that’s almost right but not quite. That gap, between code that looks correct and code that is correct, is exactly where bugs hide. And the only thing that closes it is testing and review.

This is why I tell our clients that QA isn’t a step at the end anymore, it runs through the whole build. The teams that win with AI are the ones that treat a strong testing strategy as a core principle, not a chore they get to after the fun part. When the machine writes the first draft, the real skill becomes reviewing it well and catching what’s broken before it ships. That demands more review and testing discipline than most teams have today.

Security is the principle AI breaks most quietly

There’s a risk here that worries me more than messy code.

Beyond code that’s just almost right, AI writes code that’s flat-out insecure, and it does it with total confidence. Veracode tested AI output across more than 100 models and found that 45% of the generated code carried a known security flaw, the kind on the Open Worldwide Application Security Project (OWASP) Top 10 list. The detail that matters for the long run: the newer, bigger models were no safer than the small ones. That gap looks structural, which means the next model release probably won’t fix it. That is exactly why secure software development now leans more on the human reviewing the code than on the tool writing it.

So security review can’t be something you bolt on at the end. Someone on your team has to read generated code with an attacker’s eye, every single time, the way they’d scrutinize a risky pull request from a brand-new hire. The machine will not do that part for you.

Writing the spec became the hard part

The second big shift is about requirements.

For years, a lot of developers got to skip the messy work of figuring out exactly what to build. Product handed them a ticket, they coded it, and if the ticket was vague they filled the gaps with whatever seemed reasonable. The typing kept them busy enough that nobody noticed how little time went into the thinking.

Now the typing is fast, and the thinking is what counts. The industry has a name for this: spec-driven development. You spend real time writing a clear, detailed description of what you want before the code gets generated. A good spec spells out the problem, the constraints, the edge cases, and the acceptance criteria that prove it actually works, all before anyone prompts a model. There are whole toolkits built around this now, like GitHub’s spec-kit and Amazon’s Kiro, which make you write the spec first and let the agent code from it. A sloppy spec gives you sloppy software at incredible speed.

The hard part is what comes next.

Writing a good spec is tough, and a lot of developers have never had to be good at it. It means understanding the customer, asking the awkward questions, and saying out loud when something doesn’t make sense. That takes a communication skill more than a coding one, and it’s now the most valuable thing on the team. I’ve said for years that rockstar requirements beat rockstar developers, and AI just proved it. Feed a brilliant engineer a bad spec and you get bad software, faster than before.

The roles are blurring, and that’s the real story

Step back and you can see what’s actually happening. AI is blurring the lines between every role in software development.

The developer is now doing product work while the product manager reads generated code. The line between the person who decides what to build and the person who builds it is getting thin, because the building part got cheap. Everyone is becoming, as one of my podcast guests put it, both a builder and an orchestrator.

That guest was Mohan Reddy, a chief scientist at Cornerstone AI Labs who has spent his career on AI and the future of work, and he joined me on Startup Hustle for an episode literally called “Are Software Engineers Really at Risk?”. His answer, and mine, is that the engineers who lean into the broader role are fine. The ones in trouble are the ones who define themselves narrowly. It is the same reason AI alone will not make anyone a 10x developer, because the tool got faster but knowing what to build did not.

I put it more bluntly with my own team. If you’re just a coder, you’re done. The coding is the part the machine is best at. The judgment around the coding, knowing what good actually looks like, is the part that’s now worth the most.

The principles that decide it now are human

So if the mechanical principles are table stakes, what separates a great engineer from an average one in 2026?

It comes down to three things I’ve built my whole Product Driven philosophy around: communication, curiosity, and courage. I called them the three C’s long before AI made them urgent, and now they’re the principles that actually decide whether your software is any good.

You might assume AI will eventually handle this part too, and it’s a fair bet, because the tools get better at context every month. They can already read your whole codebase, your docs, even your tickets. But context isn’t the same as judgment. Someone still has to decide what the business should value, accept the tradeoff, and answer for it when it turns out wrong. A model can recommend a path, but it can’t be the one accountable for it, and that part stays human even when the agent writes every line.

Communication is first because the job is now mostly communication. You’re translating a fuzzy human need into something a machine can build correctly. That’s the spec work I described above. A developer who can’t write clearly, ask a sharp question, or push back on a bad requirement is going to feed the AI garbage and ship garbage.

Curiosity is what keeps a developer employable. The whole field is moving under our feet, and the only people who stay ahead are the ones who can’t help poking at the new thing. Mohan said it best on the show: “Always be curious. Always be learning.” I tell our engineers the same thing in plainer words. As long as you stay curious about how AI changes your job and how you can use it, you’ll be fine. Stop being curious and you’re in trouble, because this career never stops changing.

Courage is the quiet one. It’s the willingness to say “this generated code is wrong” when everyone wants to ship, or to admit you don’t understand something the AI produced instead of merging it and hoping. That kind of honesty only shows up on a team where people feel safe being honest. Do that, and your team catches the problems AI creates. Without it, bad code sails through review because nobody wants to be the one to question it.

The timeless principles matter more under speed

A few of the old principles deserve special mention, because speed makes them more important than they used to be.

Simplicity is the big one. When you can generate a thousand lines in a minute, the temptation is to keep all thousand. Resist it. The best code is still the least code that solves the problem. At one of my companies, EngagePath, an engineer pitched a quick, harmless little feature. It ate a month and pushed back work that actually mattered, all because nobody stopped to ask whether we needed it at all. AI makes it easier than ever to build the thing you shouldn’t, and faster too.

Readability is next. Code gets read far more than it gets written, and now a lot of it gets read by a person trying to figure out what the AI did. If the generated code is clever and dense, your team can’t maintain it. Plain, boring, obvious code wins, because the next human, or the next AI prompt, can actually work with it.

And testing, again, because it’s the principle that ties the rest together. Simple, readable, well-tested code is how you keep quality high while moving fast. That balance is the whole job now.

What this means if you lead an engineering team

If you’re a CTO or a founder, the takeaway is simple. Your team’s value now lives in judgment, communication, and discipline. How fast they type barely matters anymore. So that’s what you should hire for, and what you should hold them to.

In practice, that comes down to a few concrete things worth putting in place:

• Make human review of AI-generated code a required step in your definition of done, with security and edge cases checked explicitly every time.
• Treat the spec as a real deliverable. Ask for a written description of the problem and the plan before anyone generates a line of code.
• Hire and promote for judgment and communication, and test for them in interviews instead of timed coding puzzles a model can now ace in seconds.

None of that is exotic. It’s the same discipline good teams always had, applied to a world where the code now arrives faster than anyone can vet it.

The trap is to chase raw output. It’s tempting to think that since AI makes everyone faster, you should just find the cheapest developers you can and let the tools do the heavy lifting. I call that cheapshoring, and it’s a great way to generate bad architecture at scale. A cheap developer with a powerful AI tool produces messy software very quickly, and you’ll spend more cleaning it up than you ever saved. The judgment is the expensive part, and it’s the part worth paying for.

I’ll be straight about my bias here. I run a company that sells engineering teams, so a conclusion like “you still need skilled people” is good for my business, and you should weigh it with that in mind. I’d make the same argument if I sold nothing, because I’ve watched it play out across four companies: the teams that invest in good people ship software that lasts, while the ones chasing the cheapest possible output keep starting over.

This is the idea behind how we run Full Scale. When companies use us for staff augmentation services, they get engineers we’ve trained on the principles above, working as dedicated members of their team. We build offshore engineering teams in the Philippines that think about quality, communication, and the customer, because that’s what survives the shift to AI. It’s also why our developer retention runs about 93%, and why our clients stay with us for years. When you hire developers who own their work instead of just closing tickets, you get software that holds up.

That’s the kind of dedicated-team partnership behind results like NavMD’s.

The principles were always about making good decisions. AI just raised the stakes on every one of them.