Choosing the right AI coding tool

Can a non-developer write production code with AI?

As I’m exploring how to build agents and apply AI in practice, I’ve been wrestling with a fundamental problem:

The many no-code and low-code tools, useful as they are, still have limitations today.

They don’t yet expose everything you need to have full control over your agent the way that code-based frameworks do. In many cases, that’s an acceptable trade-off. But in others, it creates real constraints and affects how stable and reliable your agents can be.

I’ve found my agents deliver solid output about 80% of the time. For the remainder, the output doesn’t meet quality standards or there are technical issues, like an agent that doesn’t return the expected result for the next step.

It’s very frustrating to hit this wall and not have full access to the control panels. My options are either to shrug and explain to stakeholders that this is as good as it gets, or to layer on automated error-handling. Neither option is particularly satisfying.

My own limitation

At the same time, I’m facing my own limitations around the tools I can use.

I’m not a developer.

I’ve been a solutions architect for nearly 15 years and have designed and delivered complex projects, many of them code-based. I’m fluent in the principles and patterns of building software.

But I don’t write code professionally. My focus has always been on writing specs, aligning with stakeholders, and working closely with an engineer to bring things to life.

So the question becomes: to reach enterprise-grade reliability, do I still need to either work with a developer or become one myself? Or can AI tools bridge that gap?

This post is my first step in answering that question: finding tools that give non-developers the right mixture of power and control. Whether that control translates to production-grade reliability is an ongoing experiment I’m running.

The limits of “Vibe Coding”

I began exploring whether AI could let me use code-based frameworks without actually coding.

After all, AI-assisted development (AKA “vibe coding”) is one of the most popular use-cases right now.

However, I really don’t love that term. In my experience, strong solutions don’t come from vibes. They come from planning, analysis, and careful design. That doesn’t mean I’m against using AI to quickly iterate and prototype—I’ve built a few toy projects this way and had fun doing it.

But even within that limited scope, I ran into challenges that seem fairly universal for non-developers. These tools are great at giving you a start, but things break down as projects grow. The AI loses track of features, introduces bugs, and the whole thing starts to feel fragile. It can also make suboptimal design choices that I don’t have the technical fluency to notice until it’s too late.

Surveying the landscape

Despite these issues, I was still convinced that using AI to build AI-powered systems was the right path forward. I just needed to find a tool that would work for someone like me.

So I started surveying the landscape. I had already experimented hands-on with tools like Bolt, Lovable, Replit, and Cursor. I wanted to make sure I wasn’t missing anything, so I used Gemini’s excellent DeepResearch tool to create a report on the space, including newer entrants and open-source tools like Trae and Void.

You can explore that report as a website here. (Caveat: I have not verified the report contents.)

One tool emerged as particularly interesting to me—Kiro by AWS. As of this writing, it’s barely a week old. But it offered a different paradigm for collaborating with AI that I found intuitively familiar and appealing.

Spec-driven development

Kiro is designed to produce production-grade code using a spec-driven workflow.

Instead of building code through loose back-and-forth chats, Kiro encourages you to work with the agent to create a proper spec.

Each spec has three parts:

• Requirements: Use cases written in EARS format that describe what each feature needs to do.
• Design: An architectural overview of how the solution will be built and how the components will fit together.
• Tasks: A list of implementation work to be done.

This felt intuitive to me. As a solutions architect, specs have always been central to my work, helping me align with clients and internal teams on what needed to be built and how. So the idea of collaborating with an AI on a spec felt not only natural but also very comforting.

Specs also help address a major challenge in AI development: context drift. When everything is vibed, it’s easy to lose track of what the system is supposed to do over time. This is when the AI starts eating its own code and introducing regressions.

For a developer, this might be merely annoying, but it is absolutely fatal for a non-developer who lacks the skills to understand what’s broken let alone fix it.

Conversely, specs ground you in a shared source of truth—a contract with the coding agent on how the system must work.

My hunch was that this workflow would provide me with the control I needed to keep a project stable and reliable over time.

Getting started

When I first opened Kiro, I felt the familiar discomfort that most non-developers probably experience when dropped into a clearly technical environment. The UI didn’t feel like it was made for me.

