Generative AI is now strong enough that dismissing it as a toy no longer makes sense. It is also unreliable enough that trusting it casually is a serious mistake. That leaves technical professionals in an awkward position. The tools are clearly useful, the surrounding discourse is often shallow, and much of the visible adoption sits somewhere between hype and negligence. This course exists for people who want a better way through: one that takes the technology seriously without surrendering standards to it.

A word to my subscribers: if you have been reading my work for the self-hosting content, nothing about that is changing. I will keep writing about self-hosting, keep publishing new pieces, and keep maintaining what is already there. This course is not a pivot. It is an expansion. I have spent enough time working with generative AI in my own engineering practice that I have things worth saying about it, and the gap between what most professionals need and what most available material provides is wide enough to be worth filling. The two topics are not as far apart as they might seem: both are about understanding your tools deeply, running things yourself rather than outsourcing your judgment, and caring about what happens when something breaks at two in the morning. So consider this a second track, not a replacement for the first.

Why this course exists now

Something shifted in the AI conversation over the past two years, and it was not just the models getting better.

The models did get better. Between late 2024 and early 2026, the frontier moved significantly. Reasoning capabilities improved. Context windows expanded. Tool use became more reliable. Coding agents went from clumsy novelties to genuinely useful assistants in constrained workflows. The gap between “impressive demo” and “useful in production” narrowed in real, measurable ways.

But the conversation around these tools did not mature at the same pace. Most of what a working professional encounters is still either breathless enthusiasm or reflexive dismissal. On one side, you get influencers treating every model release as a revolution, promising that software engineers are about to be replaced, and showcasing demos that look stunning for the thirty seconds before someone tries to maintain the output. On the other side, you get experienced engineers who tried ChatGPT once in 2023, got a bad answer, and decided the whole thing was a parlor trick. Neither posture is useful. Neither leads to competent practice.

The real situation is more interesting and more demanding than either camp admits. These systems are genuinely capable of accelerating certain kinds of technical work. They are also genuinely capable of producing confident, polished, subtly wrong output that wastes hours if you do not catch it. They can help you understand unfamiliar codebases faster, draft reasonable implementations of well-specified tasks, and surface patterns you might have missed. They can also hallucinate API signatures, invent plausible but nonexistent library features, and generate code that passes a casual glance but breaks under real conditions.

Working well with these tools requires a kind of judgment that most available guidance does not teach. It requires understanding what the models actually do, where they tend to fail, how to constrain their behavior, how to verify their output, and how to build workflows that get value from them without quietly accumulating technical debt. That is what this course is for.

It is not a survey of products. It is not a prompt collection. It is not a breathless tour of what AI can do if you squint. It is a practical, technically grounded course for people who want to understand generative AI deeply enough to use it well in professional software work.

Who this course is for

The primary audience is software engineers, technical leads, architects, sysadmins, DevOps practitioners, and technically literate professionals who build, maintain, or operate software systems. If your daily work involves code, infrastructure, systems design, or technical decision-making, this course is aimed squarely at you.

You do not need to be an AI specialist. You do not need a background in machine learning. You do not need to have trained a model or written a research paper. What you do need is a working familiarity with the basics of professional software work: you should be comfortable reading code, using a terminal, interacting with APIs, and thinking about systems in terms of inputs, outputs, and failure modes.

The course is also accessible to advanced beginners. If you have been programming for a year or two, understand how web applications or backend services generally work, and are willing to engage with material at a professional level, you will be able to follow the content. Some sections will require you to slow down and revisit concepts. That is fine. The course is written to reward careful reading, not to filter people out.

What unites the intended audience is not a specific job title or experience level. It is a disposition: you want to understand how these systems actually work, you want to use them effectively, and you are not willing to trade rigor for speed.

Who this course is not for

This course is probably not a good fit if what you are looking for is a shortcut. If you want a weekend crash course that turns you into an “AI engineer”, this is not it. If you want a list of magic prompts that will write your code for you, this is not it. If you are mainly interested in generating as much code as possible with as little review as possible, this course will actively frustrate you, because it argues against exactly that approach.

