Would You Rather Build an App in One Hour or One Week?

We've Seen This Movie Before

Keeping up with AI is hard. The technology moves extremely fast, it's often over hyped, and there's no shortage of conflicting claims, including CEOs predicting AI will take every job while, conveniently, selling the tools they say will do it.

Two things have happened, though. AI development tools have taken a genuine step forward in quality and capability, and the hype is starting to settle into a clearer picture of what's actually possible. People are realizing this isn't an easy button that fixes everything. It's a tool that can help us do some pretty amazing things, but it's still a tool, and it's harder to use well than most of us thought after our first "wow" moment with a chatbot.

We've seen this movie before. When the web took off in the late '90s, brick and mortar was supposedly finished. When mobile hit, everyone knew someone who knew someone making millions off a side-project app, which described maybe 1% of developers, while the app stores filled up with the other 99%. AI coding is following a similar arc. The "I built an app in a weekend" headlines probably won’t fade but will evolve into a more realistic picture of where it fits, from weekend projects to the enterprise.

Here's what those headlines usually leave out: they almost always come from startups and very small businesses. Enterprises are a different game. When you're handling customer data under HIPAA or PII rules, you can't ship-and-iterate on a weekend prototype the way a solo founder can, because compliance, security, and maintainability are required. You can't just copy the startup playbook.

AI Is Only as Good as What You Put In

Here's something I say a lot: AI is like magic when you're not looking for something specific. Ask it to "build me an app that does this" with no particular vision in mind, and you'll be amazed at what comes back. But if you have something specific in mind (and our clients always do), AI will fill in every gap you didn't specify, and the result won't be what you wanted.

The One-Hour App

Which brings me to my experiment. I wanted to build an internal tool to help manage certifications for our engineers. First, I tried one of the popular AI coding plugins that promise to take you from a rough prompt to a finished app.

To its credit, the experience started out impressive. I gave it a loose prompt, and it came back with clarifying questions. Some covered details I'd left out, and some raised things I hadn't even considered. It offered design options to choose from. Then it churned for about an hour and produced roughly 8,000 lines of code.

Then I tried to run it. The build failed. I fixed that, deployed it, and it still didn't work. I needed to set up identity, then make more changes, then fix more issues. When I finally got it running, it wasn't what I wanted. Three or four days of prompting later, I realized the changes I needed would touch everything about the app. The hour is just the down payment.

The One-Week App

I started over using our approach. I worked with AI to build a proper backlog, loaded it into Azure DevOps, and ran it through our agentic workflow, story by story. A week later, in between meetings, I demoed a working application.

And not just an app running on my laptop. It built the pipeline and infrastructure as code to deploy into a real Azure environment. With each story completion, it ran through the quality gates and deployed through the pipeline. I reviewed the output after each one, so by the time it was done, I knew exactly what I had and I trusted it.

Is a week slower than an hour? Sure. But that week replaced what would have been two or three months of traditional development, and it produced something enterprise-ready instead of a prototype with a pile of hidden costs. When people get excited about the one-hour promise, they are missing the hidden costs. One week, done right, wins every time for me.

Where Vibe Coding Actually Fits

None of this means vibe coding is useless. It's genuinely great for prototypes, personal utilities, validating ideas before you commit, and it's a fantastic demo tool. Instead of a napkin sketch for a client, you can produce a pixel-perfect mockup of a feature in minutes. Where it falls down is exactly where my one-hour app did: production work, where architecture, security, and tech debt aren't things you can politely prompt your way out of later.

Agentic Engineering: Same Workflow, New Team Members

Our answer is what we call agentic engineering: AI agents that actively perform development, testing, and review tasks, coordinating with each other, driven by user stories rather than one-off prompts. I've written before about why we built this on Agile and DevOps. The short version is that AI isn't ready to run without a human in the loop, and the practices that are good for humans turn out to be good for AI too.

What does it look like in practice? Exactly like the workflow a development team runs today. An agent pulls a user story from Azure DevOps, creates a branch, plans the implementation, writes the code, builds and runs end-to-end tests, commits, and opens a pull request. A separate reviewer agent does the first review pass. A human does the final review before anything merges. Swap the agents for people on that diagram and it's the same picture.

The toolkit behind it is surprisingly simple: a set of markdown files, written in plain English, not code:‍

• Agents define the roles: a planner that maps out the work, an implementer that handles development and testing, and are viewer that critiques pull requests. Splitting these into separate agents is the best approach, because AI is good at doing one thing and gets worse the more you pile on. It also gives you a built-in separation of duties. 
• Skills teach the agents things they don't know by default, like how to work with Azure DevOps, from field mappings to building work item queries.
• Commands orchestrate the workflow. Our main one, "resolve user story," walks an agent through every step from pulling the story to opening the PR.
• Memory stores progress and key context between stories, which makes runs more reliable and keeps token consumption down to prevent runaway token expense.

And because we're moving faster with more code, code a human hasn't read line by line yet, so DevOps quality gates matter more than ever. Automated scans catch bugs, code smells, and secrets in source code. Automated tests validate behavior. The pull request keeps a human decision at the gate to production.

Measuring What Matters

We've used this on greenfield projects, brownfield codebases (including modernizing a client's legacy Angular application) and mobile development. And to be clear: we still hit the same problems any project hits. Bugs get introduced. Requirements change. Sometimes the user story is missing details; sometimes AI misses the intent. The discipline is handling those through the process, rather than trying to prompt your way out of them.

That process discipline pays off in measurement, too. Because we're running on Agile and DevOps, the same metrics still work: velocity tells us how far along we are even when we're moving faster, code quality trends tell us whether we're quietly accumulating debt, and bug escape rate tells us whether problems are reaching production.

In addition to the traditional metrics, AI development introduces new constraints.  The metrics that matter should focus on trust, rework, and where the constraint has moved. These AI-specific metrics include:

• Cost per story (Overall economic) : The developer's review time plus the token cost should be less than what the story would have cost to develop manually. If it isn't, we should go back to manual development. That's the whole test.
• Review time (Constraint): This is where the constraint has moved and is worth measuring separately from just within the cost. What is the review time / story? How many stories are in review state?
• Acceptance rate (Trust): % of agent generated changes merged without material human rewrite
• Human turns per completed story(Rework/Trust): How many attempts it takes to get done.
• AI backlog growth (Rework): How many follow-up stories are we creating to correct or complete AI's work?

What's Next

Our agentic engineering workflow and tools continue to evolve as AI changes. We're constantly inspecting our process to improve quality and efficiency.  We are working on making the process more token efficient by improving skills and utilizing local models, building self-improvement into the workflow so AI reviews its own performance after each story, and extending these patterns to data and analytics work. The most interesting frontier might be the product owner: when the development side speeds up this much, the bottleneck moves to defining and feeding the work, so agentic workflows for planning and backlog management are next on the list.

The one-hour app makes a great headline. The one-week app makes it to production. If your organization is trying to figure out how to get real value from AI development, with the quality, security, and predictability enterprise software demands, that's exactly the journey we're on, and we'd love to help you take it.