If you are wondering whether AI is enough of a support to feel a difference in how your dev team performs, my answer is that it is here, and you should notice it by a mile. If you don’t, something specific is off - and it is findable. Software still gets built in the same seven steps it always was; what changed is what each of those steps costs. The video above is the full walkthrough; this is the written version, for skimming and for sending to whoever runs your product.
Your team pays for AI tools. Why don’t you feel a difference?
Because the tool alone isn’t the change. AI speeds up the steps of building software, so if a step isn’t really run - precisely and deliberately - there is nothing concrete to speed up. It is a multiplier, and a multiplier works on whatever you feed it.
We see software as built in seven steps, and those steps haven’t changed. Two things about them are new. First, every one of them should be dramatically enhanced by AI today. Second, each is ultimately meant to be taken over by agents later. Here is what changed in each, and one practical thing your team can start doing tomorrow.
1. Strategy: research that used to take days now takes an afternoon
Strategy answers why we are building something, before anyone builds it.
The old way: decisions got made on a hunch or on vague signals - the loudest customer, or the competitor’s last launch. Meaningful research meant days of work or a consultant’s invoice, so mostly it just didn’t happen.
Now the knowledge is on tap. You can have AI research recent trends, the competitive landscape, and what similar products charge; for less than a hundred dollars you get a comprehensive report that would have taken days to prepare. We run these for our own decisions now, not just for clients. It works on the behavior side too - before you dive into the future, you should understand the current state. Open your codebase and ask how to pull numbers on user behavior: what people use and don’t, how they click through the app. That is how you stop guessing what your product does for people and start knowing.
Before the next big feature, do both in one sitting. One research report on the market, one answer on how you’ll measure usage. Half a day, total.
2. Requirements: a clickable prototype instead of a wireframe wait
Requirements is where the idea becomes specific enough to build and to verify. We are building a mobile app where someone can sign up, log in, see a list of products, and order one - that easy.
The old way included prototypes, designs, and week-long design sprints. Meetings, and then more meetings to make sure everyone understood the same thing, because building the wrong thing costs thousands in budget and months in time. And then you waited days for a wireframe.
The new way: capturing requirements doesn’t have to be a post-session effort, because you can collect them as you go. Getting clear on the shape and the visual has never been easier, and nobody waits days for a wireframe or a spec.
Invite an AI assistant to the product meeting. Take the transcript, upload it to Claude, and have it aggregate the notes. Then put those notes into Claude Design - a tool that turns written requirements into a real, clickable design - and describe what you want. You get a clickable prototype within hours. A non-technical, product-aware person can build it, click through it, and correct it in chat, with no design skills needed. When it is right, it goes to the developers as the starting point for the build, converted to code their AI can pick up.
3. Architecture: the options that used to need an enterprise budget
Architecture is the structure underneath the product - how the pieces fit together, and what decides whether the next change is cheap or painful.
The old way: changes here, or any of the more careful patterns, were probably too expensive. Structure got chosen by habit, there was no time for refactoring, and the documentation never got written, because all of it was overhead nobody budgeted for.
Now that overhead is basically free. Diagrams and documentation take minutes and live with the code. Approaches that used to need an enterprise budget are on the table for a regular team, so you can think through options that used to be out of reach: an MVP that integrates with more than one provider, handles real traffic from day one, launches on more than one platform.
You don’t need to know a hundred design patterns by heart, you need to ask the right question. Open the codebase and tell AI: we are building X, we see it potentially going in the direction of Y and Z, can we structure it in a way that supports X now and keeps things open for Y and Z? Then let your senior person judge the trade-offs. The knowledge is free now; the judgment still comes from experience.
4. Coding: quality stopped being a budget question
Coding is writing the software to one shared standard.
The old way: coding was the most hours, the largest team, and the biggest bottleneck. Everything waited on hands and keyboards, and when budgets got tight, quality was the thing to cut - few tests, no documentation.
For us the new way is the obvious one, because AI writes all of our code now, and does it better than us. But the real shift is what that does to quality. Tests and documentation stopped being a budget question, and the big cleanups that used to be a quarter of a roadmap happen at a fraction of the old effort. I have seen a single strong engineer, with AI and a clear process, outperform a team of three or four - at a quality most companies couldn’t afford two years ago.
Write your standards down inside the repository - naming, structure, how much testing ships with each feature. The AI tools read those files and follow them. That is the difference between AI as a faster typist and AI as a consistent team member.
One honest caveat: someone on your team must still understand the code. A codebase nobody holds in their head, at least on some level, is a terrible place to debug. AI writes, but your engineers stay accountable.
5. QA: test automation is close to free
Quality assurance is about catching problems before your customers do.
The old way: test cases and automations existed, but not many teams had the budget to keep them extensive and up to date, so it came down to manual effort. The developer finished, and a tester clicked through the site to confirm nothing broke. Or nobody did, and your customers were the first ones to find out.
The new way is simple. Test cases and automations are close to free, so there is no longer a reason to trade one against the other. Testing the app should be documented and, preferably, not fully performed by a human.
Ask AI to write test automations for your critical paths - sign-up, login, order, payment. Then every time you finish a change, run them and let the robot click through the site to see whether anything broke.
6. Release: releases should be boring
Release is getting the change live safely, predictably, with everyone who needs to know informed.
The old way: in most projects, releases were events. Scheduled after hours, with a manual list of steps if you were fortunate, one person who knew how to run it, and everyone holding their breath until Monday.
The new way enables quick iteration. The automation pipeline that used to need a dedicated specialist now gets built in an afternoon. Releases should be small and frequent - even a few times a day if you want - and the release documentation writes itself: what shipped, when, and why. Releases should be boring, and that is the goal.
Ask AI to build the pipeline and a short smoke-test checklist - the five things that must work after every deploy - and let the automation do the checking.
7. Monitoring: the daily report nobody would have paid for
Monitoring is knowing what is actually happening once the software is live: whether the system is up, and whether the business is working.
The old way was often flying blind. Dashboards were an infrastructure project, so early products skipped them, and you learned about problems from customer emails.
Now the cost of integrations and monitoring is marginal. Have your team expose an endpoint with the application status - signups today, orders today, errors today - and wire those numbers into daily reporting. You probably wouldn’t have paid for eight hours of dev time to send you a daily report on Slack; now it takes about thirty minutes, published through whichever channel you want and customized to whoever reads it. And when something looks off, you can ask questions in plain language instead of digging through dashboards.
One status endpoint, one daily message. That is the whole build.
Seven questions to ask your dev team
One question per step. Take them to your next conversation with your dev team - not as an audit, just out of curiosity. Each answer will tell you a lot about how well that step is handled.
- Strategy - what’s the goal of the thing we’re building right now?
- Requirements - where can I see what we’re building, before it’s built?
- Architecture - which part of the system are we afraid to change?
- Coding - where are our standards written down?
- QA - where do we have our test cases?
- Release - can we deploy to production today?
- Monitoring - what are we alerted about when things fail?
A good team will enjoy these questions. If some of the answers are missing, you just found the step to start with. It is the same standard we put on the buying side in our vendor checklist - these are those questions asked from the inside instead.
AI didn’t replace the discipline. It removed the excuse.
Same seven steps we have always used. Research in hours, prototypes in a day, tests almost free, releases that are boring, and reports that come to you.
That is also the direction this is going. Today AI enhances each step, but over time agents will take over more and more of each one. Teams that run a clear process will hand it over smoothly. Teams that run on instinct will have nothing to hand over.
So send this to your dev team, or whoever runs your product, and ask them one question: which of the seven steps do we start with?