Paths
Paths
Paths are conceptual trajectories. Each one describes a progression from a familiar starting point to a more structured outcome.
These are not step-by-step guides. They do not prescribe tools or timelines. They describe a reasoning sequence: if you start from here, and you follow this line of thinking, you can get there.
The paths are drawn from real work. They reflect decisions I actually made, not theoretical ideals.
Chat → Project
Starting point: a conversation with an AI model. A question, a rough idea, a problem described in natural language.
The trajectory:
Most interactions with AI begin as conversations. You ask something, you get an answer, you refine it. This is useful but fragile. The conversation is ephemeral, the context is implicit, and the output has no structure beyond what the model happened to produce.
The path from chat to project is about making the implicit explicit. It begins when you notice that the conversation keeps returning to the same problem. At that point, the problem deserves a file, not a prompt.
The first structural decision is scope: what does this thing do, and what does it not do. AI is good at generating possibilities but poor at drawing boundaries. That is the human’s job.
The second decision is persistence: where does the output live, and how is it organized. A project has files, names, and a layout. A conversation has none of these.
The third decision is feedback: how do you know if it works. This usually means a test, a deployment, or at minimum a way to run the thing outside the chat window.
Where you arrive: a small, scoped, runnable project that originated from a conversation but no longer depends on it.
Infrastructure → System
Starting point: a piece of infrastructure. A cloud account, a deployment pipeline, a set of provisioned resources.
The trajectory:
Infrastructure alone is not a system. It is a foundation without a building. The distance between “I have a Terraform module” and “I have a working system” is larger than it appears, because the gap is not technical — it is architectural.
The first thing to establish is what the infrastructure is for. Not in general terms, but concretely: what will run on it, who will use it, and what are the failure modes that matter. Infrastructure provisioned without answering these questions tends to be either over-engineered or misaligned with actual needs.
The next step is boundaries. A system has components with defined responsibilities and interfaces between them. Infrastructure supports this, but does not create it. You need to decide where authentication lives, how data flows between services, what is synchronous and what is not.
Then comes observability. A system must be legible to the people who operate it. Logs, metrics, and health checks are not afterthoughts — they are part of the design. If you cannot tell whether the system is working by looking at its outputs, you do not have a system yet.
Where you arrive: infrastructure that serves a coherent purpose, with clear boundaries between components and enough observability to understand its behavior in production.
Workflow → Service
Starting point: a manual workflow. A sequence of steps that a person performs repeatedly, possibly with some scripting or automation.
The trajectory:
Many useful services begin as workflows that someone does by hand. The impulse to automate is natural, but premature automation produces brittle systems. The path from workflow to service requires understanding the workflow deeply before encoding it.
The first question is reliability: what happens when a step fails. In a manual workflow, the human adapts. In a service, failure must be handled explicitly. This is where most naive automation breaks — it assumes the happy path is the only path.
The second question is interface: who or what triggers the workflow, and how does the result get delivered. A manual workflow might start with “I open my laptop and check the spreadsheet.” A service needs a defined entry point and a defined output.
The third question is where AI fits. Not every step benefits from AI involvement. The steps that involve judgment, pattern recognition, or natural language processing are candidates. The steps that involve precise, repeatable computation are not — those belong to deterministic code.
Where you arrive: a reliable, triggered service that encodes a previously manual workflow, with AI applied only where it provides clear value and deterministic logic everywhere else.