It is also not aimed at researchers working on model architecture, training dynamics, or ML theory. The course covers how models work at the level a practitioner needs, but it does not pretend to be a machine learning textbook. If you want transformer internals at a mathematical level, there are excellent resources for that. This course will point you toward some of them, but it will not try to be one.

Finally, this is not a course about AI philosophy, alignment speculation, or existential risk. Those topics are important. They are also not what a working engineer needs on a Tuesday morning when they are trying to figure out whether to trust an agent’s refactoring suggestion. This course stays close to the practical.

What this course covers

The course is organized into four blocks, plus workshops and appendices.

Block I: Foundations (Parts 1 through 4) covers what these systems are and how to think about them. It maps the generative AI landscape in 2026, explains how large language models actually work, clarifies context windows and memory, and examines reasoning and planning. These parts give you accurate mental models of the technology, not simplified stories that collapse when you push on them.

Block II: Control (Parts 5 through 11) covers how to make these systems usable, reliable, and safe. It moves through prompting as specification, structured outputs, tool use and function calling, retrieval and grounding, evaluation and reliability, cost and performance, and safety and security. This is where the course shifts from understanding the technology to actually constraining its behavior for professional use.

Block III: Engineering Use (Parts 12 through 18) covers how AI fits into real programming work. It addresses the coding tools landscape, understanding large codebases, debugging and diagnosis, refactoring and migrations, agentic coding discipline, teaching the repository, and code review and quality. Each part connects back to the foundational and control concepts and demonstrates how disciplined AI use works in context.

Block IV: Professional Operation (Parts 19 and 20) covers how to use AI at team and system level. It addresses team adoption, governance, internal standards, and culminates in a capstone that walks through building a real AI-enhanced engineering workflow end to end. Individual skill is necessary but not sufficient. This block closes the course by scaling the conversation from one engineer to an organization.

Workshops are interspersed throughout the course. They include a tool comparison lab, a repository-setup lab, a retrieval lab, and a review-pipeline lab. They are practical, hands-on exercises designed to make concepts concrete. They are not optional filler. If you skip them, you will understand the ideas less well than you think.

Appendices provide a shared vocabulary, a vendor-neutral selection framework, operating checklists, and a failure modes reference. They are designed to be consulted as needed rather than read linearly.

The progression is deliberate. Block I gives you the map and the mental models. Block II teaches you to control and constrain the technology. Block III puts that control into practice inside real engineering work. Block IV scales the result from individual competence to team-level discipline. The workshops reinforce each block with hands-on practice, and the appendices give you reusable reference material. You can jump to a specific part if you need it urgently, but the course delivers its full value when read in sequence, because each block assumes the posture and knowledge established by the ones before it.

What this course deliberately does not cover

Knowing what a course excludes is as useful as knowing what it includes, because it tells you where the boundaries of the argument lie.

This course does not teach you linear algebra, calculus, or the mathematical foundations of deep learning. When it explains how models work, it does so at the level of mechanism and mental model, not at the level of gradient computation. If you want that depth, look into dedicated ML courses. You will not need it to use AI tools well, but it will deepen your understanding if you pursue it later.

This course does not do benchmark tourism. It will not spend pages comparing model X to model Y on HumanEval, MMLU, or whatever leaderboard is fashionable this month. Benchmarks have their place, but they are frequently gamed, narrowly scoped, and poorly correlated with real-world task performance. The course cares about what models can do in practice, under real conditions, with real constraints.

This course does not speculate about artificial general intelligence, superintelligence timelines, or whether AI will “replace programmers”. Those conversations generate enormous heat and very little light for someone trying to do useful work today. If the situation changes materially, the course will be updated. For now, it focuses on what exists and what works.

This course does not offer “top 100 prompts for developers” or anything resembling a recipe book. Prompting is covered seriously as a skill, but the goal is to teach you how to think about prompts, not to hand you a collection to copy.