If you’re a similar profile (technical, but not a coder) I’d encourage you to push through that feeling. It fades quickly.

I fed Kiro a high-level project idea and asked how we should get started. Kiro scaffolded out some initial files, asked a few clarifying questions, and we were off. I had a basic proof of concept in 30 minutes.

From there, I acted more like a product manager. I tested the output, gave feedback to improve the user experience, and Kiro updated files and added features. It was awesome.

Cracks start to show

In the back of my mind, though, I kept wondering when the spec-driven workflow would kick in.

Eventually I asked, and Kiro explained we were still early and should keep iterating in chat. I didn’t yet realize that Kiro has two modes:

• “Vibe” mode, which functions much like other agent-driven development tools where you iterate via chat.
• “Spec” mode, which is the spec-driven workflow I was reading about in the Kiro docs.

I had unwittingly gotten started in Vibe mode, and this actually reproduced the instability I was trying to avoid. I eventually hit a limit where Kiro forced me to start a new session. It generated a summary briefing for itself to kick the new session off, but the agent still forgot certain details and I had to re-explain things.

This really exposed the limitations of not having a clear spec.

Without that grounding, the AI had to reconstruct the intent from the code and summary. My own fallible memory was the source of truth.

Switching to spec mode

Kiro was enthusiastic to keep building, but I asked it to stop and document what we had built so far, which luckily triggered a new “spec session” and got me into spec mode.

In a spec session, you can either write the spec yourself or iterate on it via chat. This moves the collaboration up to a higher level of abstraction—you work on requirements and architecture rather than diving directly into code.

Since we now had a lot of undocumented features, I asked Kiro to generate specs retroactively, and it was able to quickly reconstruct requirements and outline the architecture choices.

It felt like laying a secure foundation underneath a structure that had been floating.

Here’s a quick walkthrough of Kiro’s three-part spec workflow in action.

Requirements

The requirements tab of a Kiro spec describes what the system should do and contains detailed user stories and acceptance criteria written in EARS format.

For a non-technical user, this is the most important collaboration space. It creates a persistent source of truth and a much cleaner way to define requirements than iterative prompting.

Design

The design tab of the spec explains how the system works: the technical architecture and core system considerations.

I’m primarily relying on Kiro’s input here. However, it is a useful place to validate technical choices before they are implemented.

As we started building some more advanced features, I would feed the high-level plan to another LLM to get a second opinion. This produced a valuable dialogue and helped refine the design.

Tasks

The last tab breaks down the build into specific implementation tasks. It describes how the system will be built.

I mostly defer to the agent on this, but the explicit task list keeps work aligned across sessions and lets you review the plan before building starts.

In contrast, when I tried feeding the same high-level project idea into Cursor, the agent dove straight into coding and created a relatively complex project with a few dozen files. It was impressive, but also felt much less aligned and risked charging off in the wrong direction.

Reflections

Vibe coding really is intoxicating. It gives you technical superpowers, like wearing an Iron Man suit.

Features go from idea to implementation in minutes. Ambitious ideas that would otherwise take weeks or be dismissed as unrealistic are suddenly achievable. You’re working with the collective knowledge of a thousand engineers.

It’s thrilling. But it can also make you lazy.

It’s easy to sit back and let the AI take over. And I think that’s when the risk creeps in—when you stop thinking deeply about the architecture, requirements, and how it all fits together. That’s how fragile systems are built.

The agent will build whatever you want, but only the human can make sure the output is truly valuable.

Also, for me, it’s not enough to talk to a black box. I want to understand what’s happening. I want to watch a developer at work and learn from the decisions being made.

So I forced myself to stay engaged. If Kiro made a decision I didn’t fully understand, I asked for a second opinion. I challenged it on whether our approaches were optimal and scalable. In many cases, this surfaced real improvements.

What Comes Next

Even with these caveats, I can’t imagine going back.

It now feels viable to use code frameworks to build real internal tools without needing a full development team—my mind is buzzing with ideas of where I could use this approach to tackle new challenges or improve existing solutions.

And in a follow-up post, I’ll walk through my first Kiro project in detail and what I’m learning from it.