Why Kiro’s approach to software engineering might be more important than AI code generation itself

“Can we trust artificial intelligence to write secure software?”

It’s an easy question to ask, but I don’t think it’s the right one.

The better question is this:

Can AI help us become better software engineers, or will it simply help us produce more code, more quickly?

There is a significant difference.

Over the past three years we’ve witnessed an explosion in AI coding assistants. GitHub Copilot, ChatGPT, Claude, Amazon Q and now Kiro can all generate surprisingly capable applications from a handful of prompts. They can write APIs, build user interfaces, generate tests and even explain code that would once have taken hours to understand.

The demonstrations are genuinely impressive.

Yet I can’t help feeling that we’ve become distracted by the wrong measure of success.

Writing software has never been the difficult part.

Designing good software always has.

We’ve Optimised for Speed, Not Engineering

The software industry has always loved productivity metrics.

• How many features did we deliver?
• How many pull requests did we merge?
• How quickly did we ship?

AI has simply accelerated this obsession.

Almost every demonstration focuses on the same outcome. A developer describes an idea in plain English and, moments later, a working application appears on the screen. It makes for fantastic conference presentations and YouTube videos.

But software projects rarely fail because developers couldn’t write code quickly enough.

• They fail because the architecture wasn’t thought through.
• Because requirements changed halfway through.
• Because security was considered too late.
• Because nobody documented the decisions.
• Because every new feature made the system a little more fragile.

AI can now generate thousands of lines of code in minutes.

Unfortunately, it can generate thousands of lines of poorly designed code just as quickly.

Speed has never been the bottleneck.

Quality has.

GitHub Copilot Solves One Problem Exceptionally Well

GitHub Copilot deserves enormous credit.

It transformed the idea of AI-assisted development from an interesting experiment into something millions of developers now use every day.

For implementation work it is remarkable.

It predicts code with surprising accuracy, removes repetitive typing and often feels like an experienced colleague looking over your shoulder. For experienced developers it is a genuine productivity boost.

But Copilot is fundamentally reactive.

• It responds to what you’re writing.
• It doesn’t usually ask whether you should be writing it at all.
• It has no understanding of the wider architecture unless you continually provide that context.
• It doesn’t know why your system exists.
• It doesn’t understand your business rules.
• It certainly doesn’t understand your organisation’s security policies.

That’s not a criticism.

It was never designed to.

Kiro Is Asking a Different Question

This is where Kiro caught my attention.

Unlike many AI development tools, Kiro doesn’t begin with code.

It begins with specifications.

• Requirements.
• Technical design.
• Implementation tasks.
• Testing.

Only then does it move into writing software.

At first glance that sounds like a small workflow change.

I think it’s much bigger than that.

Experienced software engineers already know that code is the final outcome of a much longer engineering process. Requirements are refined, designs are reviewed, assumptions are challenged and risks are identified long before anyone opens an IDE.

The problem is that AI coding assistants often jump straight to implementation.

Kiro attempts to preserve the engineering process instead of bypassing it.

Whether that becomes its greatest strength remains to be seen, but I think it is asking a far more interesting question than simply “How quickly can I generate code?”

Security Is Usually an Afterthought

Security has always suffered from unfortunate timing.

• Developers build features.
• Quality assurance confirms they work.
• Security teams eventually review them.
• Compliance teams identify problems.
• Architects ask for redesigns.
• Everyone becomes frustrated.

Security gains a reputation for slowing projects down when, in reality, it is simply discovering problems that should have been prevented weeks earlier.

The later security becomes involved, the more expensive every finding becomes.

Most organisations already know this.

Few consistently achieve it.

AWS’s Most Interesting Idea Isn’t AI

AWS recently published an article explaining how Kiro can embed an organisation’s security standards into every development session through persistent context using what Kiro calls Steering Files. Rather than repeatedly telling the AI to enable encryption, apply least-privilege IAM permissions, enable logging or follow internal standards, those requirements become part of the project itself and are automatically considered throughout development.

That isn’t especially glamorous.