What “AI-enhanced programming” means here

The phrase “AI-enhanced programming” gets used loosely in the industry, so it is worth being precise about what this course means by it.

AI-enhanced programming, as this course defines it, is the practice of using generative AI tools inside disciplined engineering workflows to accelerate understanding, reduce search space, assist with bounded transformations, support structured analysis, and make certain classes of work faster, without removing human responsibility for the outcome.

Every part of that definition matters.

“Inside disciplined engineering workflows” means the AI is not the workflow. It is a tool within a workflow that has its own structure, checks, and review processes. The engineer decides when to use it, what to use it for, how to verify the output, and when to stop.

“Accelerate understanding” means using AI to read, summarize, explain, or map unfamiliar code or systems faster than you could alone. Not to replace understanding, but to get there sooner.

“Reduce search space” means using AI to narrow the set of possibilities you need to consider. When debugging, for instance, an AI assistant might identify three plausible root causes from a stack trace. You still investigate. But you start closer to the answer.

“Assist with bounded transformations” means using AI to perform well-defined changes: renaming, reformatting, translating between languages, migrating API calls, applying a known pattern across files. The key word is “bounded.” The transformation should be specifiable, reviewable, and verifiable.

“Without removing human responsibility” means exactly what it says. If you ship code that an AI wrote, you are responsible for that code. If an AI-assisted refactoring introduces a bug, that is your bug. The AI is not a coworker who takes ownership. It is a tool that produces output you must evaluate.

This definition deliberately excludes a style of work where you paste a vague description into a chat window, accept whatever comes back, and move on. That is not AI-enhanced programming. That is something else.

What “vibe-coding” means, and why the distinction matters

The term “vibe-coding” entered common usage in early 2025, originally coined by Andrej Karpathy in a social media post. As he described it, the idea was to “fully give in to the vibes” when coding with AI, accepting suggestions without fully understanding them, and just seeing if the result works. Karpathy was being somewhat playful, and the practice he described has a legitimate place in exploratory prototyping where the stakes are zero.

The problem is that the term was quickly adopted as a general description of how to work with AI coding tools, and the playfulness was lost. What remained was a practice: generating code through conversational momentum, trusting polished output on the basis of surface appearance, skipping verification, expanding scope casually because the AI made it feel easy, and relying on confidence rather than evidence.

This course uses “vibe-coding” to refer to that broader practice, and it takes a clear position against it in professional contexts. Not because there is anything wrong with experimentation. Not because AI-generated code is inherently bad. But because vibe-coding, in the specific sense described here, systematically undermines the properties that make software reliable.

Here is what characterizes vibe-coding as a failure mode:

Ambiguous task specification. The request to the AI is vague, conversational, and underspecified. Instead of “add input validation to the email field using this regex pattern, returning a 422 with this error schema on failure”, the prompt is “make the form better”. The AI will happily comply. The output will be plausible. Whether it does what you actually needed is a separate question that vibe-coding does not ask.

Unconstrained scope. Because the AI can generate large amounts of code quickly, it becomes tempting to let it do more than you originally intended. A request to fix a bug becomes a refactoring. A refactoring becomes an architecture change. Each step feels smooth. The cumulative result is a large diff that nobody fully understands.

Trust based on surface quality. LLM output is fluent, well-formatted, and often syntactically correct. This makes it easy to assume it is also semantically correct. Vibe-coding exploits this bias. The code looks right, the variable names are sensible, the structure is clean, so it probably works. Except that “probably works” is not a standard any serious engineer would accept from a human colleague, and it should not be accepted from a model either.

Skipped verification. In disciplined practice, generated code is tested, reviewed, and validated against the actual requirement. In vibe-coding, the verification step is compressed or eliminated. If it runs, it ships. If it looks right, it is right. This is where the real damage accumulates, because the kinds of errors LLMs make are exactly the kinds that survive a casual glance: correct structure, wrong logic; valid syntax, invented API; plausible behavior, subtle edge case failure.

