I received the Stage 4 certification rubric on August 18. Thirteen days later, I submitted my package. From the outside, that can look like a two-week project. It wasn’t. The work behind it had been building for years.
I wrote before about earning Stage 4 certification. That post explains the artifacts and the harness I submitted. This series is about what made that short submission window possible, including the team practices and experiments that came before the rubric arrived.
The process came before the prompts
The first picture that comes to mind is a whiteboard. A teammate and I had just been through a team downsizing. We were trying to keep delivering useful work with fewer people, so we mapped the process from stakeholder conversation to sprint review.
We wanted to understand where time went and where rework came from. Stories mattered because they carried what we learned from a conversation into design, implementation, and verification. We marked the places where AI might help, but the map itself came from years of working with people and trying to solve real problems.
The goal was not to automate every box. We wanted better conversations with stakeholders, clearer stories, and prototypes we could show before committing to a full implementation. We talked about using stubbed endpoints so the team could shape the experience with stakeholders while the backend was still being designed. That would let us learn earlier, when changing direction cost less.
I connected that earlier outside-in practice to the modern version in A Year and a Half Without a Database. I also wrote about the repeatable endpoint pattern in Stubbed Endpoints: How We Build UI Before the Backend Exists: the route, authorization, and response contract are real, while the business logic and persistence can wait. That lets the UI call the endpoint and lets the team validate the shape before committing to the full backend.
The outside-in process map that helped us see the work and its handoffs.
That history is part of what I explored in Stories Long Before AI. I don’t want to retell that story here. The useful connection is that AI did not give us a development process. We already had one to examine.
Making the invisible work visible
Later, my teammate and I each wrote down the steps we took from a stakeholder conversation through sprint review. We gave ourselves a short time limit and used sticky notes. The exercise showed us that even people working together carried different assumptions about how the work happened.
Some steps were obvious once someone else named them. Other work was so routine that we had stopped noticing it. Comparing our maps helped us see overlaps, gaps, and choices we had been making in different orders. We could then decide which habits to make reusable across the team.
That mattered again when new teammates joined. Instead of explaining the process repeatedly, I talked through it, drew it, and asked AI to help turn those conversations into a written workflow. The document gave people something they could return to after the meeting, when a step that did not make sense at first started to fit.
Some of the individual tasks already had reusable prompts. Those prompts gradually became skills: one for stories, another for design, tests, or other parts of the work. They were not automatically shared habits just because we had put them in a repository. We had to talk about how we used them, notice where our approaches differed, and decide what we wanted to make repeatable. That team conversation made the skills more useful than a folder of prompts that only their authors understood.
The prompts themselves had started as Markdown files we dragged into a chat when a task came up. We each had ways of doing the work, but sharing the files did not mean we were using each other’s approaches. When the team changed, I needed to explain not only which prompt to use, but where it fit in the larger process. Turning those conversations into a shared workflow helped new teammates see the intent behind the steps, not just the names of the tools.
The AI Maturity Model playlist helped us name the progression we were working through, from individual tasks toward more connected workflows.
A foundation, not a shortcut
When the Stage 4 rubric arrived, I had years of team practice, a shared process, and a growing collection of skills to draw from. That did not mean I had the answer ready. We still had to understand how the pieces should connect, what belonged between them, and where people needed to make decisions.
The bridge from those individual skills to a connected workflow is the subject of Stage 3 to 4: The Arrows on the Workflow Map. The short version is that I was not starting with a blank page. I was starting with work the team had already made visible.
I had described the Stage 3 foundation and its lessons in the series on making the learning visible. This series picks up where that one leaves off. The certification took 13 days to prepare because I could build on habits and tools that were already there. The time was short; the learning was not.
Leave a Reply