There are no dramatic demonstrations.

No magical one-line prompts.

Yet I suspect it could be one of the most valuable ideas introduced in AI-assisted development.

Instead of teaching every developer every organisational standard, you teach the AI once.

Every engineer then benefits from that shared knowledge.

If your company requires encrypted storage, private networking, structured logging, row-level security or approved authentication mechanisms, those expectations no longer rely entirely on human memory.

The AI begins every conversation with the same architectural understanding.

That’s genuinely powerful.

But Here’s Where I’m More Sceptical

AWS presents Steering Files as a way of producing secure-by-default infrastructure.

I agree with the principle.

I’m less convinced by the simplicity of the message.

Steering Files don’t magically create secure software.

They simply enforce whatever rules you’ve given them.

If those rules are incomplete, outdated or poorly written, the AI will consistently produce software that reflects those weaknesses.

In other words, AI doesn’t eliminate architectural mistakes.

It scales them.

That’s an uncomfortable thought.

Many organisations still don’t have consistent security standards.

Different teams follow different conventions.

Documentation is incomplete.

Policies contradict each other.

Architecture decisions exist only in people’s heads.

Introducing AI into that environment won’t solve the problem.

It will simply automate the inconsistency.

AI Doesn’t Replace Security Architects

One aspect of the AWS guidance deserves genuine praise.

It repeatedly reminds readers that AI-generated security decisions must still be reviewed by experienced engineers before reaching production. Generated infrastructure, policies and remediation advice should always pass through human validation.

That honesty is refreshing.

Too much discussion around AI implies that expertise is becoming less valuable.

I think the opposite is true.

As AI becomes better at implementation, the value of experienced architects increases.

The difficult work has never been writing code.

The difficult work is deciding what should be built.

AI can generate infrastructure.

It cannot understand business risk.

It cannot negotiate competing priorities.

It cannot decide whether accepting a security vulnerability is commercially justified.

Those decisions remain firmly human.

Could AI Make Developers Worse?

This is perhaps my biggest concern.

If AI automatically applies security controls, configures infrastructure and generates compliant code, how many developers will actually learn why those controls exist?

We’ve already seen developers blindly accepting AI-generated code because “it looks right.”

Security may follow the same pattern.

Developers could become increasingly dependent on AI without fully understanding authentication, encryption, networking or access control.

That creates a dangerous illusion of competence.

The software appears secure because the AI produced it.

Whether it actually is becomes much harder to judge.

Ironically, organisations may end up needing stronger technical leadership rather than less.

The Future Might Belong to Engineering, Not Coding

After looking more closely at Kiro, I don’t think its biggest innovation is AI code generation.

Every major AI assistant can already write code.

Kiro’s more interesting contribution is encouraging developers to think like engineers again.

Specifications before implementation.

Architecture before syntax.

Security before deployment.

Testing before release.

Those ideas aren’t revolutionary.

They are simply good engineering practices that many teams abandoned under the pressure to deliver software faster.

Perhaps AI is helping us rediscover them.

My Conclusion

I’m not convinced Kiro will replace GitHub Copilot.

Nor do I think it should.

The two tools solve different problems.

Copilot remains one of the best implementation assistants available. It excels at helping developers write code quickly and efficiently.

Kiro appears to be aiming at something broader.

It is trying to support the entire engineering lifecycle rather than simply accelerating one stage of it.

Whether organisations adopt that approach will depend less on the quality of the AI and more on the maturity of their engineering culture.

Because Kiro cannot invent good architecture.

It cannot create security policies that don’t exist.

It cannot compensate for poor engineering discipline.

What it can do is amplify good practices that are already there.

And perhaps that’s the biggest lesson.

The organisations that gain the most from AI won’t necessarily be those with the most powerful models.

They’ll be the ones with the clearest requirements, the strongest architecture and the best engineering habits.

AI doesn’t replace those foundations.

It simply makes them far more visible.

If that happens, Kiro may end up changing software engineering in a much more profound way than simply writing code faster.