AI in the SDLC – When We Let AI Join Our Team
Picture a small software team. One person defines what the product should do — call her the requirements person. Another builds it — the developer. A third checks that it actually works — the tester. Normally these three work in a relay. The requirements person finishes her part and hands it to the developer. The developer finishes and hands it to the tester. Each handoff takes time, and questions that come up along the way often sit in someone’s inbox for a day before anyone answers them.
This is the story of a single day when our team brought AI assistants into that relay — and what changed as a result.
The morning: we taught the assistants before we asked them to help
Here’s the part that surprises people: we didn’t start by asking the AI to build anything. We spent the first stretch of the morning writing down, in plain instructions, how each role should behave. We described how the requirements person likes to phrase things, what coding conventions the developer follows, and what “done” means to the tester. Think of it like writing a short training manual for a new employee on their first morning, before you give them any real work.
Like any new employee, the AI didn’t get everything right on the first try. So we kept adjusting those instructions throughout the day, correcting course whenever we noticed the AI doing something slightly off. It wasn’t a one-time setup — it was closer to coaching someone in.
This felt like wasted time in the moment. It wasn’t.
Late morning: we handled the first piece of work as a group conversation, not a relay
Once our instructions were in decent shape, we tackled the first small piece of the product. Here’s the difference from the usual relay: the tester didn’t wait for the developer to finish. While the AI developer was still building, the AI tester was already reading the requirements and flagged a question back to the requirements person — mid-build, not after.
We answered that question right away, and the work kept moving. Instead of “finish, hand off, wait, get feedback, fix,” it looked more like three people in the same room, talking as they worked.
Afternoon: the second and third pieces of work went noticeably faster
This is the payoff. The second piece of work — and the third — took less time than the first one had. Why? By then, our “training manual” from that morning was solid. Nobody had to re-explain conventions or renegotiate what “done” looks like. We could ask for the next piece of work and get it back the same day, already checked and tested.
That timing hides the real lesson: the slow start bought us speed later. Every piece of work after the first got cheaper, because we only paid the cost of teaching the assistants once.
By the end of the day: we got more done, not less, as the workload grew
You’d expect things to slow down as the to-do list gets longer. Instead, the opposite happened. We drafted requirements for two more chunks of the product that same day, and we shipped a brand-new feature in the very last update before the day ended. The system didn’t strain under more work. It kept the same rhythm.
The next day: the habit stuck
One team member worked alone the following day. The same pattern showed up again without anyone deliberately restarting it: small steps, each building cleanly on the last, ending in a finished, tested piece of work. Whatever we set up during that first day wasn’t a one-time trick. It kept running on its own.
What this actually shows about AI helping with software work
If you’re not a developer, here’s the plain takeaway:
- The upfront effort isn’t the product — it’s the instructions. Spend time teaching an AI assistant your team’s habits and standards; that’s the real investment. Skip it, and every task will cost as much as the first one did.
- People don’t get replaced. They get closer together. The requirements person, the developer, and the tester stayed three real people making real decisions. What changed is how quickly a question could travel between them — in the middle of the work, instead of at a scheduled meeting.
- Checking the work stops being a separate, later step. Testing happened the same day as building, as a natural part of the process, not a chore we saved for later.
- Coaching the AI is a real, ongoing task — not a one-line request. It’s less like typing a magic instruction and more like training a new team member: you correct it a few times before it fits how your team actually works.
The headline isn’t “AI built our product in a day.” It’s closer to this: we spent an hour explaining our way of working to a new set of hands, and we spent the rest of the day watching that hour pay for itself.