Same Process, New Speed: What Building With AI Taught Me

Building with AI changes the speed of delivery. It does not change the fundamentals.

For the past few months, I have been learning, playing and experimenting with AI. I built automations, tested platforms and tools, connected them, compared them and pushed some of the latest ones to their limits. Along the way, a few patterns kept showing up. Some confirmed what years in software delivery taught me. Others surprised me.

Here is what I noticed, and the approach that made the difference.

What I noticed

1. The process is the same. It just runs much faster. Ideation, design, development, testing, release and documentation are all still there, in the same order. What changes is the clock. Work that used to take days or weeks now takes hours or days, depending on complexity. The steps did not disappear, they got compressed.

2. The learning curve is real. It is not as easy as it is often made to look. Getting a quick demo is easy. Building something you can extend and scale over time is a different story. That takes upfront thinking and a clear view of the outcome you expect.

3. Your vision will take a few iterations to stabilise. The first version is rarely the right one. The good news: you get there much faster. AI lets you prototype, adjust, visualise and retest as soon as you spot something to improve. The feedback loop shrinks from a sprint to an afternoon.

4. One person plays the whole scrum team. Product Owner, UI/UX designer, Business Analyst, developer, tester and DevOps engineer. All of these roles land on one desk. That is powerful, and it is also a lot to carry.

5. The bottleneck moves from building to judgement. When building is cheap, the hard part becomes deciding what to build and recognising when the result is right. Speed amplifies everything, including a weak idea or a vague requirement. A fuzzy brief used to cost weeks. Now it costs hours, but you can burn through many more of them.

6. You lose the second pair of eyes. In a team, someone challenges your assumptions in refinement, reviews your code, or questions a design choice. Working alone with AI, that friction is gone. The AI rarely pushes back unless you ask it to. Blind spots stay blind for longer.

What makes it work

1. Hit the ground running and decide fast. Make decisions with the information you have at that moment. You will get the chance to change course. It is easier to build something, even if it proves completely wrong, and fix it step by step than to spend hours designing only to find it cannot be built the way you pictured it.

2. Be pragmatic and define what Done means. There is always a way to improve. The skill is knowing when it is good enough. It is very easy to spend hours in a rabbit hole on a detail that barely affects the result. In agile terms: agree on what Done means for every step, from product definition to design, development, testing and documentation. Then hold yourself to it.

3. Stay alert. When you review the same thing many times in the same hour, you get complacent. Testing standards slip and you start trusting the AI more than you should. That is risky. The AI also degrades over long sessions. It forgets earlier decisions and starts introducing errors, what one of my colleagues calls "session Alzheimer's". There are ways to manage this, but when you are in the flow, it is easy to miss the right moment and let your guard down.

4. Write things down as you go. Keep a short, living brief: the goal, key decisions, constraints and what Done looks like. It helps you, and it is the best fix for session degradation. When a session starts drifting, open a fresh one and hand it the brief. You restart in minutes instead of rebuilding context from memory.

5. Own the quality gate. The AI produces, you decide. Write your acceptance criteria before you ask for the work, then test against them, not against how convincing the output looks. A confident answer is not a correct one.

6. Switch hats on purpose. Wearing six hats at once means none of them gets full attention. Separate the roles in time: an hour as Product Owner to frame the problem, then build, then a dedicated block as tester with fresh eyes. You can also ask the AI to play critic and challenge your plan before you commit to it. It will not replace a human reviewer, but it brings back some of the friction you lost.

What this means for teams

If one person can now cover a whole scrum team for a small build, the question for delivery leaders becomes: what does the team look like for a large one?

• Roles will blend. Expect more generalists who can frame, build and test, supported by specialists for depth.
• Clarity becomes the scarce skill. Strong product thinking and clear acceptance criteria will matter more than raw build capacity.
• Quality practices need to catch up. Reviews, testing standards and Definition of Done were designed for human-paced work. At AI pace, they need to be lighter, more frequent and harder to skip.
• Experience becomes the asset. Knowing what good looks like, spotting a wrong answer and making the right trade-off all come from years of practice. That opens a gap for juniors, who used to learn by doing the very tasks AI now handles. It also raises a bigger question: how do we train people for the roles of the future? That deserves its own article, so I will come back to it.

The fundamentals of delivery still hold. We just need to apply them at a new speed.

Final thought

AI gives you speed. What you do with that speed still depends on clear thinking, good judgement and discipline. Start fast, define Done, stay alert, and keep a human eye on the result.

I would love to hear from you: what have you noticed when building with AI? Which of these points matches your experience, and what would you add?

I publish a new article on transformation, delivery and leadership every week here. For AI, subscribe to Decoded, my monthly newsletter where I decipher the news and what it means for leaders.