My development pipeline as a PHP developer - from Jira ticket to production in 15 minutes
VSP-727 appeared in my Jira queue at 9:14 AM. By 9:29, the fix was in production. Here is the pipeline that made that possible - and why I built every piece of it myself.
9:14 AM - The Ticket
VSP-727 dropped into my queue: a validation bypass on ticket status transitions. Medium priority. The kind of bug that is easy to fix but tedious to set up - you need the right branch, a working environment, the database in the right state, and tests that cover the edge case.
In my old workflow, that setup alone would take 20 minutes. Open Jira, read the ticket, create a branch, pull latest, run composer install, wait for migrations, seed the database, start the server. Then start actually working.
In my current workflow, it takes 90 seconds. Here is how.
The Jira Skill
I built a custom skill for my AI coding agent that integrates directly with Jira Cloud. When I start a task, the agent pulls the full ticket context - description, comments, attachments, linked issues. It understands the codebase because of another skill I wrote: a workflow where the agent first reads documentation and the ticket plan before touching code. Claude has a built-in code explorer, but I add structure - memory, rules, and a requirement that for bigger features, the agent attaches documentation and a plan to the ticket before writing a single line.
For VSP-727, the agent identified the relevant files within seconds: a Symfony controller handling status transitions, a validator service, and the associated test file. All from the Jira ticket description.
The Laravel/Symfony Workflow Skill
This is where the dev orchestrator meets the AI agent. My workflow skill automates the entire branch-to-PR pipeline:
Branch creation. The agent creates a branch following our convention: VSP-727-ticket-status-validation-bypass. No typos, no inconsistencies - the Jira ID is always correct because the skill reads it programmatically.
Worktree setup. Instead of switching branches in the main repo, the orchestrator creates an isolated Git worktree on ext4 filesystem. The worktree gets its own directory, its own database instance, its own ports. The main working directory is untouched - I can keep working on something else while the agent handles VSP-727 in parallel.
Environment provisioning. The orchestrator spins up the full environment automatically: Docker services (PostgreSQL, Mailpit), dynamic port allocation, Caddy reverse proxy configuration. Within seconds, the worktree is accessible at vsp-727.webapp.local with the API running on api.vsp-727.webapp.local. The database is migrated and seeded.
Commit conventions. Every commit follows our format: VSP-727 fix: Short description. The agent knows this because it is documented in the workflow skill. No more "fix stuff" commits.
Parallel Work
Here is what makes this powerful: while the agent works on VSP-727 in its worktree, I can be working on VSP-730 in another worktree, or reviewing a PR from a colleague, or even having a different agent tackle VSP-728 simultaneously.
The parallel manager agent orchestrates all of this. It tracks which worktrees are active, which ports are allocated, which branches are merged, and which tests are running. Each worktree is completely isolated - different database, different ports, different local domain.
The Testing Gate
When the agent finishes the implementation, the orchestrator runs the full 9-stage pipeline. But the critical stage is testing. The pre-push hook intercepts the push, spins up the isolated environment one more time, runs PHPUnit and Pest tests, and only allows the push if everything passes.
For VSP-727, the agent wrote the fix AND the test. The test verified that the validation bypass was no longer possible. The pipeline confirmed all existing tests still passed. The push went through clean.
9:29 AM - Done
Fifteen minutes from ticket to merged PR. The breakdown:
- 2 minutes: Agent reads ticket, identifies relevant code, creates branch and worktree
- 5 minutes: Agent implements fix and writes test
- 3 minutes: Full test suite runs via orchestrator pipeline
- 2 minutes: I review the diff, approve the approach
- 3 minutes: PR created, reviewed by second agent (laravel-simplifier), merged
The Tools That Make This Possible
None of this is magic. It is a stack of tools I built and configured over months:
Dev Orchestrator - my CI/CD tool that manages worktrees, Docker services, port allocation, and the 9-stage pipeline.
12 Custom Skills - Jira, Bitbucket, Confluence, Outlook integration, Laravel and Symfony workflow automation, PHP testing, cross-session memory, and a personal assistant that learns project context.
4 Sub-Agents - Parallel manager for multi-worktree orchestration, Laravel simplifier for code quality, code explorer for fast navigation, and research agent for documentation lookup.
Shared Configuration - Every agent and skill shares the same configuration, conventions, and guardrails. Consistent results regardless of which agent handles the task.
What This Means
I am not faster because I type faster or think faster. I am faster because I built a pipeline that eliminates every unnecessary step between "I have a Jira ticket" and "the fix is in production." The AI handles the routine. The orchestrator handles the infrastructure. I handle the judgment calls.
That is not vibe coding. That is engineering.
The best developer pipeline is the one where the developer spends zero time on setup and all of their time on decisions that matter.