Diffused responsibility. When code is generated conversationally and accepted without deep review, it becomes unclear who actually understands what the code does. The engineer did not write it. The AI does not “understand” it in any meaningful sense. The result is code that exists in production but belongs to nobody. This is a maintenance problem, a security problem, and an accountability problem.

The distinction between AI-enhanced programming and vibe-coding is not about how much AI you use. It is about whether the usage is bounded, reviewable, verifiable, and owned. You can use AI heavily and still work with discipline. You can use AI sparingly and still be sloppy. The question is always whether the human in the loop is actually in the loop, or just adjacent to it.

The standard this course keeps applying

Throughout this course, you will encounter the same set of questions applied to different contexts. They form the recurring standard against which every use of AI in this series is measured:

Is the task clear? Can you state, before involving the AI, what you want it to do, what the output should look like, and how you will know if it succeeded? If you cannot, the task is not ready for delegation to a tool that cannot ask you what you meant.

Is the scope bounded? Is the AI being asked to do one well-defined thing, or is it being given a vague directive and allowed to interpret scope on its own? Bounded tasks produce reviewable output. Unbounded tasks produce surprises.

Is the output inspectable? Can you read, understand, and evaluate what the AI produced? If the output is too large, too complex, or too opaque for you to review meaningfully, the workflow is broken regardless of how good the output looks.

Is there evidence and grounding? Is the AI’s output based on something verifiable, or is it generating from patterns alone? Retrieval, documentation, test results, and explicit context all improve grounding. Bare generation without grounding is where hallucination thrives.

Is there validation? Is the output tested? Does it pass the same checks you would apply to human-written code? Does it meet the actual requirement, not just a plausible interpretation of it?

Is there human review? Has a competent person looked at the output with enough attention to catch the kinds of errors AI tends to make? Review is not a rubber stamp. It is the point where human judgment re-enters the process.

Does someone take responsibility? Is there a person who will own this output in production, maintain it, debug it, and answer for it? If the answer is “the AI did it”, the process has failed.

These seven questions are not a checklist you run through once. They are a habit of thinking the course will reinforce in every part, every workshop, and every applied section. If you internalize nothing else from this course, internalize these.

How beginners should read this course

If you are relatively new to programming or to professional software work, this course is still for you, but you should approach it with the right expectations.

Read the parts in order. The structure is deliberate, and later parts assume familiarity with concepts introduced earlier. If Part 2 explains how token prediction works, Part 5 will reference that explanation without repeating it. Skipping around will leave gaps that make later material harder to follow.

Read slowly where you need to. Some parts, particularly those covering context windows, reasoning, evaluation, and structured outputs, deal with concepts that may be unfamiliar. That is not a problem. The course explains them in practical terms, without requiring ML expertise. But they do require attention. If a section feels dense, re-read it before moving on.

Do the workshops. They are designed to make abstract concepts concrete. Reading about prompting is useful. Actually writing prompts, evaluating the output, and iterating on the results is where the learning happens.

Do not be intimidated by the professional tone. The course assumes its readers are intelligent adults. It does not talk down. But it also does not assume you already know everything. When a term or concept appears for the first time, it is explained. When a practice is recommended, the reasoning is given. You are expected to think, not to already know.

One thing to be honest about: if you are a beginner, the temptation to lean heavily on AI tools will be especially strong, and the risks of doing so are especially high. When you do not yet have a strong mental model of how code should work, it is much harder to evaluate whether AI-generated code is correct. This course will help you build that evaluation skill, but it cannot replace the foundational knowledge that comes from writing code yourself, debugging it yourself, and understanding why things break. Use AI to learn faster. Do not use it to skip learning.

How experienced professionals should read this course

If you have been writing software professionally for years, you may be tempted to skip the foundations and jump straight to the applied sections. That is understandable but worth resisting, at least partially.

