From AI workflows to shipping something real

Most of my practical work with AI has sat close to training and business workflows.

I have designed and demonstrated n8n-based AI workflows in training environments. I have spent a lot of time explaining how business rules become structured inputs, how AI-generated content can be checked against defined criteria, and why human review and approval should remain explicit steps.

That work taught me a great deal about how AI fits into a process. But most of it still lived inside training or demonstration contexts. The workflows ran, participants could see how the pieces fitted together, and the conversation could then move on to what would be needed before operational adoption.

This website is the first thing I have taken from an idea all the way to a public production release.

Demonstrating is not the same as shipping

A workflow demonstration can reasonably stop when it works.

Its purpose is to show a pattern: an input, a sequence of steps, a check, a decision. If the pattern is clear and participants understand it, the demonstration has done its job.

A production product does not stop there. It forces a much longer list of decisions. What is it for, and who is it for? How is it structured? What should it look like? How is it implemented, and where does the source of truth live? How do you know it works before anyone else sees it? Where is it deployed, under which domain, and how will it be maintained after the first release?

None of these questions is unusual on its own. What was new for me was having to answer all of them, in sequence, for the same piece of work.

A personal website turned out to be a useful place to learn that lifecycle. The risk is low, the scope is contained, and the decisions are mine to make. It is not a client project, and it did not need to be. It only needed to be real enough that nothing could be left as “this would happen later.”

How I worked

I started with purpose rather than tooling. Before any design work, I defined who the site was for, what it needed to communicate and how the information should be organised. That produced a small, stable structure: Home, Work, Thinking, About and Contact.

From there I prototyped the site visually before any code was written. Seeing the pages laid out made it much easier to decide what belonged, what was redundant and which content I did not yet have.

Once the design was approved, I converted it into a written production specification. In hindsight, this was the most important step. It described the routes, the content model, the visual rules, the publication rules and the conditions under which the site could be released. It also recorded what was not yet known, instead of allowing those gaps to be filled with assumptions.

The implementation was then carried out with AI coding agents working from that specification. The site is built with Astro, TypeScript and plain CSS, and GitHub became the source of truth and version history for all of it.

From there the work moved through build checks, responsive QA across screen sizes, and publication guards that prevent unapproved content from being released. The site was deployed to Vercel, first as a protected staging environment and then to production. Finally, the domain, DNS and SSL were configured, and the live site was verified at phucpham.vn.

What AI changed

The obvious difference is that I did not need to personally write every implementation detail.

AI reduced the distance between an idea and a working implementation. Something I could describe clearly could usually be attempted, checked and corrected within the same working session.

But my role did not disappear. It shifted.

Most of my effort went into framing the work, making decisions, setting constraints and reviewing what came back. When something failed, I still had to understand enough to decide what the problem actually was and what an acceptable fix looked like. When an agent proposed a change, I still had to decide whether it fitted the specification or quietly widened the scope.

The quality of the result depended heavily on how clear the inputs were. Where the specification was precise and the acceptance criteria were explicit, the output was generally sound. Where something was left vague, the gap tended to reappear later as rework.

That is a familiar lesson from enterprise work. It applies just as much when the implementer is an AI agent.

What I learned about “vibe coding”

The term is used loosely, so I want to be careful with it.

If vibe coding means prompting until something looks right, that was not the useful part of this experience. A site can look finished while still having broken routes, missing metadata, or draft content that should never reach production.

The workflow that held up was more structured:

intent → specification → implementation → test → review → version control → deployment

Each step had a purpose. The specification defined what “done” meant. Tests and checks made it visible when something was not done. Review was where I decided whether to accept a change. Version control made every accepted change recoverable.

Git and GitHub turned out to be more important than I expected. Every meaningful step became a checkpoint I could return to. It also meant that different AI agents, in different sessions, could work on the same project without losing continuity. The repository held the current state, the history and the specification, so each new piece of work started from what had actually been done rather than from someone’s recollection of it.

What this changes for me

I am not repositioning myself as a software engineer.

My core work remains on the business side: enterprise relationships, commercial development and execution. That is where I expect to keep spending most of my time.

What has changed is the depth of my firsthand understanding. I have now taken something tangible from strategy and prototype through specification, implementation, version control, QA, staging, DNS, SSL and production. I know what each of those steps involves, where it tends to go wrong, and what kind of decisions it requires from the person who owns the outcome.

That makes AI-assisted building a developing capability for me, supported by actual production experience rather than only an aspiration. It is a modest claim, but it is a real one.

It also changes how I can take part in conversations about AI adoption. It is easier to speak realistically about the distance between a working demonstration and something that is actually in use after having covered that distance once myself.

Closing thought

The most useful shift is not “AI can write code for me.”

It is that AI increasingly lets someone who understands a business problem participate much further into the building process than before: from defining what should exist, through the decisions that shape it, to seeing it run in production.

That does not remove the need for specialists, or for judgement. But it does change how far the business side can reach into the building side.