We have all been there. A ticket lands on your desk with a deceptively simple one-line summary: "deploy a new web service to AWS and add jobs to deploy it." What looks like a quick task actually hides a complex web of networks, containers, databases, secrets, CDNs, and workflows. As DevOps engineers, we often keep these dozens of small steps in our heads. That works fine until you get pulled into a call, come back an hour later, and panic because you cannot remember if you secured the database port. If you have ever given a vague estimate like "a day or two" because the task felt too big to measure, this guide is for you.
The Engineerβs Mental Model
javdet, a DevOps lead with about 15 years of experience, breaks down how senior engineers naturally approach these tasks. It starts with collecting context: understanding the project, the existing infrastructure, and the specific tools like AWS and GitHub Actions. Next, the task is outlined into large stages, such as writing infrastructure code and creating resources. These stages are then broken down into basic actionsβediting files, running CLI commands, or making API calls. The critical part is relying on team rules and personal experience to order these actions correctly. Finally, a robust plan must include actions, checks, and a rollback strategy. The rollback plan is often the first thing skipped, but it is essential for safety.
Where the Process Breaks Down
In practice, this mental process fails in three specific ways. First, the action list lives only in your head, so items fall out when you get interrupted. javdet shares a personal horror story about forgetting to add CORS configuration during a cloud migration because it feels so obvious that it never makes it onto any list. Second, checks get skipped under deadline pressure. You might see the site load and assume it works, only to discover a month later that backups were never configured. Third, nobody can accurately estimate the task size until it is broken down. You cannot hand off a mental plan to a colleague if you get sick, and you cannot measure the effort for your team lead.
Automating the Breakdown with nib
To solve this, javdet built nib (Neuro Infrastructure Builder), a tool that uses an LLM agent to replicate the engineerβs planning logic. The tutorial walks through setting up nib using Docker Compose and connecting it to an LLM provider like OpenRouter or OpenAI. The key innovation is using the Model Context Protocol (MCP) to give the agent access to external tools. The guide demonstrates connecting three specific MCP servers: GitHub for repository management, AWS for resource creation, and SearXNG for web search. This setup allows the agent to not just think, but to actually inspect current documentation and interact with the cloud environment.
From Plan to Execution
The tutorial shows how nib handles a real deployment for a demo app with a React frontend and Python backend. The agent first asks clarifying questions, such as whether to use a custom domain or the CloudFront address, and how jobs should trigger. It then generates a Directed Acyclic Graph (DAG) of stages, showing dependencies and parallelizable tasks. The resulting plan includes detailed steps, checks, and a rollback strategy, making the workload visible and estimable. The agent can execute these steps via MCP, creating AWS roles, buckets, and GitHub environments, while reporting back on each action.
Key Takeaways
- Context is King: Before planning, gather info on the project, existing infra, and tool specifics. Much of this often lives only in one person's head.
- Break It Down: Divide tasks into stages, then into atomic actions (CLI, API, UI changes). Dependencies between stages are more important than the list itself.
- Plan for Failure: Always include checks and a rollback plan. Skipping checks is a common failure point that leads to hidden bugs.
- Make Work Visible: Breaking tasks into atomic steps allows for accurate estimation and easy handoff, solving the "how long will it take?" problem.
- Use Agents Wisely: Tools like nib can automate the breakdown and execution, but the engineer must still define the context and rules.
The Bottom Line
Stop keeping your infrastructure plans in your head. If you canβt hand it off, you canβt measure it. Tools like nib prove that automating the *planning* phase is just as critical as automating the deployment itself.