{"slug": "from-prompts-to-pipelines-how-i-use-agentic-coding-as-an-engineering-workflow", "title": "From Prompts to Pipelines: How I Use Agentic Coding as an Engineering Workflow", "summary": "A developer describes using the open-source tool agentic-skills to turn AI-assisted coding into a structured, inspectable engineering workflow. The tool breaks tasks into stages such as requirements, architecture, implementation, checks, review, and pull request creation, with each stage producing artifacts. The developer emphasizes that the config-driven approach makes the process sustainable and repeatable, shifting focus from prompt engineering to pipeline behavior.", "body_md": "I am interested in agentic coding for the same reason I care about good engineering process in general: I want work to move forward in a way that is inspectable, repeatable, and resilient once the task gets messy.\n\nA lot of AI-assisted coding still feels like improvisation. You ask for something, get a result, adjust the prompt, try again, and hope the useful reasoning is still somewhere in the scrollback. That can work for tiny edits. It gets much less convincing when the task starts touching architecture, tests, review, or pull requests.\n\nWhat I want instead is a workflow where the model helps me think and execute, but inside a structure I can inspect afterwards. I want artifacts, gates, and something I can resume tomorrow without reconstructing the entire mental state from memory.\n\nThat is why I use [po8rewq/agentic-skills](https://github.com/po8rewq/agentic-skills).\n\nIt gives me a practical way to do agentic coding as an engineering workflow rather than as a long sequence of chat turns. A task moves through requirements, architecture, implementation, checks, review, and pull request creation. Each stage leaves something I can read, verify, and challenge.\n\nThe interesting part is not just that there is a CLI. Plenty of tools have a CLI.\n\nWhat matters to me is that it turns AI-assisted coding into a staged system:\n\nThat changes the feel of the work quite a bit. Instead of asking \"what should I prompt next?\", I am usually asking \"what stage is this task in, and what should exist before I move on?\"\n\nWhere this really clicked for me was when I noticed I was spending less energy trying to preserve context in my head and more energy evaluating actual outputs.\n\nThe repository itself is fairly small and opinionated in a good way:\n\n`agentic/`\n\ncontains the Python package and CLI entry points`pipelines/`\n\ncontains definitions such as `default.yaml`\n\n, `cheap.yaml`\n\n, and `production.yaml`\n\n`skills/`\n\ncontains the Markdown instructions used by each stage`templates/`\n\nand `scripts/`\n\ncontain setup helpersI like that the shared repository stays centralized while each project keeps only the parts that should be project-specific.\n\nIn the target repository, I usually only need:\n\n`agentic.yaml`\n\n`.ai/skills/`\n\n`.ai/context/`\n\n`.ai/memory/`\n\nThat separation is one of the reasons the workflow feels sustainable. The orchestration logic lives in one place, while each repository keeps its own commands, context, and operating rules.\n\nWhat surprised me is how much this small separation changes the feel of the system. It stops feeling like a clever demo and starts feeling like something I can keep around.\n\nThe config is not just setup. It is the part that tells the pipeline how to behave: which provider to use, which commands to run, when to ask for approval, what context to load, and how the task should progress from one stage to the next.\n\nA very small `agentic.yaml`\n\ncan already show the idea:\n\n```\nproject:\n  name: my-api\n  default_branch: main\nproviders:\n  default: claude-code\n  available:\n    claude-code: {command: claude}\nforge:\n  provider: github\n  create_pr: true\ncommands:\n  install: pnpm install\n  lint: pnpm lint\n  typecheck: pnpm typecheck\n  test: pnpm test\n  build: pnpm build\n```\n\nThat is obviously not a full production config, but it already makes the model operate inside a real engineering boundary. It knows which provider to call, which repo commands count as checks, what the main branch is, and whether it should prepare a PR at the end.\n\nFrom there I usually add the pieces that make the workflow more serious:\n\nOnce that file exists, I stop thinking in terms of isolated prompts and start thinking in terms of pipeline behavior.\n\nThe part I did not expect is that a boring config file would do so much work. It quietly turns \"use an AI assistant here\" into an operating model with boundaries.\n\nThe setup is intentionally boring, which is part of the appeal.\n\nI install the shared package from [po8rewq/agentic-skills](https://github.com/po8rewq/agentic-skills):\n\n```\ncd /path/to/agentic-skills\npython3 -m venv .venv\nsource .venv/bin/activate\npython3 -m pip install --upgrade pip setuptools\npython3 -m pip install -e .\n```\n\nThat gives me three commands:\n\n```\nrun-pipeline\nvalidate-agentic-config\ninstall-agentic-skills\n```\n\nIn the target project, I copy the example config:\n\n```\ncp /path/to/agentic-skills/agentic.example.yaml /path/to/project/agentic.yaml\n```\n\nThen I install the shared skills:\n\n```\ninstall-agentic-skills --source /path/to/agentic-skills/skills .ai/skills\n```\n\nFor starter repo context and memory files:\n\n```\ninstall-agentic-skills --with-context --with-memory .ai/skills\n```\n\nAt that point, the workflow is ready to try on a real task.\n\nThe easiest way to understand the workflow is to run a tiny change through it.\n\nTake a small but real task like: \"Add audit logging to endpoint X.\"\n\nBefore I worked this way, that kind of task usually turned into a loose sequence of prompts and manual checks. I would explain the endpoint, ask for a plan, ask for an implementation, remember to think about logging format, wonder whether I had missed a migration or config update, run tests manually, and then do a separate cleanup pass before opening a PR.\n\nWith the pipeline, the same task becomes much more structured:\n\n| Before | With the pipeline |\n|---|---|\n| I describe the task in chat and keep refining the prompt. | I start with a task and let the pipeline create explicit requirements. |\n| Architecture concerns stay in my head unless I stop and write them down. | Architecture is a stage, so affected modules, risks, and planned files get written down early. |\n| Implementation can drift because the prompt keeps changing. | Implementation happens against the requirements and design artifacts. |\n| Checks are easy to postpone or do inconsistently. | Lint, typecheck, test, and build are part of the flow. |\n| Review often happens informally after the code already feels \"done.\" | Review is a first-class stage with artifacts and follow-up fixes. |\n| If I get interrupted, I have to reconstruct context from chat history and git diff. | I can resume from the saved run artifacts under `.ai/runs/` . |\n\nThat is the practical difference I care about most. The pipeline does not just help me write code faster. It keeps the task legible while it moves.\n\nOn a task like \"Add audit logging to endpoint X\", that usually means I get something concrete from each stage:\n\nThat is the part I find reassuring. Even on a small task, the workflow leaves behind enough structure that I can inspect the reasoning instead of just trusting the final diff.\n\nI usually start with a dry run:\n\n```\nrun-pipeline --dry-run --skip-approval --task \"Preview the workflow\"\n```\n\nThat gives me a quick read on the configuration, the stage order, and the prompts without committing to actual work.\n\nThen I try something intentionally small:\n\n```\nrun-pipeline --pipeline cheap --task \"Fix a typo in the README\"\n```\n\nI like using a trivial task first because it teaches the workflow without forcing me to debug a complex change and a new process at the same time.\n\nEvery run is stored under `.ai/runs/<timestamp>-<task>/`\n\n. That directory is one of the biggest reasons I like this approach. It keeps the merged config snapshot, prompts, provider outputs, command results, state, and pull request context.\n\nIf a run stops halfway through, I can resume it:\n\n```\nrun-pipeline --resume .ai/runs/2026-07-07-add-audit-logging\n```\n\nThat sounds like a small detail, but it changes the experience a lot. Interruptions stop being destructive.\n\nThat was another moment where it clicked for me. Resumability sounds like a convenience until you use it on a real week with meetings, interruptions, and half-finished thoughts.\n\nThe default pipeline is intentionally linear:\n\nThat linearity is not a limitation. It is what gives the workflow its shape.\n\nMore importantly, each stage leaves behind a different kind of output:\n\nLater stages only happen if earlier stages are in a good enough state. That is what makes the pipeline feel real to me. It is not just a sequence of labels. It is a sequence of concrete outputs.\n\nThat is the part I find compelling. I do not need to invent a new ritual every time I want to use AI on a real software task.\n\nI reach for this style of agentic coding when I want a task to be:\n\nIt is especially useful when a change benefits from a requirements pass before implementation, or when I want review and PR creation to happen inside the same flow instead of as separate manual cleanup steps.\n\nIn practice, I think this works best for solo developers or small teams doing backend, infrastructure, platform, or full-stack work where a task touches multiple concerns at once: code, tests, configuration, and review. It is much less compelling for quick edits or highly visual exploratory work where the overhead is larger than the payoff.\n\nThis workflow is not free.\n\nFor trivial tasks, the overhead can be higher than the value. It also requires discipline: if the config, skills, or repo context drift away from reality, the pipeline becomes less useful very quickly.\n\nDebugging pipeline behavior can also be its own kind of work. When a stage produces something weak, the problem might be the prompt, the config, the context files, the model choice, or the task itself. That is more structured than random prompt iteration, but it is still a system you have to maintain.\n\nIt is also not the best fit for highly exploratory work. If I am still figuring out what I even want to build, a staged pipeline can feel premature. I find it most useful once a task is real enough to benefit from explicit requirements, checks, and review.\n\nThe main thing I have learned is that agentic coding gets more useful when it stops feeling like magic.\n\nI do not want an opaque assistant that sometimes writes code and sometimes loses the plot. I want a system that helps with execution while leaving behind enough structure that I can understand what happened, challenge it, and keep moving.\n\nThat is the shift that matters most to me. I no longer think in prompts. I think in stages, artifacts, and decisions.", "url": "https://wpnews.pro/news/from-prompts-to-pipelines-how-i-use-agentic-coding-as-an-engineering-workflow", "canonical_source": "https://dev.to/po8rewq/from-prompts-to-pipelines-how-i-use-agentic-coding-as-an-engineering-workflow-52fh", "published_at": "2026-07-08 21:25:00+00:00", "updated_at": "2026-07-08 21:41:13.394360+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-tools", "ai-products", "mlops"], "entities": ["po8rewq/agentic-skills", "GitHub", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/from-prompts-to-pipelines-how-i-use-agentic-coding-as-an-engineering-workflow", "markdown": "https://wpnews.pro/news/from-prompts-to-pipelines-how-i-use-agentic-coding-as-an-engineering-workflow.md", "text": "https://wpnews.pro/news/from-prompts-to-pipelines-how-i-use-agentic-coding-as-an-engineering-workflow.txt", "jsonld": "https://wpnews.pro/news/from-prompts-to-pipelines-how-i-use-agentic-coding-as-an-engineering-workflow.jsonld"}}