Journey Through Alchemy SDLC™ (Part 2): Read the Output
August 7, 2026 · Kris Brooks
Final Mile setup, early mistakes, and learning to pay attention to what the tools—and my XO (the first officer)—are actually telling me.
At the end of Journey Through Alchemy SDLC (Part 1): Beginning the Journey, I wrote:
“The setup is complete. The tools are configured. The repository is open. The prompts are still unfamiliar.”
That sentence aged quickly.
The installs were complete.
That, as it turns out, is not quite the same thing as the setup being complete.
Once I started using the Final Mile environment, I began learning the difference between having the required tools installed and having those tools configured, authenticated, connected, and working together correctly.
I also learned something much simpler:
Read the output.
That lesson started before I ever asked my XO to do anything complicated.
It started with Docker.
Installed Does Not Always Mean Ready
The Final Mile setup involves several moving pieces: the local working environment, GitHub, Node.js and npm, Kiro, Google Cloud CLI, Docker, repository access, authentication, and the Away Team configuration.
In Part 1, seeing all of that at once was part of what made the starting point feel overwhelming.
This time, I was past the list.
I was actually trying to use it.
That is when I began discovering all of the little things no checklist can teach you.
For example, if you are installing Docker on Windows and it tells you that you need to install or update Windows Subsystem for Linux (WSL), I have some very technical advice:
Actually follow the directions!
I did not.
I saw the message and apparently decided Future Me could deal with whatever it meant.
Future Me was not appreciative.
Eventually, Docker made it clear that the step I skipped was not exactly optional. I stopped, went back, installed what the Docker documentation had already told me to install, and continued.
Nothing catastrophic happened, and it was an easy problem to fix.
But it was also my first reminder that sometimes the answer is already sitting directly in front of you.
You just have to read it.
And Docker was not the last place I learned that lesson.
Authenticated as the Wrong Me
Eventually, I reached the point where I was ready to deploy.
Or, at least, I thought I was.
The repository was there.
The tools were installed.
Google Cloud CLI was installed.
I had authenticated with Google Cloud.
So I tried to deploy.
And it failed.
My first reaction was probably the same one a lot of people have when a terminal suddenly fills with an error:
What did I break?
Fortunately, I had not broken the application.
The problem was much simpler.
I was logged into Google Cloud with my personal Gmail account.
I had authenticated successfully.
I had simply authenticated as the wrong person.
Figure 1. Authentication succeeded. Unfortunately, I authenticated with an account that had no business deploying to the company cloud environment.
Once I saw the problem, the error made perfect sense.
Of course, my personal Google account did not have permission to deploy resources into a company Google Cloud project.
The Final Mile setup specifically includes authenticating Google Cloud CLI and ensuring the correct project access is available. During my walkthrough, logging into gcloud with the correct organizational account was part of getting the environment ready for deployment.
I had completed the authentication step.
I just had not paid enough attention to who I authenticated as.
That distinction ended up being more useful than the error itself.
The command can be correct while the environment around the command is wrong.
So now, when something fails, I am learning not to immediately assume the code is the problem.
What account am I using?
What project am I connected to?
Am I in the right directory?
Do I have the required permissions?
Those questions can save a lot of unnecessary troubleshooting.
Then I Started Paying More Attention to My XO
The same lesson started carrying over into how I work with the Alchemy SDLC™ Away Team.
In Part 1, the challenge was mostly learning the language.
Episodes.
XO.
The crew.
Make it so.
Director’s Dimension.
Scan for life forms.
Those terms are starting to feel less unusual now that I have seen more of what is happening underneath them.
The XO is not simply responding to a prompt.
Work is happening.
Files can change. Tests can run. Documentation can be updated. Security and diagnostic checks can occur. Git activity can happen. Versions can change.
During my initial walkthrough, I watched the Away Team work through those responsibilities as part of preparing and committing changes.
That creates a temptation I am learning to avoid:
Ask the XO to do something.
Wait for it to finish.
See a successful response.
Move on.
Instead, I am trying to stop and read what it actually tells me.
Read Your XO's Output
A Git commit gave me a good example.
I asked my XO to handle the commit, and the response gave me useful information about what had happened.
Figure 2. When the XO shows its work, read it. When it does not show enough, ask.
That second part matters because the XO does not always give me exactly the same level of detail.
Sometimes the response clearly tells me what changed and what was committed.
Sometimes it gives me a detailed summary of the work.
Other times, some of that information may not be included unless I ask for it.
I am learning not to fill those gaps with assumptions.
If I expected a commit, I can ask whether everything was committed.
If I expected a version update, I can verify that it happened.
If I want to know what changed, I can ask.
If I want to know what remains uncommitted, I can ask that too.
That is especially important because one of the lessons from my initial walkthrough was that even something as simple as a version update can occasionally be missed. The answer was not to abandon the AI workflow and do everything manually. It was to tell the XO what needed to happen and then verify that it actually did.
That distinction is starting to make a lot more sense to me.
The Lesson So Far
Docker told me what it needed.
I did not read closely enough.
Google Cloud told me why my deployment was failing.
I had to stop and understand the environment around the error.
My XO tells me what it has done.
I need to pay attention to that output and notice when something I expected is missing.
Different tools.
Same lesson.
Read what the system is telling you before you move on.
That might sound incredibly basic, but in an AI-assisted workflow, I think it becomes even more important.
Things can happen quickly.
It is easy to focus on the next prompt, the next enhancement, or the next deployment and treat everything scrolling across the screen as background noise.
I am learning that the output is not background noise.
It is how I keep track of the state of the work.
The AI may perform much of the technical execution, but I still need to understand what I asked for, what happened, and whether the result matches what I expected.
That is beginning to feel less like supervising a chatbot and more like actually working with an XO.
I provide direction.
The XO coordinates the work.
And I stay engaged enough to know where we are.
One Step Further Down the Road
In Beginning the Journey, my biggest takeaway was:
Confidence does not require certainty.
I could feel overwhelmed and still move forward.
I still believe that.
This part of the journey has added another lesson:
Moving forward does not mean moving blindly.
The errors are becoming a little less intimidating because I am starting to see them as information.
The XO is becoming easier to work with because I am learning to pay attention to what it actually reports.
And the Final Mile itself is beginning to make more sense because I am no longer just looking at a checklist of tools.
I am seeing how the pieces interact.
So far, I have learned to install the tools.
I have learned to go back and install what the documentation already told me to install.
I have learned that successfully logging into Google Cloud is not particularly useful if I log into the wrong account.
And I have learned that when my XO tells me something is complete, I should understand what complete actually includes.
The tools really are configured now.
Probably.
The prompts are becoming a little less unfamiliar.
And the journey continues.
Figure 3. One lesson at a time.
Notice: All product names are property of their respective owners. All company, product and service names used in this website are for identification purposes only.
About the Author
KB
Kris Brooks
Business Analyst · ACC3 International
Kris Brooks is a Business Analyst at ACC3 International with experience supporting government systems and software delivery. His work focuses on translating operational needs into clear, actionable requirements that help development teams deliver practical capability to end users. With a background in information technology, software engineering, and business analysis, Kris brings a grounded perspective on requirements quality, stakeholder communication, workflow improvement, and mission-focused digital transformation.
View on LinkedInContact Kris Brooks