Private corporate batches, live online cohorts and 1-on-1 mentoring in prompt structure, evaluation, tool calling, RAG grounding, failure modes and the cost and latency of LLM systems — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches prompt engineering as an engineering discipline rather than a set of tricks: prompts written as instruction, examples and an explicit output contract; evaluation sets built before prompts are tuned so a change can be shown to help rather than assumed to; and regression runs on every prompt or model change. Sessions cover the parts most courses omit — tool and function schemas with argument validation, retrieval design where chunking and reranking decide answer quality more than wording does, prompt injection and data-exfiltration failure modes in tool-using systems, and the token accounting, caching and model-routing decisions that determine whether a working prototype is affordable at production volume.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Prompt Engineering that means a trainer who has run it in production — prompt structure, evaluation, tool calling, RAG grounding, failure modes and the cost and latency of LLM systems — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Prompt Engineering batchPrompt engineering is the practice of designing the input to a large language model so the output is reliable enough to build on. That input is more than a question: it is a system instruction that sets role and constraints, a set of examples that demonstrate the wanted shape, an output contract that the response must satisfy, whatever retrieved context the answer must be grounded in, and the sampling and reasoning settings that govern how the model generates. Getting a good answer once is easy. Getting the same quality across ten thousand varied inputs is the engineering problem.
The scope has widened considerably. A prompt now frequently ships alongside a set of tool definitions the model can call, a retrieval step that grounds the answer in the organisation's own documents, a structured output schema that downstream code parses, and a reasoning or effort setting that trades cost and latency against answer quality. Context windows on frontier models now reach a million tokens, which removes some problems and creates others — cost, latency and the fact that a model can attend to far more irrelevant material than before.
The part that separates practitioners from enthusiasts is evaluation. Prompt engineering without an eval set is guessing: a change that looks better on three hand-picked examples routinely makes things worse across the distribution. Serious work means building a labelled evaluation set, defining a rubric or automated judge, running regressions on every prompt change, and monitoring the same signals in production alongside token cost, latency and failure rate. This course treats prompting as a software discipline with tests, versions and budgets — not as a collection of tricks.
Organisations have moved past the demo stage. The pilot that impressed a steering committee is now expected to run against real customer volume, and the gap between those two states is almost entirely engineering: reproducibility, evaluation, grounding, error handling, cost control and safety. Teams that never built an eval set discover the problem when a model upgrade silently changes behaviour and nobody can tell whether quality went up or down.
The technical surface has also changed under people's feet. Tool calling turned language models into components that act rather than only answer. Retrieval-augmented generation became the default way to ground answers in proprietary content. Structured output constraints made responses parseable. Reasoning and effort controls introduced a real cost-quality dial. Prompt caching changed the economics of long, stable system prompts. None of this was standard practice two years ago.
The demand is for people who can treat an LLM as an unreliable component and engineer around it — writing prompts that fail predictably, retrieving the right context rather than more context, validating tool arguments, measuring quality before shipping, defending against prompt injection, and keeping token cost and latency inside a budget somebody has to sign off.
The mechanics you need before writing anything. Tokens rather than words, the context window and what happens at its edges, next-token prediction, and the sampling settings that control variability. Why the same prompt can produce different answers, why the model is confident when it is wrong, and the message roles — system, user, assistant — that structure every conversation.
Topics: What is prompt engineering and what it is not · Important definitions and key concepts · Tokens, tokenisation and why token counts differ from word counts · Context windows and what happens near the limit · Understanding prompts: inputs, outputs and parameters · Sampling settings and their effect on variability · Understanding the non-deterministic nature of AI · System, user and assistant roles · Reasoning and effort settings as a cost-quality dial · Model families and how to choose one for a task
The anatomy of a prompt that holds up. Instruction, context, examples and output specification as separable parts; delimiters so the model can tell instruction from data; role prompting and nested prompts; zero-shot, few-shot and the example-selection choices that matter more than wording. Then output contracts — schemas and structured outputs — so downstream code never parses prose.
Topics: Crafting simple prompts: techniques and best practices · Instruction, context, examples and output specification · Basic principles for interacting with AI systems · Role prompting and nested prompts · Delimiters and separating instructions from untrusted data · Zero-shot, few-shot and example selection · Output contracts: JSON schemas and structured outputs · Prompt compression techniques and what they cost you · System prompt design for a whole application · Prompt templates, variables and versioning
Getting a model to work through a problem instead of guessing at it. Chain-of-thought prompting, decomposition into steps, self-consistency, and verification passes where a second call checks the first. Then the honest accounting: reasoning modes and effort settings cost tokens and latency, and on many tasks a well-specified prompt beats an expensive reasoning setting.
Topics: Chain-of-thought prompting · Task decomposition and multi-step prompting · Self-consistency and sampling multiple answers · Verification and critique passes · AI-assisted questioning and clarifying ambiguity · Structured ideation and divergent prompting for brainstorming · Reasoning modes and effort settings in current models · When reasoning is worth the tokens and when it is not · Human-AI collaboration: best practices and strategies · Multilingual and multimodal prompting
Measuring whether a prompt is better. Building an evaluation set that represents the real distribution including edge cases, writing a rubric with criteria that can be graded independently, and choosing between exact-match, rubric-based, model-as-judge and pairwise comparison. Then regression testing, so a prompt or model change is evidence-based rather than a hunch.
Topics: Evaluating and refining prompts: an iterative process · Building an evaluation set that reflects reality · Writing gradeable rubrics rather than vague criteria · Exact match, rubric grading and model-as-judge · Pairwise comparison and preference evaluation · Judge bias and how to control for it · Regression suites and running them on every change · Golden datasets, versioning and drift in the eval set itself · Offline evaluation versus online measurement · Human review sampling and inter-rater agreement · Reporting quality to stakeholders honestly
Turning a model from something that answers into something that acts. Tool and function schemas and how the description drives whether the model calls a tool at all; the request–execute–respond loop; parallel tool calls; and argument validation, because a schema is a suggestion until your code enforces it. Then agentic loops with iteration limits, error recovery, approval gates and observability.
Topics: Tool and function definitions and JSON schemas · Writing tool descriptions that drive correct triggering · The tool-call loop: request, execute, return result, continue · Parallel tool calls and returning results correctly · Validating arguments and handling malformed calls · Returning errors so the model can recover rather than loop · Iteration limits, budgets and stop conditions · Approval gates for destructive or irreversible actions · Server-side tools: search, retrieval and code execution · The Model Context Protocol and standardised tool servers · Logging and tracing an agent run for debugging
Answering from your content instead of the model's memory. Why retrieval-augmented generation exists, and where quality is actually decided — chunking strategy, embedding choice, hybrid keyword and vector search, and reranking. Then context assembly, citation so answers are checkable, and the honest handling of the case where retrieval finds nothing relevant.
Topics: Why RAG, and when fine-tuning or long context is better · Chunking strategies and why chunk boundaries decide answers · Embeddings and vector stores · Hybrid search: keyword plus vector · Reranking and why it usually beats retrieving more · Metadata filtering and access-scoped retrieval · Context assembly and ordering within the prompt · Citation and grounding the answer to sources · Handling no relevant results without inventing one · Evaluating retrieval separately from generation · Long context versus retrieval: cost, latency and attention · Refreshing and versioning the index
What goes wrong and how to engineer around it. Hallucination and why grounding reduces but never eliminates it; silent truncation when output limits are hit; unhelpful refusals and how to distinguish them from correct ones. Then the security section that matters most in tool-using systems: prompt injection through retrieved or user content, data exfiltration through tool calls, and the trust boundaries that contain them.
Topics: Hallucination: causes, detection and mitigation · Silent truncation, stop reasons and incomplete output · Refusals: correct, over-cautious and how to handle each · Prompt injection from user input, documents and web content · Indirect injection through retrieved context and tool results · Data exfiltration via tool calls and outbound requests · Trust boundaries and treating model output as untrusted · Least-privilege tool design and human approval · Ensuring fairness and reducing bias · Privacy and data security: PII, retention and residency · Responsible AI and the future of work · Fallback behaviour and graceful degradation · Red-teaming your own prompts
Making a working prototype affordable. Token accounting for input, output and reasoning; prompt caching and the prefix-match rule that decides whether a cache is ever hit; batching for non-interactive work; and streaming for perceived latency. Then model routing — using a smaller model where it suffices — plus versioning, monitoring and rollout for prompts as production artefacts.
Topics: Token accounting: input, output and reasoning tokens · Measuring token usage properly rather than estimating · Prompt caching and prefix matching · What silently invalidates a cache and how to find it · Batch processing for non-interactive workloads · Streaming and perceived latency · Model routing and choosing a smaller model where it suffices · Timeouts, retries, rate limits and backoff · Prompt versioning and staged rollout · Production monitoring: quality, cost, latency and failure rate · Budgets, alerting and cost regression · Handover and documentation for the team that operates it
Putting it together on the tasks organisations actually automate. Each pattern is built as a prompt plus an output contract plus an eval, not as a one-off demo — including the cases where the honest answer is that a model is the wrong tool. Coding assistance, content production, summarisation and research, support, data analysis and internal productivity.
Topics: Writing code with the help of AI: generation, review and refactoring · Test generation and using tests as the eval · Content generation: blogs, articles and reports with a house style · Automating emails and social posts with human approval · Efficient research and information curation: summarisation and analysis · Enhancing communication: proofreading, rewriting and tone control · Customer support: enhancing human-agent collaboration · Retail and ecommerce: personalisation and product content at scale · Data analysis: augmenting human insight, and the accuracy caveats · Creative writing and brainstorming with controlled divergence · Task delegation, project management and decision support · Professional development and continuous learning workflows · Problem solving and generating visual and diagram outputs · Choosing not to use a model: when rules or search win
We rebuild the agenda around the tools you actually run.
Request a custom agendaRewrite a prose prompt as instruction, delimited context, examples and a JSON schema, then prove downstream code can parse every response without defensive string handling.
Assemble fifty labelled examples for a real task, write a gradeable rubric, run two competing prompts, and wire the whole thing into a CI job.
Define three tools with descriptions that drive correct selection, validate arguments, deliberately break one, and make the loop recover instead of spinning.
Build a retrieval pipeline over real documents, evaluate retrieval independently of generation, add reranking, and make the system say it does not know when nothing relevant is found.
Plant instructions in a retrieved document, watch the system follow them, then apply delimiting, least-privilege tools and output validation until the attack fails.
Take one real workflow to production quality: prompt, contract, eval suite, guardrails, caching, monitoring, and a documented cost and latency budget you can defend.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
My experience with the AIOps training was positive. The course covered important topics in a structured way, and Rajesh Kumar explained the concepts patiently. I found the practical aspects particularly helpful because they made the technical content easier to understand.
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.