Finding your rhythm is one thing. Learning to navigate the unexpected while keeping that rhythm is another.
In Part 4, Finding the Rhythm, I ended with a thought that felt like a pretty significant milestone in my journey:
“And for the first time, I am starting to feel less like someone learning how to operate the Final Mile... and more like someone learning how to run it.”
Then, in Part 5, we stepped away from my perspective and let the XO tell the story from the other side of the console.
That was an interesting change of perspective. It gave us a look at the same process through the lens of the AI doing much of the execution.
But now it’s time to return to the Captain’s chair.
Because something interesting happens once you start getting comfortable with a process.
You stop worrying quite so much about remembering the next step.
And you start discovering that knowing the next step doesn’t necessarily mean knowing the right decision.
I had found my rhythm.
Now I was learning what happens when reality decides to interrupt it.
The Process Wasn’t the Hard Part Anymore
When I first started working through the Final Mile, practically everything felt like a new experience.
I had to learn the tools, understand the repository, become familiar with the prompts, and figure out how everything fit together.
By Part 4, that had started to change.
I knew how to establish context. I knew how to begin an episode, create the how-to-test documentation, guide the XO through implementation, and work through the deployment and testing cycle.
I was getting comfortable with the routine.
And then the work started becoming more complicated.
Not necessarily because the technology was more difficult, but because the problems weren’t always as straightforward as they initially appeared.
A feature request could sound simple enough.
A user needs to search for something.
A dashboard needs to display information differently.
Someone wants to reduce the number of clicks required to complete a task.
Easy enough, right?
Well, sometimes.
The problem is that a request describing what someone wants doesn’t always explain everything that needs to happen to accomplish it.
And that is where I started recognizing something familiar from my experience as a Business Analyst.
Understanding the request and understanding the requirement are not always the same thing.
A Simple Search Isn’t Always a Simple Search
One experience that brought this into focus involved adding the ability to search for records using a Contract ID.
On the surface, the request seemed straightforward.
Let users search by Contract ID.
That’s it.
Except, as I started working through the details, I realized there was more to consider.
For starters, which Contract ID?
The application had internal identifiers used to manage relationships between records, and it had the actual business-facing contract numbers that users recognized.
Those aren’t necessarily the same thing.
A perfectly functional search could be built against an internal identifier and still be completely useless to someone trying to locate a contract using the number they see in their daily work.
Then there was another question.
Where should the search work?
The application supported multiple roles, and those roles interacted with contract information through different workflows.
A Supply Planner looking for a record wasn’t necessarily using the same screen or underlying data as an Auditor retrieving documents.
Suddenly, “add Contract ID search” wasn’t one isolated change.
It required understanding where contract information existed, how different users interacted with it, and what each search needed to return.
This was the point where my Business Analyst background started feeling especially useful.
I wasn’t trying to determine how every database query should be written.
That was work I could direct the XO to handle.
What I needed to understand was whether we were solving the correct business problem.
Were we searching by the identifier the user actually knew?
Were we covering the workflows where that search was needed?
Were we accidentally expanding the scope into something that had never been requested?
Those questions mattered more than how quickly the code could be generated.
The XO could implement the technical solution.
But I still needed to make sure we were implementing the right solution.
Learning When Not to Do More
Another experience involved an application dashboard displaying Pending Discrepancies.
The issue wasn’t that the information was missing.
The information existed.
The problem was how much effort it took for a user to inspect it.
Users needed a more direct way to see the details of a pending discrepancy without navigating away from the dashboard and working through additional screens.
Again, it sounded straightforward.
Make the pending discrepancy clickable and display its details.
But there was an important distinction.
The objective was to let users inspect a discrepancy, not resolve it.
The application already had an established workflow for completing discrepancy resolution. That workflow wasn’t supposed to change.
So the solution needed to reuse the existing inspection experience while keeping it read-only.
The user should be able to open the details, review the information, close the view, and continue working from the dashboard.
No completion actions.
No unintended changes to the record.
No new shortcut around the established workflow.
This experience reinforced a lesson that I hadn’t fully appreciated when I started this journey.
Sometimes, the challenge isn’t determining what the AI needs to build.
It’s determining what the AI needs to leave alone.
An AI assistant can be extremely helpful when identifying opportunities to improve an application.
But helpful suggestions can also introduce unnecessary changes.
And unnecessary changes can introduce unnecessary risk.
The original problem was that users needed fewer clicks to inspect a record.
The objective wasn’t to redesign the entire discrepancy resolution process.
Keeping that distinction clear helped maintain the boundaries of the work.
When the change was validated in the GCP staging environment, what mattered wasn’t simply that the new inspection view appeared.
It was that users could inspect the information without changing the workflow they were supposed to follow.
That’s a much more meaningful outcome.
The Work Doesn’t Always Happen One Episode at a Time
There was another change in the way I was working that made the process feel different.
I wasn’t always dealing with a single isolated task anymore.
Sometimes there were multiple changes to investigate, separate issues to resolve, and different pieces of work that needed to remain independent until they were ready to come together.
This introduced me to spending more time managing Git branches and worktrees.
And, naturally, Git decided to remind me that I still had plenty to learn.
For anyone unfamiliar with worktrees, think of them as separate working copies of a repository that allow you to work on different branches without constantly switching everything in the same directory.
That sounds convenient.
And it is.
Until you forget which branch you’re on, which version of the application you started from, or whether the work you’re trying to merge was created from the correct starting point.
Ask me how I know.
One of the things I had to become more deliberate about was making sure each piece of work started from the latest appropriate version of the main branch.
Otherwise, you can find yourself with changes that work perfectly well in their own environment but become much more complicated when it’s time to bring everything together.
A successful implementation doesn’t automatically mean a clean integration.
And an organized set of worktrees doesn’t mean much if the work inside them isn’t properly coordinated.
This was a different kind of responsibility from the one I described in Part 4.
The rhythm of an individual episode was becoming familiar.
Now I also had to think about how multiple pieces of work related to one another.
What was ready?
What was still being tested?
Which changes depended on others?
What needed to be merged before the next task could begin?
There was no single magic prompt that eliminated the need to understand those decisions.
The tools helped manage the work.
I still had to manage the bigger picture.
When the Rhythm Gets Interrupted
One of the things I like about having a repeatable process is that it gives me somewhere to return when things don’t go according to plan.
And things don’t always go according to plan.
A deployment can fail because of a cloud configuration issue.
A test can fail because the expected behavior wasn’t clearly defined.
A feature can work in isolation but not behave correctly when another part of the application depends on it.
Or a change that looks completely reasonable can turn out to be solving a slightly different problem from the one the user actually had.
Earlier in this journey, situations like these felt much more disruptive.
I was still learning the process, so every unexpected problem seemed to introduce another unknown.
Now, the routine gives me a starting point.
I can investigate the problem without immediately losing track of the larger objective.
But I’ve also learned that I can’t treat the process like a script that must be followed blindly.
Sometimes the right next step isn’t another deployment.
Sometimes it isn’t another Playwright test.
Sometimes the right next step is to stop and clarify the requirement.
Or revisit the scope.
Or make sure the current branch actually contains the changes I think it contains.
That’s been an important shift in my thinking.
The rhythm gives me consistency. Judgment tells me when the situation requires something different.
And the more comfortable I become with the mechanics, the easier it is to recognize those moments.
Finding My Place in the Process
Something else has become clearer as I’ve continued working through these experiences.
When I first began learning Alchemy SDLC™, I was focused heavily on the technical side of things.
Could I configure the environment?
Could I deploy the application?
Could I understand what the XO was doing?
Could I troubleshoot an error without accidentally making things worse?
Those were legitimate concerns.
But lately, I’ve found myself spending more time thinking about questions that are much closer to the work I’ve already been doing for years as a Business Analyst.
What problem are we trying to solve?
Who is actually going to use this?
What should happen when they do?
What existing functionality needs to remain unchanged?
How will we know that the result meets the requirement?
The difference is that I’m now working much closer to the implementation itself.
Instead of defining a requirement and handing it off for someone else to build, I’m helping guide the work through implementation, testing, and validation.
That doesn’t suddenly make me an expert developer.
And it certainly doesn’t mean I have stopped asking questions.
Trust me, there are still plenty of those.
But it is changing how I think about my role.
I don’t necessarily need to know how to manually implement every solution before I can contribute meaningfully to delivering it.
I need to understand the problem well enough to give the XO clear direction, recognize when the work starts moving outside its intended boundaries, and evaluate whether the result actually solves what we set out to address.
That is starting to feel less like learning an unfamiliar development process and more like applying the skills I already have in a new way.
And that has been a pretty interesting realization.
Getting Comfortable Doesn’t Mean Getting Complacent
I think one of the bigger risks of becoming comfortable with any process is assuming that familiarity automatically means proficiency.
It doesn’t.
Just because I know the sequence of prompts doesn’t mean I’ve considered every requirement.
Just because the XO produces a working change doesn’t mean the scope is correct.
Just because one episode is finished doesn’t mean the next one can safely begin without checking the state of the repository.
And just because I’ve encountered a similar problem before doesn’t mean this one has the same answer.
The confidence I’m developing isn’t coming from believing that everything will work the first time.
It’s coming from knowing that I have a process to follow, a way to investigate what goes wrong, and a better understanding of when I need to challenge what I’m seeing.
I’m also becoming more comfortable telling the XO to stop.
Not because it’s necessarily doing something wrong.
Sometimes it’s doing exactly what I asked.
The problem is that I may not have asked the right question in the first place.
That’s an uncomfortable realization, especially when you’re supposed to be the one providing direction.
But it’s also a useful one.
A good working relationship with AI shouldn’t require pretending that every instruction you provide is perfect.
Sometimes the requirement needs refinement.
Sometimes the approach needs to change.
Sometimes you discover something in the middle of the work that changes your understanding of the problem.
The important part is recognizing that before you turn an incorrect assumption into a finished feature.
A Different Kind of Progress
Looking back at where this journey started, it’s interesting to see how much my concerns have changed.
In Part 1, I was overwhelmed by the tools and the process.
In Part 2, I was learning to pay attention to what those tools were telling me.
In Part 3, I was learning how to keep the XO focused on the objective.
And in Part 4, I finally started feeling comfortable with the rhythm of the Final Mile.
Now, I’m beginning to understand what that familiarity actually makes possible.
I’m not spending nearly as much energy trying to remember which command comes next.
I’m spending more of it thinking about the decisions surrounding the work.
The difference between an internal identifier and the number a user actually recognizes.
The difference between letting someone inspect a record and allowing them to change it.
The difference between finishing an isolated change and integrating that change into a larger application.
These aren’t necessarily the types of problems that make for dramatic technical demonstrations.
But they’re the kinds of decisions that determine whether the software we’re delivering is actually useful.
And that’s where I feel like my perspective is starting to change.
I originally approached the Final Mile as something new I needed to learn how to operate.
Then I began learning how to run it.
Now, I’m starting to understand how to lead the work happening within it.
I’m certainly not claiming to have mastered that responsibility.
There is still plenty of room for mistakes, unexpected problems, and moments when I stare at the screen wondering how I managed to get myself into another Git situation.
But those moments don’t feel quite as intimidating as they once did.
The process is familiar.
The tools are becoming more comfortable.
And the challenges are starting to look less like obstacles to getting through the Final Mile and more like the actual work I came here to learn.
Finding the rhythm was an important milestone.
Learning what to do when reality interrupts it may be the next one.
And the journey continues.
Until the next episode.