Vibe Coding Course in Pune — Build Software with AI Assistants

The honest framing first, because it determines whether everything after it lands. Vibe coding is describing intent in natural language and having a model produce code; it is genuinely transformative for speed and genuinely dangerous when the person driving cannot evaluate the output.

How AI coding assistants actually work — tokens, context windows, why a model confidently invents a method that does not exist, and why it forgets a constraint you set twenty messages ago. The limitations module is taught before the tools, not after, so you meet each failure mode knowing it is expected rather than concluding you prompted badly.

Four tools, hands-on, with their differences made concrete rather than described. Cursor as an AI-native editor with codebase-wide context. Claude Code as a terminal agent that plans and executes multi-step changes. OpenAI Codex and GitHub Copilot for inline completion and chat inside the editor you already use.

You do the same small task in each and compare what came back. The judgement being built is tool selection: inline completion for a known change, an agent for a multi-file feature, and neither for something you have not yet decided the shape of.

Prompting for code is a different discipline from prompting for prose, and the difference is specificity about constraints. A request that omits the framework version, the data shape and the error behaviour gets code that compiles and does the wrong thing.

You learn requirement-based prompting — stating inputs, outputs, edge cases and non-goals before asking for anything — then structured prompting with explicit format and file targets, then iteration: how to correct a wrong answer without starting over, and when starting over is genuinely faster.

Turning an idea into something buildable. The software development lifecycle in brief, then the specific loop this course uses: describe, generate, read, run, correct, commit — with reading placed deliberately before running, because code you execute without reading is code you cannot debug when it fails.

Application planning covers scoping a first version, identifying entities and screens, and writing requirements clear enough that a model produces the right thing. Most bad AI output traces back to a vague requirement rather than a weak model, and this module is where that becomes obvious.

Enough web fundamentals to evaluate what the assistant hands you — HTML structure, CSS layout, and what makes markup semantic — then React components, props and state at the level needed to read a generated component and change it deliberately.

Building UI with AI covers generating components from a description, then the part that matters: reviewing them. Generated interfaces are frequently inaccessible, frequently unresponsive below 400 pixels, and frequently full of state that could have been derived. Forms get their own session because validation is where generated code is most often incomplete.

The server side. What a backend does, how a request becomes a response, and REST as a set of conventions rather than a technology — enough to judge whether a generated endpoint is shaped correctly.

You build CRUD endpoints, then work on the parts assistants habitually skip: input validation, consistent error shapes and correct status codes. A generated API that returns 200 with an error message in the body is the single most common defect in AI backend code, and recognising it is a specific, teachable skill.

Where the data lives, and the decisions that are hard to reverse. Tables, columns, keys and relationships; designing a schema from requirements rather than from whatever the first prompt produced; and normalisation at the level that stops a design collapsing later.

SQL is taught to reading fluency — SELECT, JOIN, WHERE, GROUP BY — specifically so you can evaluate a generated query rather than trust it. AI-assisted query generation is genuinely excellent and genuinely capable of producing something that returns correct results on ten rows and times out on a hundred thousand.

The feature where a generated shortcut becomes a security incident. Authentication — registration, password hashing, sessions and tokens — and authorisation, which is the separate question of what a logged-in user may do.

The distinction is laboured deliberately, because assistants conflate them constantly: generated code that checks whether someone is logged in, and never checks whether this particular user owns the record they just requested. You will be shown that exact bug, in generated code, and asked to find it.

The module that decides whether the rest of the course produces a developer or an operator. Reading an error message properly, tracing a stack trace to the line that actually failed, and forming a hypothesis before changing anything.

Then the failure patterns specific to generated code: methods that do not exist, packages that were never installed, versions that do not match, logic that is subtly inverted, and state that updates in the wrong order. You are given deliberately broken AI output and asked to fix it — which is closer to real AI-assisted work than writing anything from scratch.

Tests are what let you change AI-generated code without fear, and generating them is one of the things assistants do best. Testing fundamentals — what a unit test is, what it proves and what it does not — then generating tests from existing code and from a requirement.

The judgement taught is which generated tests to keep. An assistant will happily produce twenty tests asserting that a getter returns what was set, and none for the edge case that will actually break. Coverage is discussed honestly: it measures what ran, not what was checked.

Reviewing code you did not write is the core competency of AI-assisted development, and it is a skill that transfers to every job you will hold afterwards. Reading generated code systematically rather than skimming for obvious errors; recognising the patterns that mark AI output — over-engineering, unused abstractions, duplicated logic, comments restating the code.

Refactoring covers improving structure without changing behaviour, and using the assistant to do it safely with tests in place. The standard set here is that you should be able to explain every line you ship.

Version control matters more in AI-assisted development than in ordinary development, because an agent can change fifteen files while you are reading the first one. Commits, branches, diffs and reverts — with the diff treated as the primary review surface for anything an agent produced.

GitHub covers repositories, pull requests and a history someone else can follow. The working discipline taught here is committing before you let an agent loose, so that undoing a bad run is one command rather than an afternoon.

Generated code is not secure by default, and the vulnerabilities it introduces are consistent enough to teach as a checklist. Hardcoded secrets and API keys, which assistants produce constantly. Injection through unvalidated input. Missing authorisation. Sensitive data in logs and error messages. Dependencies pulled in without a second thought.

You audit your own generated application against this list and fix what you find. The framing is that the assistant optimises for working code, and secure code is a different target that only you are holding.

Getting it in front of someone. Environments and why the thing that works locally fails in production — configuration, secrets, database connections and build steps. Deploying a frontend, deploying an API, and connecting a hosted database.

The module ends on the checks worth running after a deploy, because an application that is live and broken is worse than one that is not live. This is also the point where the capstone stops being an exercise and becomes a URL you can send someone.

Getting more from the tools once the fundamentals hold. Working across a whole codebase rather than a file; giving an agent a plan and reviewing it before execution; multi-step tasks and knowing when to break them up.

Also the practices that keep long sessions coherent: project rules and context files, keeping the assistant informed of decisions already made, and recognising the point where a session has drifted far enough that a fresh start is cheaper than another correction.