ai-assisted-devops, a ten-day syllabus for generative AI in DevOps work

A syllabus in ten directories, not a tool you install

The ai-assisted-devops repository is presented as a ten-day course syllabus for DevOps engineers who want to use generative AI to raise their day-to-day productivity. The description says exactly that, and the repository shape matches: a README that lays out the course, and ten directories named day-1 through day-10 alongside it.

That distinction is the first thing to grasp. There is no package to install, no service to run and no configuration to apply. The Python primary language reflects that the exercises involve writing Python scripts, and the day directories are where that work is meant to live, but the README itself is the course plan rather than a build. The licence field on the repository says Apache-2.0, and the project has no GitHub releases, which fits a repository whose unit of delivery is a lesson rather than an artefact.

The audience is narrow and worth stating precisely. This is aimed at DevOps engineers, and it is written for people who already know what a virtual machine health check, a CI/CD configuration, an AWS VPC or a Kubernetes manifest is. The exercises assume that knowledge and ask the model to produce the artefacts. A reader who is still learning what a Dockerfile is will find the first week thin, and the syllabus does not attempt to fill that gap.

Days one to four, from prompt basics to a local model

Day 1 introduces AI for DevOps, covering why the author argues AI matters so much for the field, an overview of generative AI and large language models without deep theory, and a survey of popular AI tools for DevOps engineers. The hands-on task is concrete: create a GitHub repository containing a bash script that reports the health of a virtual machine by checking parameters such as CPU, disk space and memory, and that also accepts a command line argument named explain, which adds a detailed summary of the health status.

That single task is the course's whole thesis in miniature. The script is ordinary work, the explain argument is where the model earns its place, and the exercise is framed so the repository is a GitHub repo rather than a local folder.

Day 2 is a prompt engineering masterclass, with fundamentals on tokens, temperature and max tokens, techniques covering zero-shot, few-shot, n-shot and chain-of-thought, and structured prompts for DevOps use cases. The listed outputs are AI-generated regex, bash scripts, Terraform and CI/CD configurations. Day 3 moves to running models locally, naming Ollama, LM Studio and GPT4All, and calling models through APIs including OpenAI, Mistral, Llama and Deepseek. The hands-on build is a Dockerfile that calls an Ollama endpoint to generate Docker manifests with the llama3 model, and the challenge asks for Kubernetes manifests from an AI API using the same model.

Day 4 turns to AI-powered shell scripting and CLI automation, using AI to improve bash and Python scripting, with a challenge to generate a shell script that creates an AWS VPC with best practices.

Days five and six, AIOps with the log and metrics caveats

Day 5 introduces AIOps for observability and incident response, including what AIOps is and what it is not, and AI-powered monitoring with enterprise observability platforms. Day 6 continues with an AIOps recap, AI-powered log analysis and anomaly detection in Python, with a demo that uses AI to predict server or application failures from logs.

The structure of these two days is the interesting part. Day 5 leans on the commercial side of observability, the platforms an organisation already pays for, and Day 6 drops to the data side, log analysis and anomaly detection written in Python. The syllabus does not say how the two are connected, and it does not claim that either replaces anything. Whether a prediction demo is anything more than an illustration is left unsaid, which is the honest state of the README.

This is also the point in the course where the reader should be most careful. A model reading logs is doing pattern matching over text, and a model asked to predict a failure will produce a confident answer whether or not the logs contain the signal. The course lists the activities without discussing evaluation, false positives or how anyone would know whether the prediction was right, so treat days five and six as demonstrations of a workflow rather than as a method.

Days seven and eight, agents that read your own documentation

Day 7 covers AI agents for DevOps, explaining what they are and how they work, then having the learner create a first agent in simple steps. The hands-on project is to build something with simple AI agents that performs research and writes a detailed analysis in blog style.

Day 8 is where the course gets specific about tooling. It asks for an AI agent for internal tools and documentation built with CrewAI, under the heading of in-house AI agents, and the exercise is to build an agent that reads internal documentation in PDF form and is trained to answer user queries. That is a different proposition from the research-writing agent of day 7. One talks to a model about the world, the other points a model at documents the organisation already owns.

The second is also the exercise with the sharpest edges. RAG over internal PDFs sounds like a solved problem, and in a controlled setting it is mostly plumbing, but the practical questions of permissioning, stale documents and answers that look authoritative while missing the source are exactly the questions a syllabus should raise. CrewAI is named as the framework, and no other detail is given about the implementation.

Day nine is still marked work in progress

Day 9 is listed as AI for Security and FinOps, cost optimization, and under its topics entry the only content is the single word WIP. The day-9/ directory exists in the repository, but the README gives no outline for it, and nothing elsewhere in the document fills the gap.

That gap matters for anyone planning to teach or take the course as written, and it is easy to miss in a document where every other day has a topic list and a hands-on section. Day 9 was presumably meant to cover AI applied to security work and to cloud cost control, which are substantial topics that deserve more than a placeholder, but the README does not say what was intended.

The honest reading is that this repository is a work in progress with nine days specified and one unfinished. It is worth checking day-9/ directly before committing a schedule around it, since the directory is present even though the outline is not.

Day ten asks for a deployed agent, not a demo

The final day is the capstone. The topics are to build an AI agent, to build an AI agent for a DevOps use case, and to deploy the agent to Kubernetes. The day is titled Capstone Project and Future of AI in DevOps.

Putting the deployment on the last day is the right shape for the syllabus that came before it. Days three and four produced manifests from a model, day eight produced an agent over internal documents, and day ten asks for that agent to run somewhere real, on Kubernetes. The earlier exercises become the prerequisites, and the Kubernetes step becomes the point where a prompt-driven workflow meets an orchestrator that will restart, reschedule and fail over the thing.

What the syllabus does not cover is the part that decides whether such a deployment survives. There is no discussion of prompt handling in production, of model latency as a factor in a health check, of cost per inference, or of what happens when the model returns something that does not parse. The future-facing part of the day title is left as a heading with no content beneath it.

The repository as a whole ends there. The top level holds the README, the licence and the ten day directories, and the last push was on 2026-05-13, which means the outline you read is the outline as it stood on that date.

Editorial conclusion

ai-assisted-devops fits a DevOps engineer or team lead who wants a structured path into using generative AI for day-to-day tasks, and who is happy to supply the videos, the accounts and the infrastructure the exercises assume. It does not fit anyone looking for a runnable tool, a pipeline to adopt, or a reference implementation, because the repository holds a syllabus and not much else. Before you plan a course around it, check day-9/ yourself, since the README marks that day's topics as WIP, and confirm the last push was on 2026-05-13, because a course outline that has not been touched in five months is a starting point rather than a maintained curriculum.

Frequently asked questions

Official sources

1. iam-veeramalla/ai-assisted-devops on GitHub
2. Issues
3. License: Apache-2.0
4. README