The foundational parts cover material you may think you already understand, but the framing matters. Many experienced engineers have a working familiarity with LLMs picked up from blog posts, social media, and casual experimentation. That familiarity is often good enough for basic use, but it frequently contains subtle misconceptions that become expensive at scale. Part 3 on context windows, Part 4 on reasoning, and Part 9 on evaluation are particularly worth reading carefully, even if you have been using AI tools for a year or more.

Where experienced professionals typically need the most help is not in understanding the technology but in restructuring their workflows to use it well. It is one thing to know that an LLM can help with code review. It is another to design a review workflow where AI assistance actually improves outcomes without introducing new failure modes. The applied sections in Block III and the governance material in Block IV are where the course addresses this directly.

Be especially honest with yourself about verification habits. Experienced engineers often trust their own judgment enough to skip explicit verification steps, and when the output is AI-generated rather than self-written, that trust becomes misplaced. The code looks like something you might have written. The style is familiar. The structure is reasonable. And so you approve it faster than you should. The course will return to this pattern repeatedly, because it is one of the most common failure modes in experienced practitioners.

The structure of the course

The course is divided into four blocks, supplemented by workshops and appendices.

Part 0: How to use this course, and what “not vibe-coding” actually means
The entry point and course contract. What this course is for, who it is for, and the standard it applies throughout: clarity, bounded scope, inspectability, validation, review, and responsibility.

Block I — Foundations

Part 1: The generative AI landscape in 2026. What actually matters now
A practical map of the current landscape: LLMs, reasoning models, agents, coding tools, retrieval, APIs, and the terms people keep mixing together.

Part 2: How LLMs work — without the math rabbit hole
The mental model professionals need: training, inference, tokens, prediction, sampling, and why fluency is not proof of understanding.

Part 3: Context windows, memory, and why models seem to forget
What context really is, how it differs from training knowledge and product memory, and why more information is not always better.

Part 4: Reasoning, planning, and the illusion of intelligence
Why some AI outputs feel deeply intelligent, where that impression is useful, and where it becomes dangerous.

Block II — Control

Part 5: Prompting for professionals. Specification, not spellcasting
How to turn vague intent into clear, reviewable task instructions instead of relying on prompt folklore.

Part 6: Structured outputs and schemas. Stop asking for “valid json” nicely
How to make model outputs machine-usable, predictable, and far easier to integrate into real systems.

Part 7: Tool use, function calling, and MCP. When models stop just talking
How AI systems become operationally useful by calling tools, touching data, and interacting with real systems.

Part 8: Retrieval, grounding, and file search. Give the model better facts, not bigger mystique
How to use external sources, fresh information, and private documents without pretending the model already knows them.

Part 9: Evaluation, hallucinations, and reliability. If you don’t measure it, you don’t know it
How to test AI workflows, compare changes, and stop confusing memorable demos with dependable performance.

Part 10: Cost, latency, and the economics of context
Why the biggest model and the longest context are often the wrong engineering decision.

Part 11: Security, privacy, and safe deployment for AI systems
How to think about secrets, prompt injection, tool abuse, permissions, and safe operating boundaries.

Block III — AI-enhanced programming

Part 12: The AI coding tools landscape. Chat, IDE, terminal, and cloud agent
Why “AI coding tool” is not one category, and why choosing the wrong class of tool creates bad habits fast.

Part 13: Using AI to understand large and unfamiliar codebases
One of the highest-value use cases in professional software work: faster orientation, subsystem mapping, and legacy code understanding.

Part 14: AI for debugging, diagnosis, and root-cause analysis
How to use AI as a hypothesis engine and investigation partner without turning it into a fake oracle.

Part 15: AI for refactoring, migrations, and test generation
Where AI can deliver real leverage in code transformation work, and where it quietly becomes dangerous.

Part 16: Agentic coding without losing the plot
How to use coding agents for meaningful progress while keeping scope, checkpoints, review, and responsibility under human control.

