The Most Valuable Thing AI Can Do in Your Next Software Project Isn't Writing Code

Let me paint a picture you've probably seen.

A senior VP finally decides enough is enough. Their team has spent the last two years manually copying numbers between three different spreadsheets every Monday morning. One of those spreadsheets contains a pivot table Carol built right before she left and everyone is afraid to touch. For the last two years, this is how several team members start their week. The VP spends a weekend vibe coding with ChatGPT and emerges Monday morning with a link to an app running on their laptop.

It's legitimately impressive — a real dashboard with dropdowns, on-brand colors, and a working filter or two. The VP is excited in a way that's hard not to respect. This person identified a problem, took initiative, and shipped something over a weekend. That's exactly the kind of energy organizations are supposed to encourage.

Then the questions start. "How does it work? Where did you get that data?"

To make the dashboard work, the VP needed to invent some of it. They built a new spreadsheet on top of Carol's, added columns representing data they felt like the company should have, but doesn't. The whole thing is wired together on the VP's laptop with open-source libraries IT has never heard of, let alone evaluated — and the vision is that IT can usher it into QA over the next couple of weeks.

I'm not laughing at the VP. I've been in engineering long enough to know this scenario is almost always the result of a system failing a smart, motivated person. The VP had great instincts. They bravely waded into waters most executives avoid entirely, built something real from scratch over a single weekend, and emerged Monday morning with a working dashboard — which is one of the best things you can say about it.

It's situations like this that had me doing deep-dives into intent for many months. This is what led me to conceptualize Intent-First Development.

AI as a reasoning partner, not a code generator

Most conversations about AI in software development focus on making developers faster — autocomplete at scale, refactoring in seconds, tests generated from existing code. All of it is real and useful. But it leaves something profound on the table: what if the most valuable thing AI can do in a software project isn't write the code at all? What if it's helping non-developers articulate the idea well enough that the code can actually be written?

That's the core of what I want to share. It's a methodology called Intent-First Development (IFD), and what makes it meaningfully different is what it produces.

The output of an IFD session isn't a prototype. It's structured intent.

Here's what that means in practice. Instead of asking an AI to build something, you sit down with it and have a design conversation — and the AI asks the hard questions: What does success look like? Who makes decisions in this workflow today? What happens when the data is wrong? What should this system explicitly never do? What does it need to work alongside in your existing infrastructure? If you've ever been in a good product discovery session, it feels exactly like that — except you can have it on a Tuesday afternoon without scheduling seven people into a conference room.

At the end of the session, you don't have a working app. You have a set of documents — design artifacts that capture not just what should be built, but why: what decisions were made, what constraints shaped those decisions, and what questions still need technical judgment to resolve.

Here's the part that changes everything

Those documents can be handed to a developer. A real one, working in your organization's actual infrastructure, with your tech stack, your security model, your deployment pipeline.

Not "take this prototype and make it production-ready." Not "here's a screenshot of what I built, can you rebuild it properly?" A hand-off that says: here is what this needs to do, here are the constraints I already know about, here are the open questions that need your technical judgment, and here is how we'll know when we're done.

This is what it means to play nicely in a corporate environment. Not just that the deliverable is polished — that it plugs into how organizations build things. Engineering doesn't have to reverse-engineer a prototype. They don't have to infer intent from code that was never meant to survive contact with production. The intent is already documented. They can apply their knowledge of the real internal systems from day one — the real database, the SSO provider, the data pipeline that already exists.

No prototype to throw away. No expectation management about why the VP's app can't just be "deployed." No six-week archaeology project before the real work begins.

Just a clear corpus of intent, produced by the person who understands the problem best, in a form that the people who understand implementation can act on.

Who this opens the door for

This is the exciting part!

There are subject matter experts in every organization who know exactly what needs to be built. They've watched the same broken process run for years. They understand the edge cases, the exceptions, the political landmines. They know where the data lives and why it's messy. They know which stakeholders will push back and why.

What they've never had is a way to turn that knowledge into something an engineering team can build from. Historically, that's been a product manager's job — someone who learns the problem secondhand from the expert and then explains it to engineers. It works, but it takes time, and something always gets lost in translation.

