From Prompting to Process: How AI Is Improving My Workflow Methodology

A few weeks ago, I fell back into a familiar rabbit hole.

I first knew Matt Pocock from the TypeScript world. Then, during a short recess in my master's in computer science, I ran into him again through four or five videos about AI workflows, skills, and how people are starting to structure engineering work around agents instead of treating AI as a bigger autocomplete.

That changed the way I was thinking about my own work.

I was already curious about AI, but those videos pushed me in a more practical direction. Instead of asking, "How do I get better answers from a prompt?", I started asking, "How do I build a workflow that makes the answers more reliable?"

That question led me to build something much more methodical than a collection of prompts.

I started by borrowing, not inventing

One detail I do not want to hide is that I did not start from a blank page.

I began by copying one of the existing skill texts almost verbatim, just to understand the pattern from the inside. A lot of the structure I use today came from studying the Codex skill system closely: what a skill is responsible for, what phase it belongs to, what artifacts it should create, and what it should refuse to do.

From there, I started adapting the idea into my own skills repository. That repository now contains the parts that matter most to me: AGENTS.md, WORKFLOW.md, and reusable skills such as grill-with-docs, to-prd, task-planner, task-runner, tdd, technical-blog-writer, domain-modeling, and project-generation helpers.

The important shift was not originality. It was turning someone else's good pattern into something I could actually run every day in my own projects.

The real improvement is not code generation

The biggest change AI brought to my workflow is not that it writes code faster.

The biggest change is that it pushed me to externalize engineering process.

In my current setup, work is not supposed to begin with "write the feature." It begins with context and structure:

• PROJECT.md explains what the project is and how to work in it.
• CONTEXT.md stores evolving decisions, risks, and domain understanding.
• docs/PRD.md defines what must be true when the work is done.
• docs/TASKS.md breaks that into small, testable, repository-aware steps.
• Implementation is supposed to happen only after those layers exist.

The workflow in my skills/WORKFLOW.md makes that explicit with a fixed sequence:

PROJECT.md -> CONTEXT.md -> grill-with-docs -> to-prd -> task-planner -> tdd

That may sound heavy at first, but the point is not bureaucracy. The point is reducing ambiguity before the model touches the code.

AI is much more useful when it is dropped into a shaped process than when it is asked to improvise from scratch.

AI Backend Factory became my proving ground

The clearest example of this is ai-backend-factory, the repository where I have been testing the methodology against a real backend project. At this stage, it is a backend-only NestJS service that accepts structured generation requests and produces deterministic backend foundations under a fixed local workspace.

That repository is not just a pile of generated ideas. It already has a stable project handbook in PROJECT.md, an evolving memory file in CONTEXT.md, a real docs/PRD.md, a detailed docs/TASKS.md, multiple ADRs, and per-task run notes under docs/task-runs/.

Even more important, those files are not decorative.

The task summaries show the workflow being used incrementally. In the first tasks alone, the project moved through bootstrap and health checks, domain modeling and Prisma persistence, shared core abstractions, and authentication. Each task summary records the same kind of trail I usually lost when working ad hoc:

• what changed
• which files moved
• which tests were added or updated
• which commands ran
• which validations passed
• what decisions were made
• what the next task should be

That is a very different way of working from a single long chat with an AI model.

What I like here is that the AI is not just producing code. It is helping maintain continuity across engineering stages. The repo accumulates memory, not just output.

The session history shows this is becoming a real habit

One reason I wanted to look at my Codex sessions before writing this post is that memory can be flattering. It is easy to tell yourself you are building a disciplined workflow when you are really just jumping between experiments.

The session history gave me a better answer.

Across the burst of work around July 1 and July 2, 2026, I logged:

• 9 sessions in ai-backend-factory
• 11 sessions in skills/orchestration
• 6 sessions in the root skills repository

That matters because it shows repetition.

This was not one inspired experiment and one polished screenshot. It was a sequence of sessions across three layers:

1. the skill system itself
2. a real product repo using the system
3. an orchestration layer trying to automate more of the loop safely

I also found smaller signals that I like a lot. In one ai-backend-factory session, Codex updated CONTEXT.md to define Generation Request before pushing further into implementation. That is exactly the kind of behavior I want: clarify the language, record the decision, then keep going.

It is a small example, but it shows the difference between "use AI to type faster" and "use AI to preserve architectural discipline."

The orchestration idea is the next layer, but not this post

The other repository I have been working on is skills/orchestration. I only want to mention it lightly here because it deserves its own post.

At a high level, that subproject is about pushing the workflow one step further: not just defining skill stages, but running AI-assisted work inside a more guarded execution loop. The current docs describe a task runner that uses a disposable worktree, a container boundary, and patch-based imports back into git history.

I do not want to go deep on that part yet.

For this post, the important point is simpler: once I started treating workflow as an artifact, it became natural to ask whether the workflow itself could also be automated, constrained, and made safer.

That question is probably the next chapter of this whole experiment.

What is actually better now

The improvements I feel right now are practical.

• I lose less context between sessions because the repo carries memory in files instead of depending on my memory or the model's context window.
• I get cleaner handoffs because PRD.md and TASKS.md force the work into explicit steps instead of vague intent.
• I can revisit decisions without rereading entire chat transcripts because CONTEXT.md, ADRs, and task summaries hold the durable parts.
• AI output feels more usable because it is anchored to repository-local rules, not just general training.
• I am starting to treat validation as part of the loop, not as something I remember to do later.

The deeper improvement is psychological.

Before this, AI often felt like a tempting shortcut. Now it feels more like a process amplifier. If the workflow is sloppy, AI amplifies sloppiness. If the workflow is explicit, AI amplifies clarity.

That is a much healthier relationship.

What is still rough

I do not want to pretend this is finished.

A lot of this workflow is still young, and some of it started as imitation. I borrowed heavily from existing skill patterns before I really understood how to shape them for myself. Some parts are probably too verbose. Some parts will need simplification. And I still need to prove that the methodology keeps helping when the projects become larger and messier.

There is also a real trade-off here: too much process can slow down simple work.

So the goal is not to force every task through a giant machine. The goal is to know when structure buys clarity and when it just adds ceremony.

That is why I like keeping the workflow explicit. Once it is written down, I can improve it the same way I improve code.

The thing I am really learning

If I had to compress this whole experiment into one sentence, it would be this:

AI is improving my workflow methodology because it is forcing me to design the workflow itself.

Not just prompts. Not just tools. Not just faster output.

I mean the actual engineering path from idea to context, from context to specification, from specification to task plan, and from task plan to validated implementation.

That is the part I find exciting right now.

The work in skills/, the sessions in Codex, the documentation trail in ai-backend-factory, and even the early orchestration experiments are all pointing to the same conclusion: the most valuable AI workflow is not the one that looks smartest in a demo. It is the one that leaves behind a system you can trust tomorrow.

If that keeps holding up, it will probably change the way I build software for a long time.

Notes

This post is based on my own local workflow artifacts, especially skills/AGENTS.md, skills/WORKFLOW.md, ai-backend-factory/PROJECT.md, ai-backend-factory/CONTEXT.md, ai-backend-factory/docs/PRD.md, ai-backend-factory/docs/TASKS.md, the task summaries under ai-backend-factory/docs/task-runs/, the high-level skills/orchestration/PROJECT.md, and my Codex session history from July 1-2, 2026.