Part 17: Teaching the tool your repository. Instructions, skills, subagents, and project memory
How to shape AI behavior around a real codebase instead of re-explaining everything from scratch every session.

Part 18: Reviewing AI-written code like a serious engineer
How to review AI-generated code for correctness, robustness, design fit, and hidden weakness.

Block IV — Operating AI professionally

Part 19: Team adoption, governance, and internal standards for AI-assisted engineering
How to keep AI use inside a team from turning into a fragmented mess of private prompts, uneven risk, and weak review habits.

Part 20: Capstone: Designing one real AI-enhanced engineering workflow end to end
A full synthesis of the course into one bounded, inspectable, professionally useful workflow.

Workshops

Workshop A: One task, three tools. ChatGPT/Codex vs Claude Code vs Copilot
A structured comparison of how different coding environments handle the same engineering task.

Workshop B: Writing repository instructions and AI guardrails for a real codebase
How to turn project conventions, boundaries, and workflows into durable guidance that actually improves AI-assisted work.

Workshop C: Build a small retrieval workflow with sources and evals
A compact, practical grounding exercise using retrieval, source references, and a simple evaluation loop.

Workshop D: Designing a safe AI review pipeline for pull requests
How to use AI in code review as structured signal rather than delegated judgment.

Appendices

Appendix A: Practical AI glossary for professionals
A clear reference for the terms used throughout the course.

Appendix B: A vendor-neutral framework for choosing models and tools
A reusable framework for evaluating AI tools by task, risk, workflow fit, and operational reality.

Appendix C: Anti–vibe-coding checklists
Practical checklists for understanding code, changing code, delegating agent work, reviewing outputs, and deciding what not to delegate.

Appendix D: Failure modes catalogue for AI-assisted technical work
A field guide to the recurring ways AI goes wrong in code, reasoning, retrieval, and workflow design.

The order matters. Block I gives you the map and the mental models. Block II teaches you to control and constrain the technology. Block III puts that control into practice. Block IV scales the result to teams and proves the whole approach works end to end. The workshops reinforce each block. You can certainly jump to a specific part if you need it urgently, but the course delivers its full value when read in sequence.

Disciplined AI use vs. vibe-coding

How to read this course

Anti-vibe-coding checklist

Before accepting any AI-generated output into your work, verify:

▫️ I can state what I asked for and why, before I look at the output.
▫️ The scope of what the AI produced matches what I requested, no more, no less.
▫️ I have read the output carefully enough to explain what it does.
▫️ I have checked the output against the actual requirement, not just against whether it looks right.
▫️ Any factual claims, API calls, library references, or external dependencies in the output have been verified.
▫️ The output has been tested at the same standard I would apply to human-written work.
▫️ I am prepared to own and maintain this output as if I wrote it myself.

What the reader should expect by the end

This course will not make you an expert in every AI tool on the market. Tools change quickly, and any course that promises comprehensive tool coverage is either lying or will be outdated within months. What this course provides instead is a durable framework.

By the end, you should be able to evaluate a new AI tool, model, or workflow in terms that matter: what is it actually good at, where does it tend to fail, how do you verify its output, and how does it fit into a disciplined engineering process? You should be able to use LLMs for code understanding, generation, review, and transformation with clear expectations about what they will and will not do well. You should be able to design workflows that get real value from AI assistance without quietly accumulating the kind of technical debt that is easy to create and hard to find. You should be able to have informed conversations with your team about adoption, standards, and risk.

More broadly, you should come away with a working model of how these systems behave, a vocabulary for talking about their strengths and limitations, and a set of habits that keep AI use productive rather than corrosive.

That is a practical outcome, not a dramatic one. This course does not promise transformation. It promises competence. In a landscape full of noise, that is worth more than it sounds.

This course does not assume that AI is magic, and it does not pretend that AI is trivial. It assumes something more demanding and more useful: that these systems are powerful, uneven, increasingly important, and worth understanding properly. The goal is not to become impressed by them. The goal is to become competent around them.