What an AI-First Feature Build Looks Like From the Inside

Many talk about going AI-first or building an AI-first feature, but we’re doing it.

In practice, it’s messier and more interesting than most acknowledge.

Right now, our team is working through an AI-first feature. It’s not a proof-of-concept or experiment, but a real feature with delivery commitments. This process clarified often glossed-over topics when discussing AI in software development, specifically: The technology is capable; the hard part is everything else.

The process habits that don’t want to change

The first thing we ran into wasn’t a technical problem. It was a habit problem.

Teams build up layers of process over the years. They follow a specific structure for how stories are written, who needs to be in the room, and what “done” looks like. Those structures that were created worked well enough and for so long that they stopped being deliberate choices and became reflexes.

I like to think of it as SDLC rust. It’s just processes that have been caked on for so long that, when something comes in and hammers them, saying, “nope, now you can do it another way,” people need time to adjust, even when they genuinely want to change immediately.

And that’s where we are now. AI hammers at the fundamentals, and it hits hard.

For teams with a lot of accumulated rust, it can be very disorienting when you try to knock it off and expect the system to work immediately.

You can’t mandate “AI-first” and expect people to instantly rewire their thinking about the SDLC. The change needs to happen, but it’s gradual, and pretending otherwise sets teams up to feel like they’re failing when they’re just adjusting. As we started navigating this, we found our process for documenting new features was changing, too.

How we’re building the PRD with AI  

One of the most concrete changes in how we’re working is how we define and document what we’re building. Before we started this process, there was no formal PRD. Instead, BAs would jump on calls with Product, trying to compile the ask and translate it into user stories, all while referencing a scattered mix of documents, specs, and artifacts that, together, described the feature being built.

It was decentralized, and creating a shared understanding before coding meant a lot of back-and-forth, context-switching, and reliance on tribal knowledge.

The problem with that model isn’t the intent. It’s variability. You have people in that room with very different levels of domain knowledge, all trying to converge simultaneously, while half of them are multitasking. The output reflects that. And the cost in time, in scheduling overhead, in contractor hours add up fast.

To address these challenges in alignment and documentation, we’ve moved to a different model.

The product owner sits down and has a direct conversation with AI. They spend time answering questions, refining the scope, and surfacing edge cases, and it is from this dialogue that the PRD emerges.

With this process, you go from ten people in a meeting to one person in a focused working session. The resulting document is more coherent. It shows a single, continuous train of thought rather than multiple people seeking alignment.

The PRD is faster, cheaper, and yields a cleaner document. But it isn’t finished the moment it’s approved.”

Gaps do happen. The question is how you handle them.

A skillfully crafted AI-assisted PRD will still have gaps. We expected this, but building a feature using this process made it clear. Even with thorough planning, you can hit implementation and find something missed or assumed.

That’s not a process failure, just the nature of complex software. The goal isn’t to eliminate gaps, but to have a solid process for feeding them back into the PRD as they appear.

What we’ve been building to identify and find these gaps is a feedback loop. When a developer hits a gap during implementation, instead of resolving it informally or making a snap judgment, we use AI tooling to generate a structured ticket. The ticket describes the gap:

• What was expected?
• What’s missing?
• What decision needs to be made?

That ticket goes to the BA or product owner, is evaluated, and, if valid, folds back into the PRD.

The PRD remains accurate throughout development, rather than becoming outdated. This might sound like a small detail, but it’s one of the more important process improvements we’ve made.

Watch out for when AI gets confident about the wrong thing.

Here’s something we ran into that I think every team working this way needs to be prepared for.

AI is great at reading a codebase and creating implementation plans. But when it lacks information about your specific system, it might propose the wrong solution with full confidence. It might fill in gaps based on general patterns rather than signaling uncertainty.

We had a situation in which our system had an established approach to record auditing. It wasn’t specifically documented in the context we’d given the AI. So, when that requirement came up, the AI proposed building a set of new tables and columns to handle it.

But that implementation would be completely redundant with what already existed. If someone without deep knowledge of the system had accepted that output, we would have caused considerable technical debt under the impression we were solving a problem.

The fix isn’t better AI. It’s a better context and a developer who knows the domain well enough to catch what the AI doesn’t.”

Building context is unglamorous work, especially in large codebases that were not originally designed for AI-first development. Documenting these key elements is what separates teams that get true value from AI from those that produce polished but sometimes wrong code.

Takeaways from using AI on a real product

A few things I’ve noticed as we’ve worked through this:

Developers are now asked to own the feature end-to-end, not just coding, but understanding. In AI-first development, you need to clearly describe the business problem for AI and critically evaluate its output.

That requires a deeper understanding of the domain. The developers on our team who are picking up this new process best are the ones who have always treated business knowledge as part of their job. The ones who haven’t been are finding this transition harder.

We’re still figuring out developer speed, QA testing, and maintaining quality. AI-assisted development boosts output, but QA still operates at a human pace. We’ve had to add deliberate pauses so developers can collaborate with QA instead of just producing more.

This isn’t necessarily a bad thing. Pausing can help align the direction of a feature across different roles, which helps maintain the accuracy of our outcome. But we are seeing developers take on more in this process, which leaves roles like Scrum Masters trying to shift where their value is used in the SDLC.

What I’d tell a team starting this tomorrow

Don’t expect perfection, expect collaboration.

You’re going to be changing the engine while the car is moving, because that’s the reality of how technology shifts happen inside organizations with real roadmaps and real commitments. Build grace periods into your process. Build feedback loops. Design for gaps rather than hoping they won’t appear.  We all need to wear multiple hats to make a feature a reality.

Invest in context before you invest in tooling. The AI is only as useful as the information you give it about how your system works and what your business needs. That documentation work is foundational, and only your team can do it.

Put your domain knowledge where it matters most. The developers who know the business as well as they know the code are your most valuable people in this model. Make sure they’re the ones guiding the AI, not the ones watching from the side.

These key takeaways are forming our approach. We’re still figuring this out and that’s the most honest thing I can say. But we’re learning fast, and our lessons are worth sharing.