Intent-First Development lets the subject matter expert participate in the design directly. Not by building a prototype. Not by writing user stories in a format they weren't trained for. By having a structured conversation with an AI that knows how to pull the right information out of them — then producing documentation that engineering can pick up and build from.

The product manager still matters enormously: as a guide, a reviewer, a bridge. But the bottleneck moves. The compliance officer who has watched a manual audit process for two years suddenly has a path to get what's in their head into a form that's directly useful to the people who will build it. The product owner who understands the customer's pain better than anyone finally has a way to participate in a design session that doesn't require them to pretend they understand Jira epics.

What I haven't seen before

I've worked with a lot of approaches to bridging business and engineering. Process frameworks from waterfall to SAFe. Discovery/Innovation sprints. Jobs-to-be-done workshops. Story mapping. Most of them are valuable in many different ways. At the end of the day, most of them still require a trained facilitator (or a team of them), a reasonably long runway, and a skilled PM to synthesize the output into something actionable.

Intent-First Development compresses that without cutting corners — because the AI does the facilitation work, and the output is structured documentation rather than someone's synthesis of a whiteboard session that's fading from memory as the meeting is wrapping up.

What's new here is the portability. A VP, a compliance officer, a product manager, a domain expert who has never written a line of code — any of them can have a productive design conversation about a problem they understand deeply, and hand the result to a developer they've never met, working in infrastructure they don't fully understand, and have it land as useful rather than as a problem to be solved before the real work starts.

That capability didn't exist before AI got good enough to ask the right questions.

Frequently Asked Questions

What is the "structured conversation" with AI? Is IFD a specific product you have to buy?

Intent-First Development is a methodology — a defined session structure and set of artifact formats — not a product tied to any specific AI tool or vendor. The article describes using AI to help you shape a system by describing what you intend to do. It will help you surface what success looks like, who makes decisions today, what the system should never do, and what constraints the implementation must work within.

How is this different from a product discovery sprint or a well-run PM-led design session?

It might not be that different at all. A well-run, PM-led discovery session is still a great way to surface intent. Nothing stops a PM (and potentially others) from pulling the meeting transcript and feeding it into a separate AI-assisted session to shape the output into structured design artifacts. One of the things AI changes is the old assumption about who belongs in which role — the same tools that let a domain expert run their own session also let a PM do work that used to require a larger team. What IFD focuses on is the output: not insights and backlog items, but documents specific enough that a developer who wasn't in the room can build from them directly.

Our organization already has product managers who do this work. Does IFD add process on top of what we already do?

It adds upfront capture work — but removes the translation tax that eats PM time on most initiatives. When a subject matter expert can articulate their own intent into a structured corpus before walking into a PM's calendar, the PM isn't spending half the discovery session extracting the basics. They receive documented intent they can digest and refine on their own terms, then connect to the engineering workflow, backlog ceremonies, and organizational priorities where their expertise lives. The bottleneck moves from 'PM extracting intent from a domain expert' to 'PM shaping intent for engineering delivery.' The roles don't disappear. The quality and quantity of what lands in the sprint goes up.

Once we have the design documents, who actually writes the software?

Developers do — either your internal engineering team or an external partner like XTIVIA that's already fluent in the methodology. The thing that changes for developers is what they receive at the start of their work: high-quality, structured design artifacts instead of a prototype to try to reverse-engineer or a verbal description to piece together. Engineering can work against your real stack and real constraints from day one — no archaeology phase before the real work begins, and no ambiguity about what done looks like, because the success criteria live in the same corpus the developer is building from. XTIVIA create the Intent-First Development methodology and offers development services that help you bridge the gap.

Where to go from here

If you want to understand how this works mechanically — the design session structure, the artifact model, the way intent is captured and traced to decisions — we created an "Adopting Intent-First Development" article series that starts with an introduction to Intent-First Development and takes you through different scenarios up to an introduction to Altitude-Gated Design..

Intent-First Development is a methodology developed at XTIVIA.