At the end of Part 2, Read the Output, I wrote that the tools really were configured now.
Probably.
That word is doing more work than I realized.
I can access the repository. I can authenticate into Google Cloud. I can deploy. I am getting more comfortable working with my XO. But the Final Mile is teaching me that being able to start the work and being able to guide it all the way to the finish are two different things.
The name almost makes it sound simple. Final Mile. The application has been built. The requirements have been translated. The hard part must be over, right?
Not exactly.
This is where the application, the cloud environment, deployment behavior, testing instructions, task files, steering files, and the AI crew all have to agree on what 'done' actually means.
AI can execute quickly, but the Final Mile still requires active direction.
The Final Mile Sounds Smaller Than It Is
Once the XO starts working, it can move fast. It can inspect the repository, change files, run tests, review logs, and investigate failures. That speed is useful, but it creates a new responsibility for me: keeping the work pointed at the original objective.
A failed check can lead to another investigation. That investigation can lead to a configuration file, which can lead into application code. In my session, that was not random wandering. Kiro's coding-assistant defaults kept nudging the XO toward code-first and local-development paths. Those are reasonable defaults for many development workflows; they just were not the boundaries of this Final Mile.
That is why this is even more important at the start of the Final Mile, Episode 1. The specifications, /tasks folder, and steering files are supposed to establish the route before the code becomes the answer.
The AI is very capable of solving a problem. My job is to make sure it keeps solving the problem I gave it.
I am learning that direction is not something I provide once at the beginning and never again. The Final Mile is not about hand-holding the AI; it is the discipline that keeps fast execution aligned to the specifications, the intended environment, and the acceptance point we are trying to prove.
Cloud Means Cloud
One of the clearest examples came from testing. The objective was to validate the deployed application in the cloud, not locally and not against a substitute environment that happened to be easier for the AI to reach.
The distinction mattered because coding assistants are commonly optimized around local development workflows. When the target is a cloud-deployed application, that default can pull the XO toward a convenient answer that does not prove the deployed system. Local testing can still be useful during development, but it does not answer the same question.
Passing a local test does not prove that the thing I am preparing to release works.
So, I found myself redirecting the work: stay in the cloud. Test the deployed application. Validate the environment that matters.
That is becoming an important part of AI-assisted testing for me. 'The test passed' is not enough. I need to know what was tested, where it was tested, and whether that result truly proves the requirement in the environment that will be used.
The Instructions Around the Application Matter
Another lesson came from files that can look like supporting material: how_to_test, start.sh, and deploy.bat. These files cannot simply exist. They must communicate the right process and work in synchrony with each other.
We use specific templates for a reason. A generic file may technically work and still be a poor instruction set for the next person - or the next AI - trying to use the application.
The start.sh file gave me the best example. During the session, we did not follow the expected template closely enough, or at all for that matter. The startup process did not include the wait time the application needed before the next step continued.
Nothing dramatic broke. The XO simply struggled to get started because it was trying to interact with an application that was not ready yet. It did create a loss of working hours.
The file was not just code. It was part of the instruction set.
That changed how I look at these artifacts. If how_to_test is vague, testing becomes vague. If deploy.bat is generic, deployment behavior becomes harder to trust. If start.sh does not reflect how the application really starts, the AI can make a completely reasonable decision at exactly the wrong time.
The same principle applied when database validation was needed. We already had an established cloud proxy path for those checks. The answer was not to let the XO invent another route. It was to use the path we had already defined.
In an AI-assisted workflow, the quality of the automation depends partly on the quality of the instructions and boundaries surrounding it.
When the XO Gets Lost in the Code
The most interesting lesson, though, was about focus.
The XO can read a lot of context: application code, configuration, documentation, task artifacts, and steering files. That is one of the strengths of the workflow. But the coding environment naturally rewards going back to the code, even when the instruction is to look at the specifications first.
During this Final Mile session, I had to keep bringing the work back to the /tasks folder and the steering files. The sequence matters: specifications and steering first, code second. Those artifacts define the assignment, the constraints, and the direction of the work.
There is a difference between reading the code necessary to complete the task and allowing the codebase to redefine the task.
That difference is easy to miss because the XO may still look productive. It can be tracing behavior, reviewing code, or investigating a failure. None of that is inherently wrong. The question is whether the work is still moving toward the acceptance point we started with.
When it is not, the redirection can be simple: go back to the task. Read the steering. Stay in the cloud. Use the established template. Use the proxy. What are we actually trying to prove right now?
Those corrections are not signs that the AI workflow failed. They are the work. The Final Mile is the guide that keeps a coding assistant's drive to get something working quickly from becoming the definition of done.
Keeping the XO on Course
Part 1 taught me that confidence does not require certainty.
Part 2 taught me to read the output.
This part of the journey is adding another lesson:
Keep the work pointed at the objective.
The Final Mile is daunting because everything starts to matter at the same time. Testing has to happen in the right environment. Supporting files must communicate the right behavior. Established access paths need to be respected. And the XO should remain anchored to the task it was given.
AI can move through that work quickly. Quickly is not the same thing as correctly. That echoes a point Doug Preyna makes in From Vibe Coding to Governed Delivery: “AI-assisted experimentation can move quickly, but speed alone is not enough.”
I am spending less time thinking about how I would manually implement every technical step and more time asking whether the work is still aligned to the requirement, the environment, and the process.
That is beginning to feel like the real discipline of the Final Mile.
The XO can do an incredible amount of the execution. The Final Mile does not exist to slow it down. It exists to keep that speed on course, and my job is to make sure the XO remembers where the ship is supposed to be going.
And the journey continues.
