Debug School: rakesh kumar

Difference between Traditional developer LLM application developer

rakesh kumar — Thu, 13 Aug 2026 03:43:13 +0000

Traditional developer
LLM application developer
Traditional Developer vs LLM Application
Main Difference Between All the Concepts

Traditional developer: writes the rules the software must follow.
LLM application developer: uses an AI model that has already learned language patterns, then controls it using prompts, context, validation, APIs, and normal application code.

A useful way for developers to remember it

Traditional application:

I tell the computer exactly how to do the task.

LLM application:

I tell the model what I want, provide the necessary context/data, and then verify/control its response.

And in real production systems, you normally use both together:

Traditional Development + LLM = Modern LLM Application

Laravel
│
├── Authentication       → Traditional code
├── Payments             → Traditional code
├── Booking validation   → Traditional code
├── Database             → Traditional code
│
├── AI chatbot           → LLM
├── Review summary       → LLM
├── Natural language Q&A → LLM
└── Description writing  → LLM

Traditional Developer vs LLM Application

Traditional Backend
────────────────────

Input
  ↓
Business Logic
  ↓
Database/API
  ↓
Output

LLM Application
────────────────────

User Input
    ↓
Prompt + Instructions + Context
    ↓
Tokenization
    ↓
LLM
    ↓
Probabilistic Generation
    ↓
Structured Output
    ↓
Validation
    ↓
Business Rules
    ↓
Application

Main Difference Between All the Concepts

How to delete particular row from postgress pgsql using commands

rakesh kumar — Mon, 10 Aug 2026 07:13:02 +0000

Enter PostgreSQL
Show all databases
Connect to a particular database
delete all rows from table

Enter PostgreSQL

sudo -u postgres psql

Show all databases

Inside psql:

\l

or:

\list

Example:

hl_booking
hl_country
hl_profile
hl_trip
postgres

Connect to a particular database

For example:

\c hl_booking

You should see:

You are now connected to database "hl_booking".

Then show all tables:

\dt

Suppose your table name is bookings.

delete all rows from table

To delete all rows but keep the table structure:

DELETE FROM availability_slots;

SELECT * FROM bookings;

SELECT * FROM bookings LIMIT 10;

SELECT *
FROM bookings
WHERE status = 'confirmed';

INSERT INTO bookings
(user_id, status)
VALUES
(10, 'pending'),
(11, 'confirmed'),
(12, 'cancelled');

UPDATE bookings
SET status = 'confirmed'
WHERE id = 10;

UPDATE bookings
SET
    status = 'confirmed',
    updated_at = NOW()
WHERE id = 10;

DELETE FROM bookings
WHERE id = 10;


DELETE FROM bookings
WHERE id = 10
RETURNING *;

To see all fields/columns of a particular PostgreSQL table, use:

## \d bookings

“AI and LLM Foundations for Developers: From Machine Learning to Transformers, Tokens, Embeddings, and RAG

rakesh kumar — Mon, 10 Aug 2026 03:19:58 +0000

What are we trying to understand?
Machine Learning
Deep Learning
Neural Networks
Generative AI
Large Language Model (LLM)
Transformer
Attention
Tokens and Tokenization
Context Window
Inference
Temperature
Top-p and Sampling
Deterministic vs Probabilistic Software
Embeddings
Hallucination
Pretraining
Prompting
Fine-tuning
RAG
Prompting vs RAG vs Fine-tuning
The complete LLM request lifecycle
Main Difference Between All the Concepts

What are we trying to understand?

As a traditional developer, you're accustomed to this:

Input
  ↓
Your Code
  ↓
Business Rules
  ↓
Database/API
  ↓
Predictable Output

For example:

if age >= 18:
    return "Adult"
else:
    return "Minor"

Same input → same logic → same output.

An LLM application behaves differently:

User Input
    ↓
Prompt / Instructions
    ↓
Tokenization
    ↓
LLM
    ↓
Probabilistic Generation
    ↓
Validation
    ↓
Application

Understanding why that middle part behaves differently is the purpose of Week 1.

Machine Learning

Definition

Machine Learning (ML) is a way of creating software where the system learns patterns from data instead of you manually programming every decision rule.

Traditional programming:

Rules + Data
     ↓
 Program
     ↓
 Output

Machine learning:

Historical Data + Expected Outputs
              ↓
           Training
              ↓
            Model
              ↓
        New Data → Prediction

Example

Suppose MotoShare wants to predict whether a booking is potentially fraudulent.

Traditional approach:

if booking_amount > 100000:
    suspicious = True

But fraud can depend on:

booking amount
user history
vehicle
location
booking frequency
payment behavior
account age
device

ML learns patterns among these features.

Purpose

Learn ML because LLMs themselves are machine-learning models.

You don't need to become a classical ML expert first, but you should understand:

data
training
model
prediction/inference
features
evaluation

Deep Learning

Definition

Deep learning is a branch of machine learning that uses multi-layer neural networks to learn complicated patterns from large amounts of data.

Artificial Intelligence
        │
        └── Machine Learning
                │
                └── Deep Learning
                        │
                        └── Generative AI
                                │
                                └── LLMs

Why do we need it?

Traditional ML can work very well for structured problems such as:

Price prediction
Fraud detection
Spam detection
Customer churn

Deep learning is particularly powerful for unstructured/high-dimensional information:

Text
Images
Audio
Video
Language

Backend analogy

Think of ML as an application and a neural network as one possible implementation engine.

You don't need to understand every transistor inside your CPU to write Laravel/Python applications.

Likewise, you don't initially need the mathematics behind every neural-network operation to build LLM systems.

Neural Networks

Definition

A neural network is a collection of connected mathematical units that transforms inputs through learned parameters called weights.

Very simplified:


INPUT
  ↓
Layer
  ↓
Layer
  ↓
Layer
  ↓
OUTPUT

During training:

Input
 ↓
Prediction
 ↓
Compare with expected result
 ↓
Calculate error
 ↓
Adjust weights
 ↓
Repeat millions/billions of times

Backend analogy

Imagine an enormous configurable function:

output = model(input, billions_of_learned_parameters)

Except developers didn't manually write all those parameters.

They were learned during training.

Why learn this?

Because terms such as:

7B model
70B model
parameters
weights
training
fine-tuning

will otherwise be confusing later.

Generative AI

Definition

Generative AI produces new content based on patterns learned during training.

It can generate:

Text
Code
Images
Audio
Video
Structured data

Traditional ML vs Generative AI

Traditional ML might answer:

Input:
"This vehicle is excellent."

Output:
Positive

Generative AI could answer:

"Write a professional description
for this vehicle."

→

"Experience comfortable city travel
with this well-maintained..."

The second system generates content.

Purpose

Agentic AI is primarily built around generative models that can reason over instructions, produce responses and increasingly invoke tools.

Large Language Model (LLM)

Definition

An LLM is a large neural network trained on huge amounts of text to predict and generate sequences of tokens.

One crucial mental model:

An LLM is fundamentally predicting what token should come next.

Suppose the input is:

The capital of India is

Possible next tokens could have probabilities resembling:

Delhi       0.91
Mumbai      0.03
India       0.02
Kolkata     0.01

The generation process continues:

Input
 ↓
Predict next token
 ↓
Append token
 ↓
Predict next token
 ↓
Append token
 ↓

Why learn this?

This explains many things you'll encounter:

temperature
hallucination
tokens
context windows
prompt engineering
sampling

Transformer

This is one of the most important Week 1 concepts.

Definition

A Transformer is a neural-network architecture designed to process sequences while determining relationships between different parts of the input.

Modern LLMs are largely built using transformer architectures.

Why was it important?

Consider:

Ashwani deposited ₹10,000 into the bank.
He withdrew ₹2,000 the next day.
How much money remains?

The model needs relationships among:

Ashwani
He
₹10,000
₹2,000
bank
withdraw

Transformers help model those relationships.

Simplified architecture

For Week 1, remember:

Transformer = architecture; 
LLM = a language model commonly built using transformer architecture.

Attention

Definition

Attention allows the model to determine which parts of the available context are relevant when processing another part.

Consider:

Raj put his laptop inside his bag
because he was traveling.

What was inside the bag?

For answering the question, important relationships include:

bag ← laptop

Less important information may include:

traveling

Conceptually:

          "bag"

               │
       Attention relationships
        ↙      ↓       ↘
     Raj    laptop   traveling
             ↑
         highly relevant

Backend analogy

Think of attention loosely as dynamic relevance selection.

A backend developer might explicitly select:

SELECT relevant_columns
FROM data
WHERE condition = ...

Attention learns which parts of context matter instead of using your manually written SQL condition.

Why learn it?

Later it helps you understand:

context
RAG
long documents
prompt placement
agent memory

Tokens and Tokenization

This is extremely important for production AI.

Definition

LLMs don't directly process text as human-readable words.

Text is converted into tokens.

"AI is powerful"

       ↓ Tokenizer

[token1, token2, token3, ...]

A token might represent:

a word
part of a word
punctuation
whitespace-related units

So:

Characters ≠ Words ≠ Tokens

Why do tokens matter?

Because they affect:

API cost
context limits
latency
maximum output

Conceptually:

Cost ≈
(input tokens × input price)
+
(output tokens × output price)

Backend analogy

Tokens are somewhat like payload size.

You already care about:

HTTP request size
memory
DB query size
response size

With LLMs you additionally care about:

token budget

Context Window

Definition

The context window is the amount of tokenized information a model can consider within a request/conversation context.

It can contain more than just the latest user message.

Context Window
│
├── System instructions
├── Developer instructions
├── Conversation history
├── User message
├── Retrieved RAG documents
├── Tool results
└── Generated tokens

Important misconception

Context is not permanent memory.

If you have:

Message 1
Message 2
Message 3
...
Message 5000

you cannot assume the model permanently remembers everything.

Applications often manage this using:

truncation
summarization
RAG
external memory
sliding windows
databases

Why learn it?

Agents often maintain long-running conversations and tool results.

Bad context management produces:


high cost
high latency
lost information
context overflow
poor responses

Inference

Definition

Training teaches the model.

Inference uses the trained model.

TRAINING

Huge dataset
    ↓
Training process
    ↓
Learn weights
    ↓
Trained model

INFERENCE

Your prompt
    ↓
Trained model
    ↓
Generated response

When your FastAPI application calls an LLM API, you're normally performing inference, not training.

Backend analogy

Think:

Training ≈ building/compiling/preparing the capability

Inference ≈ executing that capability for a request

It's not a perfect analogy, but useful initially.

Temperature

Definition

Temperature controls how much variation is allowed during token selection.

Conceptually:

Temperature ↓
More predictable

Temperature ↑
More variation

Example:

Prompt:
Give me a slogan for MotoShare.

Low temperature might repeatedly produce similar direct answers.

Higher temperature may produce more diverse alternatives.

When should you use low temperature?

Tasks requiring consistency:

classification
data extraction
structured output
business decisions
API workflows

Higher temperature?

Creative tasks:

marketing copy
brainstorming
story ideas
slogans

But temperature does not magically turn the model into a truth engine.

Top-p and Sampling

The model may assign probabilities to candidate next tokens.

Example:

Delhi       70%
Mumbai      10%
Kolkata      7%
Chennai      5%

Sampling determines how the next token is selected from that probability distribution.

Temperature and top-p influence this selection.

For Week 1:

Temperature
    ↓
changes probability sharpness/variation

Top-p
    ↓
limits selection to a probability mass

Sampling
    ↓
select next token

Next token

You don't need the detailed mathematics yet.

Deterministic vs Probabilistic Software

This is a major mindset change for backend developers.

Traditional backend:

2 + 2
 ↓
4

You expect the same result every time.

LLM:

"Write a vehicle description."
             ↓
            LLM
       ↙      ↓       ↘
Response A Response B Response C

Therefore:


Traditional software

Input → Rules → Output


AI software

Input
 ↓
Prompt
 ↓
Probabilistic Model
 ↓
Possible Output
 ↓
VALIDATION
 ↓
Application

Why this matters for Agentic AI

An agent may decide:

Which tool?
What arguments?
Do I need another tool?
Is the task complete?

Therefore you cannot treat model output like trusted deterministic code.

Embeddings

This will become extremely important when you learn RAG.

Definition

An embedding converts information such as text into a numerical vector representing aspects of its semantic meaning.

"Rent a bike"
      ↓
Embedding model
      ↓
[0.13, -0.82, 0.44, ...]

Consider:

A = "I want to rent a car."

B = "I need a vehicle for hire."

C = "Python supports decorators."

Semantically:

Similarity(A, B) → HIGH
Similarity(A, C) → LOW

even though A and B don't contain exactly the same words.

Backend analogy

Traditional search:

WHERE description LIKE '%car rental%'

Semantic search:

Query
 ↓
Embedding
 ↓
Vector similarity search
 ↓
Semantically related documents

Where will you use this?

Later:

RAG
semantic search
recommendations
document retrieval
knowledge bases
similarity matching

Hallucination

Definition

Hallucination occurs when an LLM generates information that appears plausible but is unsupported, incorrect or fabricated.

Example:

User:
"What is the rental price of this vehicle?"

Context:
No price provided.

Bad model:
"The rental price is ₹1,500/day."

The model created information that wasn't available.

Why?

Remember:

LLM
 ≠
database

LLM
 ≠
truth engine

LLM
 =
probabilistic language model

Production solution

Never rely solely on:

"Please don't hallucinate."

Instead build:

User question
      ↓
Retrieve trusted data
      ↓
Provide context
      ↓
LLM
      ↓
Structured output
      ↓
Validation
      ↓
Business rules

This leads directly to RAG.

Pretraining

Definition

Pretraining is the large-scale initial training process through which an LLM learns language patterns and broad knowledge from huge datasets.

Massive dataset
      ↓
Pretraining
      ↓
General-purpose model

As an application developer, you usually do not pretrain an LLM yourself.

It's extremely expensive.

Prompting

You provide instructions and context at inference time without changing the model's underlying trained weights.


Existing Model
     +
Prompt
     +
Context
     ↓
Response

Example:

Classify this MotoShare enquiry into:

BOOKING
PAYMENT
CANCELLATION
OTHER

No model training required.

Start here first

For most application problems:

Prompting
   ↓
Structured Output
   ↓
RAG
   ↓
Fine-tuning if justified

Don't jump directly to fine-tuning.

Fine-tuning

Definition

Fine-tuning further trains an existing model using a specialized dataset to influence its behavior or capabilities for a particular task/domain.

Base Model
    ↓
Specialized training examples
    ↓
Fine-tuned Model

Don't confuse this with RAG

Fine-tuning
    ↓
changes model behavior/weights

RAG
    ↓
supplies external information at runtime

If the problem is:

"The AI doesn't know today's MotoShare vehicle inventory."

Fine-tuning is generally the wrong solution.

You want:

Database / Search
        ↓
Retrieve current vehicles
        ↓
LLM

RAG

RAG = Retrieval-Augmented Generation.

Definition

RAG retrieves relevant information from an external source and supplies that information to an LLM as context before generation.

User Question
      ↓
Create/Search representation
      ↓
Knowledge Base / Vector DB
      ↓
Relevant Documents
      ↓
Prompt + Documents
      ↓
LLM
      ↓
Answer

Why?

Your database may know:

Vehicle availability
Rental price
Booking policy
Cancellation policy

The LLM shouldn't invent these.

Retrieve them.

Then let the LLM reason/generate using them.

Prompting vs RAG vs Fine-tuning

The complete LLM request lifecycle

Here is the architecture you should remember:

                React Application
                          │
                          │ HTTP
                          ▼
                  ┌───────────────┐
                  │    FastAPI    │
                  └───────┬───────┘
                          │
                    Validate Input
                          │
                          ▼
                 Build Instructions
                          │
                          ▼
                System + User Prompt
                          │
                          ▼
                   TOKENIZATION
                          │
                          ▼
                ┌──────────────────┐
                │  Context Window  │
                │                  │
                │ System Prompt    │
                │ User Prompt      │
                │ History          │
                │ RAG Context      │
                │ Tool Results     │
                └────────┬─────────┘
                         │
                         ▼
                  Transformer / LLM
                         │
                  ┌──────┴──────┐
                  │ Attention   │
                  │ Neural Net  │
                  │ Parameters  │
                  └──────┬──────┘
                         │
                         ▼
                 Next-token scores
                         │
                         ▼
             Temperature / Sampling
                         │
                         ▼
                  Select Token
                         │
                         ▼
               Generate Next Token
                         │
                    repeat...
                         │
                         ▼
                   Model Output
                         │
                         ▼
                Pydantic Validation
                         │
                 ┌───────┴────────┐
                 │                │
              Valid            Invalid
                 │                │
                 ▼                ▼
           Business Logic    Retry / Reject
                 │
                 ▼
             FastAPI Response
                 │
                 ▼
                React

How everything connects

The entire Week 1 can be reduced to this mental model:

            AI
                     │
              Machine Learning
                     │
               Deep Learning
                     │
              Neural Networks
                     │
                Transformer
                     │
                    LLM
                     │
        ┌────────────┼─────────────┐
        │            │             │
      Tokens      Attention    Embeddings
        │            │             │
        └────────────┼─────────────┘
                     │
               Context Window
                     │
                   Prompt
                     │
                 Inference
                     │
        Temperature + Sampling
                     │
               Generated Output
                     │
              Possible Hallucination
                     │
                  Validation
                     │
             Production Application

What you need to know before moving forward

Don't memorize definitions. You should be able to explain these relationships:

ML → Deep Learning → Neural Network → Transformer → LLM

and:

Text → Tokens → Context → Transformer → probabilities → sampling → tokens → response → validation

and finally:

Prompting = give instructions

RAG = give external/current knowledge

Fine-tuning = modify model behavior through additional training

Pretraining = create the general model capability

Main Difference Between All the Concepts

chatgpt
differences
differences

The Ultimate Reusable Master Prompt to Become an AI Agentic Developer

rakesh kumar — Thu, 06 Aug 2026 02:54:34 +0000

the best cycle is:
For each week:
Master instruction prompt
Week 1: Practical LLM foundations
Week 2: FastAPI AI microservice with Laravel
Week 3: Prompt engineering as software engineering

the best cycle is:

Understand → Build → Break → Debug → Improve → Test → Explain

Not:

Watch videos → Take notes → Watch more videos → Forget

How to use these prompts

For each week:

Start a fresh ChatGPT or Claude conversation.
Paste the Master Instruction Prompt.
Paste that week’s prompt.
Write the code yourself.
Share your code for review.
Finish the weekly GitHub project and README.

Each one-hour topic session should approximately follow:

10 minutes: Essential theory
10 minutes: Architecture and minimal example
25 minutes: You implement
10 minutes: Debugging and improvement
5 minutes: Questions and revision

Master instruction prompt

Paste this once at the beginning of every weekly conversation.

Act as my senior AI engineering mentor, pair programmer, system architect,
technical interviewer and code reviewer.

My background:
- Six years of professional software development experience
- Experienced in Python, PHP, Laravel, REST APIs, SQL, PostgreSQL,
  Redis, Docker, Git, Linux and microservice architecture
- I understand classes, functions, APIs, databases, queues, authentication,
  validation and software architecture
- Do not teach basic Python, Laravel, Git, SQL or HTTP
- My goal is to become a production-oriented AI and Agentic AI developer
  in 12 weeks

My learning method:

Understand → Build → Break → Debug → Improve → Test → Explain

For every topic, follow this exact process.

PHASE 1 — ESSENTIAL THEORY

Spend no more than 10–15 minutes of reading.

Explain:
1. What problem the technology solves
2. How it works internally at a practical level
3. Its important terminology
4. How it relates to Laravel, Python, APIs, queues, services,
   middleware, events or state machines
5. When it should be used
6. When it should not be used
7. What I can safely ignore for now

Avoid:
- long history
- unnecessary mathematics
- beginner programming lessons
- generic definitions without real examples

PHASE 2 — MINIMAL IMPLEMENTATION

Show the smallest runnable example.

Include:
- architecture
- folder structure
- installation commands
- environment variables
- request and response contracts
- important code only
- command to run it
- one success test
- one failure test

Explain why every important component exists.

PHASE 3 — MY CODING TASK

Give me a practical task to implement myself.

Provide:
- requirements
- API contract
- input and output examples
- acceptance criteria
- edge cases
- test requirements

Do not provide the complete solution.

Wait for me to share my implementation.

PHASE 4 — CODE REVIEW

When I share code, review:

- correctness
- architecture
- validation
- type safety
- security
- exception handling
- retries and timeouts
- testability
- maintainability
- performance
- token and API cost
- production readiness

Return:

1. Critical problems
2. Why each problem matters
3. Hints to correct them
4. Corrected code only where necessary
5. Missing test cases
6. Score out of 10
7. Next implementation task

PHASE 5 — BREAK AND DEBUG

Create realistic failures such as:

- invalid input
- malformed model output
- provider timeout
- API rate limit
- unavailable database
- incorrect tool call
- duplicate execution
- authorization failure
- context-window overflow
- prompt injection
- infinite agent loop

Let me diagnose the issue before showing the answer.

PHASE 6 — PRODUCTION UPGRADE

Upgrade the working version one feature at a time:

- clean architecture
- Pydantic validation
- configuration management
- authentication
- authorization
- retries
- timeouts
- idempotency
- structured logging
- tracing
- caching
- queue processing
- cost limits
- security
- unit tests
- integration tests
- Docker
- CI/CD
- Laravel integration

Explain the production problem solved by each improvement.

PHASE 7 — ASSESSMENT

Give me:

- five practical questions
- three debugging scenarios
- three interview questions
- one architecture decision
- one improvement assignment

After I answer, score:

- conceptual understanding
- implementation ability
- debugging ability
- architecture ability
- production readiness

Never move to the next phase until I finish the current phase or ask you
to continue.

My goal is to write and understand the implementation—not merely copy
AI-generated code.

Week 1: Practical LLM foundations

The blog places Python, FastAPI and core AI concepts in Weeks 1–2. Since you already know Python, Week 1 should concentrate on transformers, tokens, context windows, inference, embeddings, temperature, hallucinations and the difference between training, fine-tuning and prompting.

Week 1 prompt

Using my master instructions, teach Week 1 through a practical
“LLM Experiment Lab.”

PROJECT

Create a Python command-line and notebook-based laboratory that demonstrates:

1. Tokenization
2. Context windows
3. Temperature
4. Deterministic versus probabilistic output
5. System and user messages
6. Structured output
7. Embeddings and semantic similarity
8. Hallucination
9. Prompting versus fine-tuning
10. Input/output token cost estimation

PHASE 1 — ESSENTIAL THEORY

Explain only the theory required to run these experiments:

- machine learning versus deep learning versus generative AI
- transformer architecture at a practical level
- tokens and tokenization
- attention at a high level
- context window
- inference
- temperature, top-p and sampling
- embeddings
- hallucination
- pretraining, fine-tuning, RAG and prompting

For every concept:

- give a precise two- or three-line explanation
- compare it with traditional backend development
- show one product use case
- explain one common failure

Do not teach advanced mathematics.

PHASE 2 — MINIMAL EXPERIMENTS

Guide me through small runnable experiments:

Experiment 1:
Tokenize three different texts and compare token counts.

Experiment 2:
Call an LLM three times with temperature 0 and temperature 1.

Experiment 3:
Send a long conversation and observe context usage.

Experiment 4:
Generate valid and invalid JSON and validate it with Pydantic.

Experiment 5:
Create embeddings for five sentences and calculate semantic similarity.

Experiment 6:
Ask the model a question not covered by the supplied context and observe
hallucination.

Provide installation commands and a minimal project structure.

PHASE 3 — MY TASK

Ask me to build an “AI Text Analyzer” that:

- accepts user text
- estimates token usage
- summarizes it
- classifies its category
- extracts structured entities
- returns estimated API cost
- records latency
- handles malformed output

Do not provide the full solution.

Acceptance criteria:

- typed Python code
- Pydantic models
- environment variables
- provider abstraction
- pytest tests
- timeout handling
- structured logging

PHASE 4 — PRODUCTION DISCUSSION

After my implementation works, explain:

- why model output cannot be trusted directly
- why structured validation is required
- when low temperature is useful
- when embeddings are useful
- when RAG is preferable to fine-tuning
- how context affects cost and latency

Then review my implementation.

PHASE 5 — ASSESSMENT

Give me:

- five experiment-based questions
- three debugging problems
- three interview questions
- one scenario requiring me to choose among prompting, RAG and fine-tuning

Week 1 deliverable

Repository: ai-llm-experiment-lab
Deliverable: Token, temperature, embeddings and structured-output experiments
README: Explain findings from every experiment

THEORY PROMPT FOR Week 1: AI and LLM foundations

Prompt 1: Learn the AI mental model
Using my master instructions, teach me the practical AI and LLM foundations
required by an experienced backend developer.

Cover:
- machine learning versus deep learning versus generative AI
- neural networks at a practical level
- transformers
- attention
- tokenization
- context windows
- inference
- temperature and sampling
- pretraining, fine-tuning and prompting
- embeddings
- hallucination
- deterministic software versus probabilistic AI systems

Do not teach advanced mathematics unless it is directly required.

For every concept:
1. Give a precise definition.
2. Explain what happens internally.
3. Compare it with a traditional backend concept.
4. Show where I would use it in a real product.
5. Explain what can go wrong.
6. Give one small experiment I can execute.

Conclude with a diagram of an LLM request lifecycle, from user input to
tokenization, inference, output generation and validation.
Prompt 2: Tokens, context and cost
Teach me tokens, context windows and LLM cost management as a production engineer.

Use concrete examples involving:
- a Laravel support application
- a Python FastAPI AI service
- conversation history
- large documents
- system prompts
- tool responses

Demonstrate:
- how text becomes tokens
- why context is not permanent memory
- what consumes the context window
- how long conversations fail
- truncation, summarization and sliding-window strategies
- how to estimate cost per request
- how to set request-level token budgets

Give me Python utilities for:
- estimating tokens
- rejecting oversized requests
- trimming conversation history
- logging estimated input and output cost

Include unit tests and edge cases.
Prompt 3: One-hour implementation
Guide me through building a minimal FastAPI LLM service.

Endpoints:
POST /summarize
POST /classify
POST /extract
POST /chat

Requirements:
- Pydantic request and response models
- structured outputs
- environment-based configuration
- provider abstraction
- timeout and retry handling
- consistent error responses
- structured logging
- pytest tests
- Docker support

Do not give the complete code immediately.

First:
1. Present the architecture.
2. Present the folder structure.
3. Define the API contracts.
4. Identify failure scenarios.
5. Wait for my approval.

Then guide me file by file and review each part I share.

Week 2: FastAPI AI microservice with Laravel

The roadmap’s first project is a FastAPI service with /summarize, /classify, /extract and /chat, connected to a Laravel application.

Week 2 prompt

Using my master instructions, teach Week 2 by building a production-oriented
FastAPI AI microservice and connecting it to Laravel.

PROJECT ARCHITECTURE

Laravel application
        ↓ REST API or Queue
FastAPI AI microservice
        ↓
LLM provider

REQUIRED ENDPOINTS

POST /api/v1/summarize
POST /api/v1/classify
POST /api/v1/extract
POST /api/v1/chat
GET  /health
GET  /ready

PHASE 1 — ESSENTIAL THEORY

Explain only the FastAPI features important to AI services:

- async versus sync
- Pydantic request and response models
- dependency injection
- exception handlers
- lifespan management
- middleware
- connection pooling
- streaming
- health and readiness endpoints

Compare each feature with its Laravel equivalent.

PHASE 2 — ARCHITECTURE

First provide:

- component diagram
- folder structure
- API contracts
- Pydantic schemas
- provider interface
- expected errors
- security boundaries

Do not provide the complete implementation yet.

Suggested architecture:

app/
  api/
  core/
  models/
  schemas/
  services/
  providers/
  exceptions/
  middleware/
tests/

PHASE 3 — IMPLEMENTATION TASKS

Guide me through these tasks one at a time:

Task 1:
Create configuration and environment validation.

Task 2:
Create Pydantic request/response schemas.

Task 3:
Create an abstract LLM provider interface.

Task 4:
Implement one provider.

Task 5:
Implement /summarize.

Task 6:
Implement /classify and /extract using structured outputs.

Task 7:
Implement /chat with limited conversation history.

Task 8:
Create Laravel AIService using Laravel HTTP Client.

Task 9:
Move long-running calls to a Laravel queue job.

Wait for my code after every task.

PHASE 4 — FAILURE HANDLING

Make me implement:

- connection timeout
- request timeout
- provider rate limit
- malformed model output
- unavailable provider
- invalid API key
- oversized request
- Laravel retry
- duplicate queue execution

PHASE 5 — PRODUCTION UPGRADE

Add:

- service-to-service authentication
- correlation IDs
- idempotency keys
- retries with exponential backoff
- circuit breaker design
- structured logs
- request metrics
- token and cost tracking
- Docker
- pytest
- Laravel integration tests

PHASE 6 — ASSESSMENT

Ask me when to use:

- direct synchronous HTTP
- Laravel queue
- webhook callback
- Redis/message broker
- streaming response

Give practical and interview questions after implementation.

Week 2 deliverable

Repository: laravel-fastapi-ai-service
Deliverable: Laravel application calling four AI endpoints

THEORY PROMPT FOR FastAPI AI microservice and Laravel integration

Prompt 1: Production FastAPI architecture

Teach me only the FastAPI concepts that are important for production AI services.

Skip basic Python and basic REST explanations.

Cover:
- dependency injection
- async versus sync endpoints
- Pydantic validation
- middleware
- exception handlers
- lifespan events
- connection pooling
- background tasks
- streaming responses
- API authentication
- rate limiting
- request IDs
- health and readiness endpoints

Compare every major concept with its Laravel equivalent.

Build a reference architecture for:

Laravel application
    ↓
Python FastAPI AI service
    ↓
LLM provider
    ↓
PostgreSQL / Redis

Explain which responsibilities belong in Laravel and which belong in FastAPI.

Prompt 2: Laravel-to-Python integration

Design a reliable integration between Laravel and a FastAPI AI microservice.

Use case:
Laravel sends text to FastAPI for summarization, classification, extraction
or chat completion.

Cover:
- synchronous HTTP calls
- asynchronous Laravel queue jobs
- webhook callbacks
- Redis or message-queue integration
- authentication between services
- idempotency keys
- correlation IDs
- retries with exponential backoff
- timeout handling
- circuit breakers
- duplicate request prevention
- audit logs

Provide:
1. Sequence diagram
2. API contract
3. Laravel service class
4. Laravel queue job
5. FastAPI endpoint
6. Failure-handling strategy
7. Integration tests

Explain when HTTP is enough and when a queue is preferable.

Prompt 3: Code-review prompt

Use this whenever you complete a feature:

Review the following implementation as a senior AI platform engineer.

Evaluate:
- architecture
- correctness
- type safety
- async usage
- validation
- security
- timeout handling
- retries
- idempotency
- structured logging
- test coverage
- maintainability
- Laravel integration
- production readiness

Do not rewrite everything immediately.

Return:
1. Critical problems
2. High-priority improvements
3. Optional improvements
4. Missing test cases
5. Corrected code only for critical sections
6. A score out of 10
7. Conditions required before production deployment

Here is my implementation:

[PASTE CODE]

Week 3: Prompt engineering as software engineering

The blog’s Weeks 3–4 include message roles, prompt engineering, structured JSON output, tool calling, streaming, history, token management, and retry/fallback handling. It specifically says not to practise only inside ChatGPT but to create API-based applications.

Week 3 prompt

Using my master instructions, teach Week 3 by building a production
Prompt Engineering Laboratory.

PROJECT

Build an API that generates:

- MotoShare vehicle descriptions
- HolidayLandmark trip summaries
- DevOpsSchool course descriptions

PHASE 1 — ESSENTIAL THEORY

Explain prompt engineering as software engineering.

Cover:

- system, developer, user and assistant messages
- instruction hierarchy
- zero-shot prompting
- few-shot prompting
- context
- constraints
- delimiters
- output contracts
- reusable prompt templates
- prompt injection
- hallucination reduction
- prompt versioning

For every concept:

1. Show a weak prompt.
2. Run or predict its likely failure.
3. Show an improved prompt.
4. Define a test for it.

PHASE 2 — BUILD A PROMPT TEMPLATE SYSTEM

Design a template structure containing:

- prompt name
- prompt version
- purpose
- system instruction
- input variables
- constraints
- output schema
- examples
- refusal behavior
- changelog

Store templates outside application code.

PHASE 3 — PRACTICAL EXPERIMENTS

Experiment with:

- vague versus explicit instructions
- zero-shot versus few-shot
- plain text versus structured output
- no delimiters versus clear delimiters
- no examples versus two examples
- one large prompt versus modular prompt sections
- temperature differences

Record results in a comparison table.

PHASE 4 — MY PROJECT

Ask me to implement a “Vehicle Listing Content Generator.”

Input:

- vehicle category
- brand
- model
- year
- city
- features
- rental price
- target customer
- language
- desired tone

Output:

- listing title
- short description
- detailed description
- five highlights
- SEO title
- meta description
- social caption
- warnings when information is missing

Requirements:

- Pydantic validation
- prompt templates
- prompt versions
- no invented vehicle features
- multilingual support
- regression tests
- token logging

Do not provide the complete solution.

PHASE 5 — PROMPT DEBUGGING

Give me five failing model responses.

Make me identify whether each problem is:

- ambiguous instruction
- missing context
- prompt conflict
- hallucination
- schema failure
- unsupported request
- prompt injection

PHASE 6 — ASSESSMENT

Ask practical questions about designing, testing, versioning and improving prompts.

Week 3 deliverable

Repository: production-prompt-engineering-lab
Deliverable: Tested and versioned prompt-template service

THEORY PROMPT FOR Prompt engineering and structured output

The roadmap’s Weeks 3–4 include system/user/assistant messages, prompt engineering, structured JSON, streaming, conversation history, token management and fallback handling.

Prompt 1: Prompt engineering for developers

Teach me prompt engineering as software engineering, not as a list of clever phrases.

Cover:
- system, developer, user and assistant instructions
- instruction hierarchy
- zero-shot and few-shot prompting
- constraints
- delimiters
- role and context
- output contracts
- prompt templates
- prompt versioning
- prompt injection
- handling ambiguous input
- avoiding unsupported claims

For each concept:
- show a weak prompt
- explain why it fails
- show an improved prompt
- define how its quality can be tested

Use examples from:
- MotoShare vehicle description generation
- HolidayLandmark itinerary generation
- DevOpsSchool support answers

End by giving me a reusable production prompt template with:
purpose, input, constraints, output schema, failure behavior and examples.

Prompt 2: Structured output with Pydantic

Teach me how to obtain reliable structured output from an LLM.

Build a HolidayLandmark Trip Creation Assistant that accepts:
- destination
- number of days
- budget
- traveller type
- group size
- preferences

It must return:
- title
- summary
- highlights
- day-wise itinerary
- price suggestion
- exclusions
- warnings
- confidence

Requirements:
- strict Pydantic schemas
- enums where appropriate
- nested models
- field constraints
- output validation
- retry after malformed output
- refusal when information is insufficient
- no invented factual claims
- model-independent provider interface

First design the schema.
Then design the prompt.
Then implement the service.
Then create at least 15 malformed-output and edge-case tests.

Prompt 3: Prompt debugging

I will give you a prompt and several model outputs.

Act as a prompt debugger.

For every failure:
1. Classify the failure:
   - instruction failure
   - schema failure
   - missing context
   - ambiguity
   - hallucination
   - unsafe behavior
   - model limitation
2. Identify the exact prompt section responsible.
3. Recommend the smallest possible correction.
4. Do not overcomplicate the prompt.
5. Create a regression test for the failure.
6. Produce the corrected version with a version number and changelog.

Prompt:
[PASTE PROMPT]

Expected output:
[PASTE EXPECTED OUTPUT]

Actual outputs:
[PASTE OUTPUTS]

Week 4: Structured output, tools, streaming and conversation history

Week 4 prompt

Using my master instructions, teach Week 4 by building a HolidayLandmark
AI Trip Creation Assistant.

USER INPUT

- destination
- number of days
- budget
- currency
- traveller type
- group size
- preferred activities
- accommodation preference
- travel month

REQUIRED OUTPUT

- title
- summary
- highlights
- daily itinerary
- estimated pricing
- inclusions
- exclusions
- warnings
- required trip JSON

PHASE 1 — ESSENTIAL THEORY

Explain:

- structured outputs
- JSON schema
- Pydantic nested models
- enums and constraints
- structured output versus tool calling
- tool selection
- tool argument validation
- conversation history
- context management
- streaming responses
- retries and fallbacks

PHASE 2 — SCHEMA-FIRST DESIGN

Before writing prompts:

1. Design the complete Pydantic schema.
2. Identify required and optional fields.
3. Add range and length constraints.
4. Define enums.
5. Define validation rules.
6. Show valid and invalid payloads.

Wait for my approval.

PHASE 3 — MINIMAL VERSION

Build Version 1:

- one request
- one LLM call
- validated structured response
- no tools
- no conversation
- no database write until validation succeeds

PHASE 4 — TOOL-CALLING VERSION

Add safe tools:

- get_destination_information
- search_available_trip_categories
- get_currency_information
- estimate_base_price
- check_existing_similar_trips

Teach:

- how the model selects a tool
- how application code executes it
- why the model must not directly access the database
- argument validation
- authorization
- maximum tool-call iterations

PHASE 5 — CONVERSATIONAL VERSION

Allow the assistant to ask for missing information.

Implement:

- limited conversation history
- summarization of old messages
- token budget
- streaming response
- cancellation
- conversation persistence
- user isolation

PHASE 6 — FAILURE TESTS

Make me handle:

- invalid JSON
- missing days
- unrealistic budget
- unsupported destination
- tool timeout
- repeated tool call
- invented pricing
- context overflow
- interrupted stream

PHASE 7 — LARAVEL INTEGRATION

Create:

- Laravel form
- request validation
- AI-service call
- preview page
- human confirmation
- storage only after confirmation
- audit record containing prompt and schema version

PHASE 8 — ASSESSMENT

Test me on structured output, tools, conversation state and streaming.

Week 4 deliverable

Repository: holidaylandmark-ai-trip-assistant
Deliverable: AI-generated trip preview validated before database storage

THEORY PROMPT FOR Tool calling, streaming and conversations

Prompt 1: Function and tool calling

Teach function calling and tool calling from first principles for an
experienced API developer.

Explain:
- the difference between structured output and tool calling
- tool schema
- tool selection
- tool arguments
- execution by application code
- returning tool results to the model
- parallel versus sequential tool calls
- forced versus automatic tool selection
- validation and authorization
- tool-call loops
- maximum iteration limits

Build a MotoShare booking assistant with safe read-only tools:

search_vehicles
check_vehicle_availability
get_booking_status
get_payment_status
create_support_ticket

The model must never execute database queries directly.

Show:
1. Tool schemas
2. Tool registry
3. Dispatcher
4. Pydantic validation
5. Authorization checks
6. Tool-result handling
7. Loop protection
8. Unit and integration tests

Prompt 2: Conversation history and memory

Explain conversation history and memory without treating them as the same thing.

Cover:
- message history
- working memory
- persistent memory
- semantic memory
- user profile memory
- summaries
- retrieval-based memory
- privacy and retention
- context-window limitations

Design a conversation architecture using:
- Laravel for users and permissions
- FastAPI for AI orchestration
- PostgreSQL for durable records
- Redis for temporary session state

Explain:
- what should be saved
- what should never be saved
- when conversations should be summarized
- how users can delete stored information
- how to prevent one user's memory from leaking to another

Provide schemas and pseudocode, but do not implement an agent yet.

Prompt 3: Streaming implementation
Teach and implement token streaming between:

LLM provider
→ FastAPI
→ Laravel
→ Browser UI

Compare:
- Server-Sent Events
- WebSockets
- chunked HTTP responses

Recommend the simplest reliable option for an AI chat application.

Include:
- FastAPI streaming endpoint
- Laravel proxy or direct-client architecture
- cancellation when the user stops generation
- timeout handling
- partial-output handling
- authentication
- logging without storing sensitive content
- frontend JavaScript example
- tests for interrupted and failed streams

Week 5: Embeddings and vector search

The roadmap uses Weeks 5–6 for document chunking, embedding models, vector databases, semantic search, filtering, hybrid search, reranking, citations and RAG evaluation.

Week 5 prompt

Using my master instructions, teach Week 5 by building semantic search for
DevOpsSchool documentation.

PHASE 1 — ESSENTIAL THEORY

Explain:

- what embeddings represent
- vector dimensions
- cosine similarity
- dot product
- query and document embeddings
- semantic search versus keyword search
- embedding-model selection
- normalization
- multilingual embeddings
- vector indexing
- metadata filtering

Use PostgreSQL and pgvector.

Avoid unnecessary mathematical derivations.

PHASE 2 — EMBEDDING EXPERIMENTS

Create experiments that compare:

- identical sentences
- paraphrased sentences
- similar words with different intentions
- technical terms
- multilingual questions
- irrelevant sentences

Show similarity scores and make me interpret them.

PHASE 3 — DATABASE DESIGN

Design:

documents
document_versions
document_chunks
embedding_jobs

Each chunk should have:

- document ID
- version
- source URL/path
- title
- section
- content
- content hash
- metadata
- embedding model
- vector
- timestamps

Explain pgvector indexes and filtering.

PHASE 4 — INGESTION PIPELINE

Build:

load
→ clean
→ normalize
→ chunk
→ add metadata
→ embed
→ store
→ verify

Compare:

- fixed chunking
- recursive chunking
- semantic chunking
- parent-child chunking

Create an experiment using at least three chunk sizes and overlaps.

PHASE 5 — MY PROJECT

Ask me to implement a semantic documentation search API.

Endpoints:

POST /documents/index
POST /documents/reindex
POST /search
DELETE /documents/{id}

Search response:

- chunk content
- source
- section
- similarity score
- metadata

Requirements:

- pgvector
- metadata filters
- deduplication
- content hashing
- incremental indexing
- deleted-document handling
- pytest tests

PHASE 6 — FAILURE TESTING

Test:

- duplicate documents
- modified documents
- empty documents
- huge files
- poor chunks
- wrong embedding dimensions
- embedding-provider failure
- model migration
- cross-project retrieval

PHASE 7 — ASSESSMENT

Make me explain why retrieval failed in several examples.

Week 5 deliverable

Repository: devopsschool-semantic-search
Deliverable: Search API over real documentation using PostgreSQL + pgvector

THEORY PROMPT FOR Embeddings and semantic search

Prompt 1: Embeddings mental model

Teach embeddings to me as an experienced database and backend developer.

Cover:
- what an embedding represents
- vector dimensions
- semantic similarity
- cosine similarity, dot product and Euclidean distance
- why similar words are not always similar intentions
- embedding model selection
- query and document embeddings
- normalization
- multilingual embeddings
- changing embedding models
- limitations of semantic search

Use PostgreSQL and pgvector examples.

Include:
- a small Python experiment
- table schema
- indexing options
- similarity query
- metadata filtering
- common production mistakes
- tests that demonstrate poor and good retrieval

Prompt 2: Document ingestion pipeline

Design a production document-ingestion pipeline for a DevOpsSchool
Knowledge Assistant.

Sources:
- Markdown documentation
- README files
- course pages
- troubleshooting guides
- test documentation
- PDFs where text extraction is reliable

Pipeline stages:
load → clean → normalize → split → enrich metadata → embed → store → verify

Teach me:
- fixed-size, recursive and semantic chunking
- chunk overlap
- parent-child chunking
- document and chunk identifiers
- deduplication
- content hashes
- versioning
- incremental re-indexing
- deleted-document handling
- embedding-model migrations

Provide:
1. Architecture
2. Database schema
3. Chunking strategy
4. Python implementation plan
5. Laravel-triggered indexing flow
6. Test plan

Week 6: Complete production RAG

The blog’s RAG project is a DevOpsSchool Knowledge Assistant that uses documentation, README files, course information, tests and troubleshooting guides, returning an answer, sources and confidence.

Week 6 prompt

Using my master instructions, teach Week 6 by converting the Week 5 semantic
search system into a production RAG Knowledge Assistant.

RESPONSE CONTRACT

{
  "answer": "...",
  "sources": [],
  "confidence": 0.0,
  "answerable": true
}

PHASE 1 — ESSENTIAL THEORY

Explain the complete RAG pipeline:

query
→ query normalization
→ retrieval
→ filtering
→ reranking
→ context construction
→ generation
→ citation validation
→ final response

Explain the difference between:

- retrieval failure
- generation failure
- missing-document failure
- grounding failure

PHASE 2 — NAIVE RAG

Build a minimal RAG version using:

- vector search
- top-k chunks
- one generation prompt
- source list

Then intentionally demonstrate its weaknesses.

PHASE 3 — PRODUCTION IMPROVEMENTS

Add one feature at a time:

1. Metadata filtering
2. Hybrid keyword + vector search
3. Query rewriting
4. Reranking
5. Context deduplication
6. Source citations
7. Insufficient-evidence handling
8. Document-version preference
9. Context token budget
10. Caching

For every feature:

- explain the problem
- define acceptance criteria
- let me implement it
- review my implementation

PHASE 4 — MY PROJECT

Build the DevOpsSchool Knowledge Assistant using:

- documentation
- README files
- course pages
- existing tests
- troubleshooting guides

Requirements:

- answer only from retrieved evidence
- provide citations
- refuse unsupported answers
- return useful confidence information without pretending certainty
- isolate projects and permissions
- record retrieval traces
- track latency, tokens and cost

PHASE 5 — RAG DEBUGGING LAB

Give me traces containing:

- user query
- retrieved chunks
- scores
- selected context
- generated answer

Make me diagnose:

- bad chunking
- missing metadata
- poor embedding match
- incorrect top-k
- noisy retrieval
- missing reranking
- hallucination
- stale documentation
- conflicting documents

PHASE 6 — EVALUATION

Create a golden dataset containing:

- exact questions
- paraphrased questions
- multi-document questions
- unanswerable questions
- ambiguous questions
- outdated-content conflicts
- injection text inside documents

Measure:

- retrieval hit rate
- context relevance
- answer correctness
- groundedness
- citation correctness
- latency
- cost

PHASE 7 — ASSESSMENT

Give practical RAG architecture and debugging questions.

Week 6 deliverable

Repository: devopsschool-rag-assistant
Deliverable: Grounded knowledge assistant with citations and evaluation

THEORY PROMPT FOR Production RAG

Prompt 1: End-to-end RAG

Teach me end-to-end Retrieval-Augmented Generation by building a
DevOpsSchool Knowledge Assistant.

The response contract must be:

{
  "answer": "...",
  "sources": [],
  "confidence": 0.0
}

Cover:
- query preprocessing
- embedding search
- metadata filtering
- hybrid keyword and vector search
- reranking
- context construction
- grounded answer generation
- source citations
- insufficient-evidence responses
- confidence limitations
- latency and cost

First show a naïve RAG pipeline.
Then explain exactly where it fails.
Then develop a production-oriented version.

The system must say that it does not know when the retrieved evidence
does not support an answer.

Prompt 2: RAG debugging

Act as a RAG debugging expert.

I will provide:
- user query
- retrieved chunks
- expected answer
- generated answer
- retrieval scores

Diagnose whether the failure comes from:
- document ingestion
- chunking
- embeddings
- metadata
- query transformation
- retrieval
- top-k selection
- reranking
- context construction
- generation prompt
- unsupported source content

Return:
1. Root cause
2. Evidence supporting the diagnosis
3. Smallest corrective action
4. Retrieval test to add
5. Generation test to add
6. Whether re-embedding is required
7. Whether the document itself lacks the answer

Data:
[PASTE RAG TRACE]
Prompt 3: RAG evaluation dataset
Help me create a golden evaluation dataset for a RAG system.

Create categories for:
- exact factual questions
- paraphrased questions
- multi-document questions
- questions requiring metadata filters
- unanswerable questions
- ambiguous questions
- outdated-information conflicts
- prompt-injection attempts inside documents
- similar but incorrect documents
- large-context questions

For each test case define:
- query
- expected source document
- expected facts
- forbidden claims
- answerability
- retrieval success criteria
- generation success criteria

Do not generate fake company facts. Give me a template and guide me to
populate it from my real documents.

Week 7: Agentic AI without a framework

The blog defines an agent as a system that receives a goal, selects tools, acts, observes the result and continues until completion or human intervention. It recommends starting with a fixed workflow and adding autonomy only where genuinely necessary.

Week 7 prompt

Using my master instructions, teach Week 7 by building a tool-using agent
in plain Python without LangGraph.

PROJECT

Build a Laravel Error Investigation Agent.

SAFE TOOLS

- read_log_excerpt
- search_repository
- read_file
- list_recent_migrations
- read_configuration
- search_known_solutions

PHASE 1 — ESSENTIAL THEORY

Explain:

- agent goal
- agent loop
- observation
- action
- tool
- planning
- state
- memory
- termination
- human approval
- bounded autonomy
- idempotency
- error recovery

Compare:

- chatbot
- tool-using assistant
- deterministic workflow
- router
- autonomous agent

Explain when a normal function is better than an agent.

PHASE 2 — FIXED WORKFLOW FIRST

Build a deterministic workflow:

receive error
→ classify error
→ read logs
→ choose investigation category
→ inspect relevant information
→ create report
→ request approval
→ stop

Use plain Python functions and typed state.

PHASE 3 — ADD LIMITED DECISION-MAKING

Allow the model to choose among approved read-only tools.

Implement:

- tool registry
- Pydantic argument validation
- authorization
- result size limits
- timeout
- maximum steps
- duplicate-action detection
- stop conditions

PHASE 4 — MY TASK

Ask me to implement the agent loop myself.

Do not provide the full code.

Acceptance criteria:

- explicit state
- deterministic termination
- maximum 10 steps
- read-only access
- audit trail
- no shell
- no arbitrary SQL
- no production modification
- human approval before recommendations are applied

PHASE 5 — FAILURE SIMULATION

Create:

- infinite loop
- repeated tool call
- incorrect tool choice
- invalid arguments
- tool timeout
- unauthorized file request
- poisoned tool output
- incomplete investigation

Let me debug each one.

PHASE 6 — ASSESSMENT

Ask me to decide which parts should be deterministic and which parts
benefit from model reasoning.

Week 7 deliverable

Repository: plain-python-error-investigation-agent
Deliverable: Safe tool-calling agent without an agent framework

THEORY PROMPT FOR Agentic AI foundations

The blog correctly distinguishes an agent from a chatbot: an agent receives a goal, chooses tools, acts, observes results and continues until completion or human intervention. It also recommends beginning with deterministic workflows before introducing autonomy.

Prompt 1: Agent mental model

Teach Agentic AI to me using state-machine and workflow concepts.

Cover:
- agent loop
- goal
- observation
- reasoning
- action
- tool
- state
- memory
- termination
- human approval
- planning
- retries
- error recovery
- idempotency
- bounded autonomy

Compare:
- chatbot
- tool-using assistant
- deterministic workflow
- router
- autonomous agent
- long-running agent

For each one explain:
- appropriate use case
- inappropriate use case
- level of risk
- testing difficulty
- production controls required

Conclude with a decision tree answering:
“Does this problem actually require an agent?”

Prompt 2: Build without a framework first

Help me implement a minimal tool-using agent in plain Python before using LangGraph.

Agent task:
Investigate an application error using safe, read-only tools.

Tools:
- read_log_excerpt
- search_repository
- read_file
- search_documentation
- list_recent_migrations

Requirements:
- explicit state model
- maximum-step limit
- validated tool arguments
- permission checks
- tool timeout
- duplicate-action detection
- final report
- request human approval before any proposed modification
- no shell access
- no production writes

Guide me through:
1. State design
2. Agent loop pseudocode
3. Tool interface
4. Stop conditions
5. Implementation
6. Tests
7. Failure simulation

Week 8: LangGraph and stateful agent workflows

The roadmap identifies LangGraph as suitable for stateful, long-running workflows with shared state, nodes, persistence and memory.

Week 8 prompt

Using my master instructions, teach Week 8 by converting the Week 7 plain-Python
agent into LangGraph.

PHASE 1 — ESSENTIAL THEORY

Explain using Laravel and workflow comparisons:

- StateGraph
- typed shared state
- nodes
- edges
- conditional edges
- reducers
- START and END
- checkpoints
- persistence
- interrupts
- human-in-the-loop
- retries
- subgraphs
- resumability

For every concept:

- explain the problem it solves
- show where it maps to the Week 7 implementation
- explain when it is unnecessary

PHASE 2 — ARCHITECTURE FIRST

Before coding, provide:

- graph diagram
- state schema
- node responsibilities
- edge conditions
- stop conditions
- checkpoint strategy
- approval points

Wait for my approval.

PHASE 3 — STEP-BY-STEP CONVERSION

Guide me through:

Task 1:
Define typed state.

Task 2:
Convert classification into a node.

Task 3:
Convert log inspection into a node.

Task 4:
Add conditional routing.

Task 5:
Add tool execution.

Task 6:
Add report generation.

Task 7:
Add human approval interrupt.

Task 8:
Add persistent checkpoints.

Task 9:
Resume an interrupted investigation.

Wait for my code after every task.

PHASE 4 — WHY STATEGRAPH?

After the minimal graph works, compare it with the Week 7 implementation.

Explain concretely:

- what StateGraph improved
- what complexity it added
- when plain Python remains preferable
- how persistence and interrupts change the design

PHASE 5 — PRODUCTION UPGRADE

Add:

- maximum-iteration guard
- retries per node
- idempotent nodes
- redacted checkpoints
- audit events
- tool authorization
- correlation IDs
- FastAPI endpoint
- Laravel API client
- queue execution
- Docker
- pytest branch coverage

PHASE 6 — DEBUGGING

Give me broken graphs containing:

- infinite cycles
- missing state
- overwritten state
- incorrect reducer
- dead-end node
- checkpoint failure
- repeated side effect
- approval bypass

PHASE 7 — ASSESSMENT

Give implementation, architecture and interview questions about LangGraph.

Week 8 deliverable

Repository: langgraph-production-error-agent
Deliverable: Resumable, checkpointed investigation workflow with approval

THEORY PROMPT FOR LangGraph and stateful workflows

Prompt 1: Learn LangGraph efficiently

Teach me LangGraph assuming I understand Laravel workflows, queues,
state machines and microservices.

Do not start with installation.

First explain:
- why LangGraph exists
- shared state
- nodes
- edges
- conditional edges
- StateGraph
- reducers
- checkpoints
- persistence
- interrupts
- human-in-the-loop
- subgraphs
- retries
- time travel or replay concepts

For each concept:
- show its Laravel or backend equivalent
- explain when it is useful
- show a minimal example
- describe one production mistake

Then convert the plain-Python error investigation agent from Week 7
into LangGraph.

Prompt 2: Production Error Investigation Agent

Design a Production Error Investigation Agent using LangGraph.

Workflow:
1. Accept error details.
2. Read a limited Laravel log excerpt.
3. Classify the error.
4. Search relevant repository files.
5. Inspect related configuration and migrations.
6. Search known documentation.
7. formulate likely causes.
8. Propose a fix.
9. Generate tests.
10. Ask for human approval.
11. Stop without modifying production.

Requirements:
- typed shared state
- deterministic stages where possible
- conditional routing
- checkpointing
- resumability
- maximum iteration limit
- tool authorization
- audit trail
- idempotency
- timeout and retry policies
- sensitive-data redaction

First provide the graph diagram and state schema.
Do not write implementation until I approve them.

Prompt 3: LangGraph debugging

Review the following LangGraph implementation.

Check specifically for:
- mutable or poorly defined state
- incorrect reducers
- infinite cycles
- missing stop conditions
- non-idempotent nodes
- unsafe tool execution
- checkpoints containing sensitive data
- improper retry behavior
- confused separation between deterministic logic and model decisions
- missing human approval
- untestable nodes

Return:
1. Graph-level defects
2. Node-level defects
3. State-schema defects
4. Security defects
5. Corrected graph diagram
6. Minimum changes required
7. Test cases for every branch

Implementation:
[PASTE CODE]
Week 9: Model Context Proto

Week 9: MCP server development

The blog describes MCP as an open standard for connecting AI applications with external tools and data, and proposes a MotoShare MCP server with restricted tools rather than dangerous capabilities such as arbitrary SQL or shell execution.

Week 9 prompt
Using my master instructions, teach Week 9 by building a secure MotoShare
MCP server.

TOOLS

- get_vehicle
- search_bookings
- get_payment_status
- read_application_logs
- create_support_ticket

PHASE 1 — ESSENTIAL THEORY

Explain:

- MCP host
- MCP client
- MCP server
- resources
- tools
- prompts
- tool schemas
- transport
- authentication
- permission boundaries
- local and remote MCP servers

Compare MCP with:

- REST API
- OpenAPI
- function calling
- application plugins
- direct SDK integration

Explain what MCP standardizes and what it does not.

PHASE 2 — THREAT MODEL

Before implementation, identify:

- unauthorized users
- tenant leakage
- excessive permissions
- prompt injection
- malicious tool arguments
- sensitive logs
- replay
- duplicate execution
- denial of service
- secret leakage

PHASE 3 — CONTRACT DESIGN

For every tool, define:

- purpose
- input schema
- output schema
- allowed roles
- data boundaries
- pagination
- rate limit
- timeout
- audit event
- failure responses

Create a permission matrix.

PHASE 4 — IMPLEMENTATION

Guide me one tool at a time.

Requirements:

- strict schemas
- service authentication
- user authorization
- tenant isolation
- parameter allowlists
- pagination
- redaction
- rate limiting
- structured logging
- audit trail
- human confirmation before support-ticket creation

Do not expose:

- arbitrary SQL
- unrestricted shell
- unrestricted file access
- raw database credentials
- production write operations

PHASE 5 — CLIENT INTEGRATION

Connect the MCP server to an AI host.

Demonstrate:

- tool discovery
- tool selection
- argument validation
- result handling
- failed tool calls
- permission denial

PHASE 6 — SECURITY TESTING

Make me test:

- SQL injection attempt
- path traversal
- cross-user booking access
- unbounded log request
- prompt injection through tool output
- duplicate ticket creation
- expired credentials
- excessive request rate

PHASE 7 — ASSESSMENT

Ask me to choose when MCP is better than direct REST integration.

Week 9 deliverable

Repository: motoshare-secure-mcp-server
Deliverable: Authenticated MCP server with five bounded tools

THEORY PROMPT FOR Model Context Protocol

The blog’s Week 9 covers MCP hosts, clients, servers, resources, tools, prompts, authentication and permission boundaries, with a MotoShare MCP server as the project.

Prompt 1: Learn MCP architecture

Teach MCP to me as an experienced API and microservice developer.

Explain:
- what problem MCP solves
- host, client and server
- resources
- tools
- prompts
- schemas
- transport
- capability negotiation
- local versus remote servers
- authentication
- authorization and trust boundaries

Compare MCP with:
- REST APIs
- OpenAPI
- function calling
- plugins
- SDK integrations

Explain what MCP standardizes and what it does not.

Conclude with:
- when to use MCP
- when a normal REST API is better
- security checklist
- production architecture diagram

Prompt 2: MotoShare MCP server

Guide me through building a secure MotoShare MCP server.

Expose only these tools:
- get_vehicle
- search_bookings
- get_payment_status
- read_application_logs
- create_support_ticket

Requirements:
- strict input schemas
- user and role authorization
- tenant isolation
- read limits
- log redaction
- pagination
- rate limiting
- audit logging
- timeout handling
- no arbitrary SQL
- no shell commands
- no unrestricted file access
- human confirmation before creating a support ticket

First define:
1. Threat model
2. Tool contracts
3. Permission matrix
4. Error model
5. Audit event schema
6. Test cases

Only then implement the server step by step.

Prompt 3: MCP security review

Perform a security review of this MCP server.

Look for:
- excessive tool permissions
- prompt injection through tool output
- unauthorized cross-user access
- tenant data leakage
- arbitrary parameters
- SQL injection
- path traversal
- sensitive log exposure
- missing rate limits
- missing human approval
- replay and duplicate execution
- secrets in errors
- weak authentication

Return findings using:
severity, attack scenario, affected component, remediation and test case.

Server implementation:
[PASTE CODE]

Week 10: Multi-agent systems

The roadmap covers supervisor-worker, router, planner-executor, reviewer, parallel workers, handoffs and shared state, while warning against creating multiple agents merely to appear advanced.

Week 10 prompt

Using my master instructions, teach Week 10 by building a Software QA
Agent Workflow.

PROPOSED ROLES

- Requirement Analyzer
- Test Planner
- API Test Generator
- UI Test Generator
- Security Reviewer
- Final Report Composer

PHASE 1 — ESSENTIAL THEORY

Explain:

- supervisor-worker pattern
- router pattern
- planner-executor pattern
- reviewer or critic pattern
- parallel workers
- handoffs
- shared state
- independent state
- disagreement handling
- termination

For every pattern explain:

- problem solved
- simpler alternative
- cost
- latency
- new failure modes
- testing difficulty

PHASE 2 — AGGRESSIVE SIMPLIFICATION

Before building anything, evaluate every proposed agent.

For each role ask:

- Does it genuinely require reasoning?
- Can deterministic code perform it?
- Can structured output perform it?
- Can it be a normal LangGraph node?
- Does a separate agent justify its cost?

Replace unnecessary agents with normal functions.

PHASE 3 — CONTRACT DESIGN

For retained agents define:

- responsibility
- input schema
- output schema
- allowed tools
- maximum calls
- timeout
- success criteria
- failure behavior
- handoff contract

Do not allow uncontrolled agent-to-agent conversation.

PHASE 4 — PROJECT

Input:

- feature requirement
- API contract
- UI screenshots or acceptance criteria
- existing test documentation

Output:

- analyzed requirements
- test plan
- API test cases
- UI test cases
- security test cases
- traceability matrix
- final review report

Requirements:

- supervisor controls execution
- structured handoffs
- duplicate-test detection
- cost limit
- maximum-step limit
- audit trail
- human review before writing files or creating a PR

PHASE 5 — COMPARISON EXPERIMENT

Build and compare:

Version A:
One structured LLM call

Version B:
Single-agent workflow

Version C:
Multi-agent workflow

Measure:

- quality
- token usage
- latency
- cost
- maintainability
- error rate

PHASE 6 — FAILURE TESTING

Test:

- conflicting agent outputs
- missing handoff field
- repeated task
- endless reviewer cycle
- supervisor failure
- cost limit exceeded
- unsupported requirement
- security reviewer disagreement

PHASE 7 — ASSESSMENT

Make me defend whether multi-agent architecture is justified.

Week 10 deliverable

Repository: ai-software-qa-workflow
Deliverable: Evaluated and simplified multi-agent QA system

THEORY PROMPT FOR Multi-agent systems

Prompt 1: Understand patterns and trade-offs

Teach multi-agent systems without hype.

Cover:
- supervisor-worker
- router
- planner-executor
- reviewer or critic
- parallel workers
- handoffs
- shared state
- independent state
- consensus
- termination
- conflict resolution

For each pattern explain:
- problem it solves
- simpler alternative
- additional latency
- additional cost
- new failure modes
- testing strategy

Provide a decision framework for choosing among:
single LLM call, deterministic workflow, single agent and multi-agent system.

Be critical: explain why many multi-agent designs should be replaced by
ordinary functions or workflow nodes.

Prompt 2: Software QA Agent Team

Design a Software QA Agent Team for Laravel and Python projects.

Roles:
- Requirement Analyzer
- Test Planner
- API Test Generator
- UI Test Generator
- Security Reviewer
- Final Report Composer

Requirements:
- each agent has one bounded responsibility
- structured input and output contracts
- no uncontrolled agent-to-agent conversation
- supervisor controls sequencing
- shared requirement identifier
- duplicate-test detection
- disagreement handling
- cost and step limits
- human review before tests are committed

First evaluate whether every proposed role genuinely needs an LLM.
Replace any unnecessary agent with deterministic code.

Then provide:
1. Architecture
2. Agent contracts
3. State schema
4. Handoff rules
5. Failure handling
6. Evaluation plan
7. Implementation stages

Prompt 3: Simplification review

Review this multi-agent architecture and aggressively simplify it.

For every agent ask:
- Does it require reasoning?
- Could a normal function perform this task?
- Could it be a LangGraph node?
- Could structured output replace the agent?
- Does it provide enough value to justify latency and cost?

Return:
1. Agents to retain
2. Agents to replace with deterministic functions
3. Agents to merge
4. Simplified architecture
5. Estimated reduction in model calls
6. New testing strategy

Architecture:
[PASTE DESIGN]

Week 11: Evaluation, security and observability

The roadmap says production AI work should include golden datasets, prompt regression tests, RAG evaluation, tool-call accuracy, hallucination checks, cost and latency tracking, injection protection, validation, rate limiting, audit logs and approval for destructive actions. It recommends creating at least 50 test cases.

Week 11 prompt

Using my master instructions, teach Week 11 by creating a complete evaluation,
security and observability system for the projects built in Weeks 1–10.

PHASE 1 — ESSENTIAL THEORY

Explain:

- golden datasets
- offline evaluation
- online monitoring
- prompt regression
- retrieval evaluation
- groundedness
- citation correctness
- schema validity
- tool selection accuracy
- tool argument accuracy
- task-completion rate
- hallucination checks
- human evaluation
- LLM-as-judge limitations

PHASE 2 — EVALUATION FRAMEWORK

Design separate evaluation suites for:

1. Structured outputs
2. Prompt templates
3. RAG
4. Tool calling
5. Agent workflows
6. MCP tools
7. Multi-agent handoffs

Define:

- test input
- expected behavior
- pass/fail rule
- metric
- threshold
- regression status

PHASE 3 — 50-CASE DATASET

Help me create at least 50 meaningful tests covering:

- normal requests
- missing information
- incorrect information
- ambiguous requests
- malformed output
- very large input
- timeout
- provider failure
- tool failure
- repeated execution
- unauthorized action
- prompt injection
- indirect injection
- data leakage
- stale document
- low-quality retrieval
- infinite agent loop
- human rejection

Do not invent company facts.

Use templates that I populate using real project information.

PHASE 4 — SECURITY REVIEW

Threat-model:

- prompt injection
- indirect injection
- tool abuse
- cross-user access
- cross-tenant access
- PII leakage
- secret exposure
- arbitrary actions
- replay
- resource exhaustion
- unsafe generated code

Implement controls and corresponding tests.

PHASE 5 — OBSERVABILITY

Trace:

Browser
→ Laravel
→ Laravel queue
→ FastAPI
→ LLM
→ RAG
→ tools
→ database

Track:

- correlation ID
- trace ID
- model
- prompt version
- schema version
- token usage
- cost
- latency
- retrieval results
- tool calls
- retries
- validation failures
- final status

Define privacy-safe logging and redaction rules.

PHASE 6 — DASHBOARD

Design metrics for:

- request volume
- success rate
- schema failure
- tool failure
- average cost
- p95 latency
- answerability
- retrieval quality
- agent completion
- approval rejection
- injection detection

PHASE 7 — ASSESSMENT

Give me a failed production trace and make me find the root cause.

Week 11 deliverable

Repository: ai-evaluation-security-observability
Deliverable: 50+ test cases, traces, dashboards and security controls

THEORY PROMPT FOR Evaluation, security and observability

The blog describes this week as the distinction between a demo developer and a professional AI engineer. It calls for golden datasets, prompt regression tests, tool-call accuracy, hallucination checks, latency and cost tracking, injection protection, output validation, rate limiting and audit logs.

Prompt 1: Evaluation framework

Teach me how to evaluate an AI system like a production software system.

My system may contain:
- prompts
- structured outputs
- RAG
- tools
- agents
- human approval

Define separate metrics for:
- answer correctness
- groundedness
- retrieval relevance
- citation correctness
- schema validity
- tool selection
- tool argument accuracy
- task completion
- safety
- latency
- cost

Help me design:
- golden dataset
- offline evaluation
- regression testing
- production monitoring
- human review sampling
- pass/fail thresholds

Explain where LLM-as-judge is useful and where it is unreliable.

Prompt 2: Generate 50 serious test cases

Create a test-plan template containing at least 50 categories of test cases
for my AI application.

Include:
- normal requests
- missing information
- contradictory information
- ambiguous instructions
- malformed JSON
- oversized input
- timeouts
- provider failure
- rate limiting
- tool failure
- repeated execution
- unauthorized tool request
- prompt injection
- indirect injection from retrieved documents
- PII leakage
- cross-user data access
- unsupported claims
- weak retrieval
- stale documents
- duplicate actions
- infinite agent loops
- interrupted workflow
- human approval rejection

Do not invent expected business facts.

For each case provide:
test objective, input pattern, expected behavior, failure signal and automation method.

Prompt 3: Observability design

Design observability for a Laravel + FastAPI + LLM agent system.

I need to trace one request across:
browser → Laravel → queue → FastAPI → LLM → tools → database

Cover:
- correlation IDs
- traces
- spans
- structured logs
- model name
- prompt version
- token usage
- latency
- cost
- tool calls
- retries
- validation failures
- human approval
- final status

Protect:
- user messages
- credentials
- access tokens
- personal information
- retrieved confidential documents

Provide:
1. Event schema
2. Trace example
3. Redaction rules
4. Metrics dashboard
5. Alert thresholds
6. Audit versus operational log separation

Week 12: Enterprise AI Operations Assistant

The blog’s final project is an AI Operations Assistant that can read repositories, logs and documentation, find known solutions, produce investigation reports, suggest changes, generate tests, open a draft pull request, require approval and maintain an audit trail.

Week 12 prompt

Using my master instructions, guide me through building the final enterprise
AI Operations Assistant.

CAPABILITIES

- read authorized GitHub repositories
- read sanitized Laravel logs
- read project documentation
- search known solutions using RAG
- investigate application errors
- identify likely causes
- propose code changes
- generate tests
- create a draft pull request
- request human approval
- maintain an audit trail

SAFETY RULES

- never modify production
- never merge pull requests
- never expose secrets
- never execute arbitrary shell commands
- never execute arbitrary SQL
- use least-privilege access
- require approval before external write actions
- make every action auditable

PHASE 1 — REQUIREMENTS

Help me define:

- users
- roles
- use cases
- non-functional requirements
- scope
- out-of-scope actions
- acceptance criteria

PHASE 2 — THREAT MODEL

Identify:

- repository data leakage
- malicious logs
- prompt injection in code or docs
- unsafe code suggestions
- tool abuse
- unauthorized pull request
- secret leakage
- cross-project access
- duplicate external actions

PHASE 3 — ARCHITECTURE

Use:

- Laravel main application
- FastAPI AI API
- LangGraph workers
- PostgreSQL + pgvector
- Redis
- queue workers
- GitHub integration
- MCP tools where justified
- centralized logs and traces

Provide:

- component diagram
- request sequence
- state schema
- trust boundaries
- permission model
- data model
- API contracts
- failure matrix

Wait for my approval.

PHASE 4 — IMPLEMENTATION STAGES

Stage 1:
Authentication, authorization and project boundaries

Stage 2:
Read-only repository tools

Stage 3:
Sanitized log-reading tools

Stage 4:
Document ingestion and RAG

Stage 5:
Error-investigation LangGraph workflow

Stage 6:
Suggested-code patch generation

Stage 7:
Test generation

Stage 8:
Human approval interrupt

Stage 9:
Draft pull-request creation

Stage 10:
Audit trail

At every stage:

- define acceptance criteria
- let me implement it
- review my code
- require tests
- do not continue until it passes

PHASE 5 — PRODUCTION DEPLOYMENT

Add:

- Docker
- separate API and worker containers
- Redis queues
- health and readiness checks
- secrets management
- service authentication
- model fallback
- caching
- rate limits
- cost limits
- horizontal scaling
- backup
- rollback
- GitHub Actions CI/CD

PHASE 6 — FAILURE EXERCISES

Test:

- LLM unavailable
- GitHub unavailable
- Redis unavailable
- vector database unavailable
- malformed agent state
- malicious repository instruction
- repeated PR request
- approval rejection
- long-running investigation
- cost threshold exceeded

PHASE 7 — FINAL EXAMINATION

Evaluate me through:

- five architecture scenarios
- five debugging scenarios
- three coding exercises
- two security reviews
- one complete system-design task

Score:

- LLM development
- prompt design
- structured output
- RAG
- tool calling
- agents
- LangGraph
- MCP
- multi-agent architecture
- evaluation
- security
- observability
- deployment

Tell me honestly whether I am ready for production AI engineering.

Week 12 deliverable

Repository: enterprise-ai-operations-assistant
Deliverable: Complete controlled AI workflow with draft PR and human approval

THEORY PROMPT FOR Production deployment and capstone

The final week of the roadmap covers Docker, workers, Redis, background jobs, authentication, tracing, fallbacks, caching, CI/CD and scaling. Its suggested capstone is an AI Operations Assistant that can investigate issues, suggest changes, generate tests and open a draft pull request while requiring human approval.

Prompt 1: Production architecture

Act as a principal AI platform architect.

Design a production deployment architecture for:

Laravel application
Python FastAPI AI service
LangGraph workers
PostgreSQL + pgvector
Redis
LLM providers
MCP servers
GitHub integration
centralized logs and traces

Cover:
- Docker containers
- API and worker separation
- queues
- autoscaling
- health checks
- readiness checks
- secrets
- service authentication
- caching
- provider fallback
- cost limits
- rate limits
- backups
- zero-downtime deployment
- rollback
- CI/CD
- disaster recovery

Provide:
1. Component diagram
2. Request sequence
3. Deployment topology
4. Environment variables
5. Failure matrix
6. Security boundaries
7. Deployment checklist

Prompt 2: Capstone execution prompt

Guide me in building an enterprise AI Operations Assistant.

Capabilities:
- read authorized GitHub repositories
- read sanitized Laravel logs
- read project documentation
- search known solutions using RAG
- generate an investigation report
- suggest code changes
- generate tests
- prepare a draft pull request
- request human approval
- maintain an audit trail

Safety restrictions:
- no automatic production modification
- no unrestricted shell
- no arbitrary SQL
- no merging pull requests
- no secret exposure
- least-privilege repository access
- every external action must be auditable

Work in phases:

Phase 1: Requirements and threat model
Phase 2: Architecture and state schema
Phase 3: Read-only tools
Phase 4: RAG
Phase 5: LangGraph workflow
Phase 6: GitHub draft-PR integration
Phase 7: Evaluation
Phase 8: Deployment
Phase 9: Security review

At each phase:
- give acceptance criteria
- let me implement it
- review my code
- require tests
- do not continue until the phase passes

Prompt 3: Final expert assessment

Evaluate whether I am ready to work professionally as an AI and
Agentic AI developer.

Assess me through a practical examination covering:
- LLM fundamentals
- prompt design
- structured output
- tool calling
- FastAPI architecture
- Laravel integration
- embeddings
- RAG
- LangGraph
- MCP
- agent design
- multi-agent trade-offs
- evaluation
- security
- observability
- deployment

Do not ask definition-only questions.

Give me:
1. Five architecture scenarios
2. Five debugging scenarios
3. Three coding exercises
4. Two security reviews
5. One system-design assignment

After I answer:
- score each competency
- identify evidence of understanding
- identify weak areas
- provide a two-week correction plan
- tell me honestly whether I am production-ready

Weekly schedule

Prompt to use after every coding session

Review today's implementation as a strict senior AI engineer.

Here is what I attempted:

[DESCRIBE TASK]

Here is my code:

[PASTE CODE OR REPOSITORY FILES]

Evaluate:

- whether I understand the topic
- correctness
- architecture
- security
- validation
- failure handling
- test coverage
- cost
- observability
- production readiness

Do not rewrite the entire implementation.

Return:

1. What I implemented correctly
2. Critical defects
3. Design weaknesses
4. Missing tests
5. One debugging exercise
6. One production improvement
7. Three revision questions
8. My next coding task
9. Score out of 10

Prompt to convert each week into revision notes

Convert this week's work into an experienced developer's revision document.

Include:

1. Problem solved
2. Important mental models
3. Architecture
4. Main implementation
5. Important code patterns
6. Failures encountered
7. Debugging lessons
8. Security risks
9. Performance and cost considerations
10. Testing strategy
11. Laravel integration
12. Five interview questions
13. Five flashcards
14. Topics that need revision next week

Keep it technical and practical.
Do not include beginner explanations.

Daily one-hour learning workflow

Use the following workflow for every topic:

Time    Activity
0–10 min  Run the teaching prompt and understand the mental model
10–20 min Ask questions about unclear concepts
20–40 min Implement the smallest working version
40–50 min Add one failure scenario and one test
50–60 min Ask AI to review your code and quiz you

At the end of each session, use:

Summarize today's session into a developer revision note.

Include:
- five essential ideas
- architecture learned
- code completed
- mistakes I made
- unresolved questions
- five flashcards
- three interview questions
- tomorrow's first task

Keep the note under 700 words.

folder structure

How Experienced Developers Can Learn AI and Agentic AI Faster Using ChatGPT, Claude and Real Projects

rakesh kumar — Wed, 05 Aug 2026 03:43:31 +0000

Introduction

Explain the problem:

AI courses are often designed for beginners.
Long video playlists consume too much time.
Experienced developers already understand APIs, databases, authentication, queues, Docker and architecture.
They should focus on AI-specific concepts and practical implementation.

Why Video-First Learning Is Slow

Explain the limitations:

Long introductions
Repeated basic concepts
Passive learning
Outdated framework examples
No code review
No project-specific guidance
Difficult to find one exact answer in a long video

Clarify that videos are still useful for visual concepts, but they should not be the main learning method.

The Recommended Learning Formula

Use this model:

Understand
   ↓
Build
   ↓
Break
   ↓
Debug
   ↓
Improve
   ↓
Test
   ↓
Explain

Recommended time distribution:

20% Essential theory
60% Practical implementation
10% Debugging and testing
10% Documentation and revision

How ChatGPT and Claude Reduce Learning Time

Explain how AI assistants can act as:

Personal tutor
Pair programmer
Architecture reviewer
Debugging assistant
Interviewer
Test-case generator
Documentation assistant

But also mention that developers must write and understand the code themselves.

The Wrong Way to Use AI

Show poor prompts:

Explain LangGraph.
Teach me RAG.
Build an AI agent.

These prompts usually generate generic theory or an oversized project.

The Correct Prompt Pattern

Use:

I am an experienced Python and Laravel developer.

Teach me [TOPIC] using a build-first approach.

Follow this sequence:

1. Explain only the essential theory required to start.
2. Show the smallest runnable example.
3. Give me a mini-project to implement myself.
4. Do not give the complete solution.
5. Review my implementation when I share it.
6. Create realistic failures for me to debug.
7. Upgrade the working version toward production.
8. Test me using practical and interview questions.

Compare unfamiliar AI concepts with APIs, Laravel services, queues,
events, middleware, state machines and microservices.

Include validation, security, retries, timeouts, logging, testing,
cost control and deployment.

Topic-by-Topic Practical Prompt Strategy

Cover the following core topics.

LLM fundamentals

Project:

Build an LLM experiment lab for tokens, temperature,
structured output, embeddings and hallucination.

FastAPI AI services

Project:

Build a FastAPI AI microservice and integrate it with Laravel.

Prompt engineering

Project:


Build and test versioned prompts for a real content-generation API.

Structured output and tool calling

Project:

Build an assistant that returns validated Pydantic output
and calls approved application tools.

Embeddings

Project:


Build semantic search using PostgreSQL and pgvector.

RAG

Project:

Build a knowledge assistant that answers only from retrieved documents
and returns citations.

Agentic AI

Project:

Build a bounded tool-using agent in plain Python.

LangGraph

Project:

Convert the plain Python agent into a resumable,
checkpointed LangGraph workflow.

MCP

Project:

Build a secure MCP server exposing limited business tools.

Multi-agent systems

Project:

Build and compare a single-call, single-agent and multi-agent workflow.

Evaluation and security

Project:

Create a golden dataset, regression tests, security tests
and observability for the AI applications.

Production deployment

Project:

Deploy Laravel, FastAPI, LangGraph workers, Redis,
PostgreSQL and an LLM provider using Docker.

A Practical One-Hour Learning Session

0–10 minutes
Understand essential concepts

10–20 minutes
Study architecture and minimal example

20–40 minutes
Implement the feature yourself

40–50 minutes
Debug one failure and add tests

50–60 minutes
Review, explain and answer questions

When to Use Documentation, Videos and AI

Recommended order:

ChatGPT/Claude explanation
        ↓
Official quickstart
        ↓
Build the project
        ↓
Watch a short video only when stuck

Real Projects for Experienced Developers

Use existing business products rather than generic chatbot projects.

MotoShare

Vehicle description generator
Rental support assistant
Vehicle availability agent
Pricing recommendation system

HolidayLandmark

AI itinerary generator
Trip creation assistant
Travel-document RAG assistant
Organizer support agent

DevOpsSchool

Documentation knowledge assistant
Course recommendation system
Production error investigation agent
Test-case generation workflow

MyHospitalNow

Hospital quote explanation assistant
Medical-document information retrieval
Hospital discovery assistant

For healthcare projects, clearly separate informational assistance from medical diagnosis.

Swift and Programming Foundations

rakesh kumar — Fri, 31 Jul 2026 03:28:59 +0000

swift_basic_syntax

1)semicolons after each statement are optional.
2)if you are using multiple statements in the same line then semicolon required or not
3)Space on both sides of an operator should be equal

swift_variables

4)syntax of multiple variables −
5) what is Type annotation

swift_constants

6)syntax to declare multiple constant

difference-between-let-and-var-in-swift

7)Difference between let and var

swift_data_types

difference-between-structclass-and-enum

data-type-in-swift

8)classify different kind of data type
9) what are the user defined data type, collective data type and derived data type
10.Difference between struct,class and Enum and When to Use Which to create project for developer
11) why init fun is need to declare in class compulsory but for struct not compulsory
12.swift is type safety programming language
13.Type inference is a special feature of Swift language

swift_strings

different way to create string 2 way
14.difference between mutable and immutable string
15.how to modify or concatenate two string
16.how to insert into string literal or meaning of string interpolation
17syntax to determine string length
18 string comparision operator syntax
19.how to get index of each char from given string using enumerated
20.difference between enumerated and foreach function
21.how to determine given string starts or ends with specified string
22.how to remove whole char of string,first char of string or last char of string, or range of specified char
23.how to reverse the char

purpose of type alias

swift_tuples

Tuples can store multiple values of the same or different data types, separated by commas.
how to access and modify tuple value
how to Assigning tuple to a set of constants
syntax for assigning names to a tuples elements
what is named tuple and nested tuple
how to add or modify elements of named tuple
swift_arrays
how to adding new element in existing array
how to get index of each elements of array
how to adding two array

swift_sets

swift_dictionaries

how to accessing and modifying dictionary
how to removing key value pair
how to removing all at once
how to apply filter in existing dictionary

How China Is Teaching Artificial Intelligence in Schools: Year-by-Year AI Curriculum for Students

rakesh kumar — Thu, 30 Jul 2026 15:03:09 +0000

Grade 5 (Age 10)

Subject

AI Applications & Smart Technologies

Topics

Introduction to Artificial Intelligence
History of AI
AI in Everyday Life
Smart Devices & IoT
Machine Learning Basics (Concept Only)
AI vs Human Intelligence
AI vs Traditional Programming
Data Collection
Data Quality & Clean Data
Voice Recognition
Speech-to-Text
Face Recognition
Image Recognition
Object Detection
Chatbots
Recommendation Systems (YouTube, Netflix)
Smart Homes
Smart Cities
Autonomous Vehicles (Introduction)
AI Ethics & Responsible AI
Digital Safety & Privacy

Practical Activities

Use Google Lens to identify objects
Interact with ChatGPT or a child-friendly AI chatbot
Try speech-to-text tools
Explore image recognition apps
Test translation apps
Compare AI recommendations on YouTube
Create simple AI stories using generative AI
Identify AI used in daily life

Mini Projects
Build a simple chatbot using Scratch or block-based AI tools
Smart Home Model
AI Daily Life Presentation
Voice Assistant Demo
Image Classification Activity
AI vs Human Comparison Chart
Smart City Poster
AI Ethics Poster

Grade 6 (Age 11)

Subject

Beginner Programming with AI

Topics
Python Programming Basics
Variables & Data Types
Input & Output
Conditional Statements
Loops
Functions (Introduction)
Lists & Dictionaries
Computational Thinking
Algorithms
Flowcharts
Debugging Basics
Scratch AI Extensions
Introduction to Machine Learning
Training Data vs Testing Data
Image Classification Basics
Text Classification Basics
Voice Recognition
OCR (Optical Character Recognition)
AI APIs (Introduction)
Prompt Engineering Basics
Responsible AI & Ethics
Cyber Safety

Practical Activities
Install and run Python
Write simple Python programs
Build calculators and guessing games
Create Scratch AI projects
Use Teachable Machine to train an image model
Convert speech to text
Generate images using AI
Build a simple Q&A chatbot
Connect to a basic AI API
Experiment with prompts

Mini Projects
Python Calculator
Number Guessing Game
AI Chatbot
Image Classifier using Teachable Machine
Voice Assistant
Animal Recognition App
Smart Attendance System (Concept)
OCR Text Reader
AI Story Generator
Simple Recommendation System

Grade 7 (Age 12)

Subject

AI Foundations

Topics
History of Artificial Intelligence
AI vs Traditional Programming
Introduction to Machine Learning
Types of AI (Narrow AI & General AI)
Data Collection & Data Quality
Supervised vs Unsupervised Learning (Concept)
Voice Recognition
Face Recognition
Image Classification
Speech Recognition
Natural Language Processing (Introduction)
AI in Healthcare, Education & Transportation
AI Ethics, Privacy & Responsible AI

Practical Activities

Explore ChatGPT and AI assistants
Train a simple image model using Teachable Machine
Build a basic chatbot with block-based tools
Use voice recognition applications
Test image classification models
Identify AI applications used in daily life

Mini Projects

Build a Simple Chatbot
Image Classifier
Voice Assistant
AI Object Recognition Demo
AI in Daily Life Presentation
Smart School Assistant (Concept)

Grade 8 (Age 13)

Subject

Programming, Data Science & Computer Vision

Topics
Python Programming
Data Types & Functions
NumPy
Pandas
Data Visualization (Matplotlib)
Statistics for AI
Data Cleaning
Machine Learning Basics
Computer Vision
Image Processing
NLP Fundamentals
OCR (Optical Character Recognition)
Recommendation Systems
AI APIs (Introduction)

Practical Activities

Analyze datasets using Python
Create charts and graphs
Build image recognition models
Perform OCR on documents
Experiment with sentiment analysis
Build simple recommendation systems

Mini Projects

Sentiment Analysis Tool
OCR Text Reader
Object Detection App
Movie Recommendation System
AI Image Recognition Project
Student Performance Dashboard

Grade 9 (Age 14)
Subject

Machine Learning & Deep Learning Fundamentals

Topics
Neural Networks
Deep Learning
CNN (Convolutional Neural Networks)
Reinforcement Learning
Model Training & Testing
Model Evaluation
AI Bias & Fairness
Privacy & Data Security
Cybersecurity Basics
Responsible AI
Explainable AI (Introduction)

Practical Activities

Train a basic neural network
Detect faces using OpenCV
Build gesture recognition demos
Experiment with reinforcement learning games
Evaluate AI model accuracy

Mini Projects

Face Detection System
Gesture Recognition
AI Game Bot
Handwritten Digit Recognition
AI Security Awareness Project
Smart Attendance System

Grade 10 (Age 15)

Subject

Advanced Programming & Generative AI

Topics
Advanced Python
Data Structures & Algorithms
SQL & Databases
REST APIs
Git & GitHub
Linux Fundamentals
LLM (Large Language Models)
Prompt Engineering
Embeddings
AI APIs
AI Productivity Tools
AI Application Development

Practical Activities
Build REST APIs
Connect applications with AI APIs
Design effective prompts
Create semantic search demos
Use Git for collaborative development

Mini Projects
AI Chatbot
AI Website
Smart Search Engine
AI Email Assistant
AI Resume Generator
AI FAQ System

Grade 11 (Age 16)

Subject

Generative AI & Enterprise AI Development

Topics
Transformer Architecture
Hugging Face Models
Open Source LLMs
LangChain
Vector Databases
Embeddings
Retrieval-Augmented Generation (RAG)
Fine-tuning Concepts
AI Evaluation
AI Security
AI Deployment Basics

Practical Activities

Build RAG applications
Store embeddings in vector databases
Use Hugging Face models
Evaluate AI responses
Connect multiple AI tools

Mini Projects

PDF Question Answering System
AI Tutor
AI Healthcare Assistant
AI Document Search
Customer Support Chatbot
Enterprise Knowledge Assistant

Grade 12 (Age 17)

Subject

Agentic AI & Intelligent Systems

Topics
AI Agents
Multi-Agent Systems
Model Context Protocol (MCP)
Tool Calling
Workflow Automation
Robotics
Internet of Things (IoT)
Edge AI
AI Entrepreneurship
AI Product Development
AI Law & Governance
Responsible AI & Ethics

Practical Activities
Build autonomous AI agents
Connect AI with external tools using MCP
Design multi-agent workflows
Integrate AI with IoT devices
Develop production-ready AI applications

Capstone Projects
Smart City AI Platform
Healthcare AI Assistant
Agricultural AI Monitoring System
Educational AI Tutor
Finance AI Advisor
Autonomous Multi-Agent System

University (4 Years)

Year 1

Computer Science Foundation

Python
C++
Java
SQL
Linux
Git
Networking
OOP
Mathematics
Statistics

Year 2

Artificial Intelligence Foundation

Machine Learning
Deep Learning
Computer Vision
NLP
Reinforcement Learning
TensorFlow
PyTorch

Year 3

Generative AI

LLM
RAG
Agents
MCP
AI Security
Cloud AI
MLOps
Docker
Kubernetes

Projects

AI Copilot
Enterprise Chatbot
Autonomous Agent

Year 4

Industry + Research

Students complete

Internship
AI Startup
Research Paper
Open Source Contributions
Production Deployment
AI Product Development

How to Become an AI and Agentic AI Developer in 12 Weeks: A Practical Roadmap for Experienced Developers

rakesh kumar — Thu, 30 Jul 2026 11:35:31 +0000

AI Engineer + Agentic AI Developer

Weeks 1–2: Python and AI foundations
Weeks 3–4: LLM application development
Weeks 5–6: Embeddings and RAG
Weeks 7–8: Agentic AI fundamentals
Week 9: MCP
Week 10: Multi-agent systems
Week 11: Evaluation, safety and observability
Week 12: Production deployment
Here's the strategy I would follow if I were in your position

The YouTube link you shared is currently titled “China’s New Education Policy” and discusses AI education in schools; it does not appear to be a developer roadmap for becoming an AI expert.

For a developer with 6 years of coding experience, you can become a strong AI application and Agentic AI engineer in 12 weeks. Becoming an AI researcher or model-training expert will take considerably longer.

Target role

Focus on becoming an:

AI Engineer + Agentic AI Developer

You should be able to build:

LLM-powered applications
RAG systems using company documents
Tool-calling agents
MCP servers
Multi-step agent workflows
Production-ready AI APIs
Evaluation, monitoring and security systems
Recommended technology stack

Use:

Python
FastAPI
OpenAI or another major LLM API
PostgreSQL + pgvector
Redis
Docker
LangGraph
MCP
Hugging Face
GitHub Actions

Continue using Laravel for your main applications, but create a separate Python AI microservice. Laravel can communicate with it through REST APIs or queues.

12-week AI and Agentic AI roadmap

Weeks 1–2: Python and AI foundations

Do not spend months learning mathematics first.

Learn:

Python syntax, classes and type hints
Virtual environments and package management
NumPy and Pandas basics
FastAPI
Async programming
REST APIs
JSON Schema and Pydantic

Understand these AI concepts:

Machine learning versus deep learning
Neural networks
Transformers
Tokens
Embeddings
Context windows
Temperature
Inference
Training versus fine-tuning

Project

Build a FastAPI service:

POST /summarize
POST /classify
POST /extract
POST /chat

Connect it to one of your Laravel applications.

Weeks 3–4: LLM application development

Learn:

System, user and assistant messages
Prompt engineering
Structured JSON output
Function and tool calling
Streaming responses
Conversation history
Token and cost management
Retry and fallback handling

Do not only practise prompts inside ChatGPT. Write actual API-based applications.

Project

Build an AI Trip Creation Assistant for HolidayLandmark:

User provides:
- Destination
- Number of days
- Budget
- Traveller type

AI generates:
- Title
- Summary
- Daily itinerary
- Highlights
- Pricing suggestion
- Required JSON data

Validate every response using Pydantic before storing it.

Weeks 5–6: Embeddings and RAG

Learn:

Document chunking
Embedding models
Vector databases
Semantic search
Metadata filtering
Hybrid search
Reranking
Citations
RAG evaluation
Project

Build a DevOpsSchool Knowledge Assistant that answers questions using:

Documentation
README files
Course information
Existing test cases
Troubleshooting guides

Store embeddings in PostgreSQL using pgvector.

The system should always return:


{
  "answer": "...",
  "sources": [],
  "confidence": 0.0
}

Weeks 7–8: Agentic AI fundamentals

An agent is not simply a chatbot. It receives a goal, chooses tools, performs actions, observes results and continues until it finishes or needs human approval.

Learn:

Agent loop
Tools and actions
Planning
State management
Short-term and long-term memory
Deterministic workflows versus autonomous agents
Human-in-the-loop approval
Error recovery
Idempotency

LangGraph is designed for long-running, stateful agent workflows and supports concepts such as shared state, nodes, persistence and memory.

Project

Build a Production Error Investigation Agent:

Read Laravel logs
Identify the likely error
Search the relevant repository
Check migrations and configuration
Suggest a fix
Generate tests
Ask for approval
Never modify production automatically

Start with a fixed workflow. Add autonomous decision-making only where it is genuinely necessary.

Week 9: MCP

MCP is an open standard that lets AI applications connect to external tools and data sources. MCP servers can expose resources, tools and reusable prompts.

Learn:

MCP host, client and server
Resources
Tools
Prompts
Tool schemas
Authentication
Permission boundaries
Local and remote MCP servers
Project

Create a MotoShare MCP server exposing safe tools:

get_vehicle
search_bookings
get_payment_status
read_application_logs
create_support_ticket

Do not expose dangerous tools such as unrestricted SQL execution or arbitrary shell commands.

Week 10: Multi-agent systems

Learn:

Supervisor and worker pattern
Router pattern
Planner and executor
Reviewer or critic pattern
Parallel workers
Agent handoffs
Shared state
When not to use multiple agents
Project

Build a Software QA Agent Team:

Requirement Agent
↓
Test Planner
↓
UI Test Generator
↓
API Test Generator
↓
Security Reviewer
↓
Final Test Report

Each agent should have a clearly limited responsibility. Avoid creating multiple agents merely because it looks advanced.

Week 11: Evaluation, safety and observability

This is what separates a demo developer from a professional AI engineer.

Learn:

Golden test datasets
Prompt regression testing
RAG evaluation
Tool-call accuracy
Hallucination checks
Latency and cost tracking
Prompt injection protection
Output validation
Rate limiting
Audit logging
Human approval for destructive actions

Create at least 50 test cases covering:

Normal request
Missing information
Incorrect information
Prompt injection
Tool failure
Timeout
Malformed output
Repeated execution
Unauthorized action
Very large input

Week 12: Production deployment

Learn:

Docker
Queue workers
Redis
Background jobs
Webhooks
Secrets management
API authentication
Logging and tracing
Model fallbacks
Caching
Cost limits
CI/CD
Horizontal scaling

Final project

Build one complete enterprise AI system:

AI Operations Assistant

It should:

Read GitHub repositories
Read Laravel logs
Read project documentation
Search known solutions
Create an investigation report
Suggest code changes
Generate test cases
Open a draft pull request
Require human approval
Maintain an audit trail
Daily routine

Study for 2–3 hours per day, six days per week:

30 minutes – Theory
60 minutes – Coding
30 minutes – Project work
30 minutes – Testing and documentation

Use this rule:

20% learning
70% building
10% publishing and explaining

Every week, publish:

One GitHub project
One README containing architecture and decisions
One demonstration video
One short technical article
Best learning order
Python and FastAPI
LLM APIs and structured output
Embeddings and RAG
Tool calling
Agent workflows
LangGraph
MCP
Evaluation and security
Deployment
Multi-agent systems

The free Hugging Face Agents Course covers agent theory, design and frameworks including smolagents, LlamaIndex and LangGraph. Its LLM course covers transformers, tokenizers, datasets and related foundations.

Important advice

Do not spend your first months on:

Training an LLM from scratch
Advanced mathematics without building anything
Learning five agent frameworks
Creating autonomous agents for every problem
Watching tutorials without completing projects
Depending entirely on generated code

Choose one stack, build four serious projects and learn how to evaluate them.

After 12 weeks, your realistic position should be:

Production-oriented AI and Agentic AI Developer, capable of adding reliable AI features and agents to Laravel, Python and enterprise applications.

You will not yet be an AI research scientist, but you can be employable and productive in applied AI.

agentic ai developer

Here's the strategy I would follow if I were in your position

The roadmap you shared is good because it focuses on AI Engineering + Agentic AI, not AI research. That's exactly the direction experienced developers should take. Similar roadmaps from AI engineering communities also emphasize building production systems rather than spending months on theory.

Here's the strategy I would follow if I were in your position

Documentation (20%)

Only for understanding APIs and frameworks.

Examples:

OpenAI API docs
Anthropic docs
LangGraph docs
MCP documentation
FastAPI docs

Documentation should answer:

How does this work?
What APIs are available?
Best practices?

Do not read documentation cover to cover.

ChatGPT / Claude (40%)

This should become your personal teacher.

Instead of searching YouTube:

❌ "LangGraph tutorial"

Ask:

Explain LangGraph assuming I'm a Laravel developer.

Then

Build a simple project.

Then

Why do we use StateGraph?

Then

Show production architecture.

Then

Give interview questions.

This reduces 10 hours of video into 1 hour.

Official Tutorial (20%)

Use only official quickstarts.

For example

OpenAI Quickstart
LangGraph Quickstart
MCP Quickstart
LlamaIndex Quickstart

Never watch a 5-hour playlist first.

YouTube (20%)

Use videos only when:

a concept is confusing
architecture needs visualization
you want to see implementation

Watch only:

Fireship
freeCodeCamp
IBM Technology
Microsoft Developer
Anthropic/OpenAI official videos

Avoid "100 videos on LangChain."

The learning cycle

For every topic:

Step 1
Ask ChatGPT

↓

Step 2
Read official documentation (20 minutes)

↓

Step 3
Build it

↓

Step 4
If stuck
Watch a 15-minute YouTube video

↓

Step 5
Build a better version

That is probably 5× faster than video-first learning.

Don't study. Build.

This is where most developers fail.

Instead of

Week 1

Prompt Engineering

Do

Build

AI Email Generator

Instead of

Week 2

RAG

Build

Company Knowledge Chatbot

Instead of

Week 3

MCP

Build

AI that controls your filesystem

Instead of

Week 4

Agents

Build


AI Travel Planner

Every topic should produce a GitHub repository.

Since you're already a Laravel developer

Your roadmap should be different from beginners.

Skip

Python basics
Variables
Loops
Functions
Git
HTTP
REST API
SQL

You already know these concepts.

Only learn Python syntax differences as needed.

Spend time here instead

LLMs
Prompt Engineering
Structured Outputs
Function Calling
Embeddings
Vector Databases
RAG
Memory
AI Agents
LangGraph
MCP
Multi-agent systems
Evaluation
AI Security

Production deployment

These are the skills that differentiate an AI engineer from a traditional backend developer.

My weekly schedule (15 hours/week)


Monday (2 hrs)
Learn one concept with ChatGPT
Read official docs
Tuesday (2 hrs)
Build a mini project
Wednesday (2 hrs)
Improve the project
Thursday (2 hrs)
Read architecture
Learn best practices
Friday (2 hrs)
Add new features
Saturday (4 hrs)

Build one complete project

Sunday (1 hr)

Write notes

The biggest shortcut

Don't create demo projects.

Create AI features for your own products.

For example:

MotoShare

AI vehicle description generator
AI pricing recommendation
AI support chatbot
AI fraud detection
AI booking assistant

MyHospitalNow

AI symptom assistant
AI treatment comparison
AI hospital recommendation
AI appointment scheduler
AI medical FAQ

HolidayLandmark

AI trip planner
AI itinerary generator
AI travel assistant
AI multilingual guide
AI review summarizer

These projects will immediately improve products you're already building and create a portfolio that demonstrates production experience.

If your goal is to become an AI/Agentic AI developer in 12 weeks

I'd simplify the roadmap into four phases:

If your goal is to become an AI/Agentic AI developer in 12 weeks

Here's the strategy I would follow if I were in your position

Planning to become ai agentic developer

Difference between struct,class and enum

rakesh kumar — Fri, 24 Jul 2026 03:37:13 +0000

Difference between class ,struct and enum
When to Use Which?
TABULAR COMPARISION

Purpose

A struct is used to group related data and methods.

A class is used to create objects that can share the same data through references.

An enum is used to represent a fixed set of possible values or states.

Example
struct Student {
    var name: String
}

class Employee {
    var name: String

    init(name: String) {
        self.name = name
    }
}

enum PaymentStatus {
    case pending
    case completed
    case failed
}

let student = Student(name: "Ashwani")
let employee = Employee(name: "Ravi")
let status = PaymentStatus.completed

print(student.name)
print(employee.name)
print(status)

Output:

Ashwani
Ravi
completed

Value Type and Reference Type

A struct is a value type.

A class is a reference type.

An enum is also a value type.

Example

struct Student {
    var name: String
}

class Employee {
    var name: String

    init(name: String) {
        self.name = name
    }
}

enum Direction {
    case north
    case south
}

Copy Behavior

When a struct or enum is assigned to another variable, a separate copy is created.

When a class object is assigned to another variable, both variables refer to the same object.

Struct example
struct Student {
    var name: String
}

var student1 = Student(name: "Ashwani")
var student2 = student1

student2.name = "Ravi"

print(student1.name)
print(student2.name)

Output:

Ashwani
Ravi
Class example
class Employee {
    var name: String

    init(name: String) {
        self.name = name
    }
}

let employee1 = Employee(name: "Ashwani")
let employee2 = employee1

employee2.name = "Ravi"

print(employee1.name)
print(employee2.name)

Output:

Ravi
Ravi
Enum example
enum Direction {
    case north
    case south
}

var direction1 = Direction.north
var direction2 = direction1

direction2 = .south

print(direction1)
print(direction2)

Output:

north
south

Inheritance

Only a class supports inheritance.

A struct and an enum cannot inherit from another struct or enum.

Example
class Person {
    func introduce() {
        print("I am a person")
    }
}

class Developer: Person {
    func code() {
        print("I write Swift code")
    }
}

let developer = Developer()

developer.introduce()
developer.code()

Output:

I am a person
I write Swift code
5. Initialization

A struct automatically gets a memberwise initializer.

A class usually requires an explicit initializer when properties do not have default values.

An enum is created using one of its predefined cases.

Struct example
struct Student {
    var name: String
    var age: Int
}

let student = Student(name: "Ashwani", age: 30)

print(student.name)
print(student.age)

Output:

Ashwani
30
Class example
class Employee {
    var name: String
    var salary: Double

    init(name: String, salary: Double) {
        self.name = name
        self.salary = salary
    }
}

let employee = Employee(name: "Ravi", salary: 50000)

print(employee.name)
print(employee.salary)

Output:

Ravi
50000.0
Enum example
enum UserRole {
    case student
    case trainer
    case admin
}

let role = UserRole.trainer

print(role)

Output:

trainer

Mutability

For a struct, both the property and the instance must be declared with var to modify the value.

For a class, a var property can be changed even when the object reference is declared using let.

For an enum, the value can change only when its variable is declared with var.

Struct example
struct Student {
    var name: String
}

var student = Student(name: "Ashwani")

student.name = "Ravi"

print(student.name)

Output:

Ravi
Class example
class Employee {
    var name: String

    init(name: String) {
        self.name = name
    }
}

let employee = Employee(name: "Ashwani")

employee.name = "Ravi"

print(employee.name)

Output:

Ravi
Enum example
enum Status {
    case offline
    case online
}

var status = Status.offline

status = .online

print(status)

Output:

online

Stored Data and Cases

A struct and a class can contain stored properties.

An enum mainly contains cases. It cannot contain normal stored instance properties, but its cases can carry associated values.

Example
struct Product {
    var name: String
    var price: Double
}

class User {
    var name: String

    init(name: String) {
        self.name = name
    }
}

enum PaymentResult {
    case success(amount: Double)
    case failure(message: String)
}

let product = Product(name: "Laptop", price: 75000)
let user = User(name: "Ashwani")
let result = PaymentResult.success(amount: 2500)

print(product.name)
print(user.name)

switch result {
case .success(let amount):
    print("Payment successful: ₹\(amount)")

case .failure(let message):
    print("Payment failed: \(message)")
}

Output:

Laptop
Ashwani
Payment successful: ₹2500.0

Best Use

Use struct for independent data models.

Use class when shared state, inheritance, or object identity is required.

Use enum when a value must be selected from a fixed set of options.

Example

struct Address {
    var city: String
    var country: String
}

class BankAccount {
    var balance: Double

    init(balance: Double) {
        self.balance = balance
    }
}

enum BookingStatus {
    case pending
    case confirmed
    case cancelled
}

let address = Address(city: "Bengaluru", country: "India")
let account = BankAccount(balance: 10000)
let bookingStatus = BookingStatus.confirmed

print(address.city)
print(account.balance)
print(bookingStatus)

Output:


Bengaluru
10000.0
confirmed

TABULAR COMPARISION

When to Use Which?

how to increase max connection in PostgreSQL

rakesh kumar — Thu, 23 Jul 2026 10:07:26 +0000

Error

check the current value

sudo vi /etc/postgresql/16/main/postgresql.conf

Increase it (pick ONE method)
Find the line:

max_connections = 100           # (change requires restart)
change to:

max_connections = 300

Step 4 — restart PostgreSQL (required)
max_connections is a static parameter — a reload is NOT enough, you must restart:

sudo systemctl restart postgresql

(Confirm it came back up:)
==============or==============================

systemctl restart apache2

systemctl status apache2 --no-pager -l

sudo systemctl status postgresql

Step 5 — verify

sudo -u postgres psql -c "SHOW max_connections;"     # → 300

Data type in swift

rakesh kumar — Thu, 23 Jul 2026 05:07:29 +0000

Basic Data Types
Collection data types
Derived data types
User-defined data types
Special data types
swift is type safety programming language
Type inference is a special feature of Swift language

Basic data types    Int, UInt, Float, Double, Bool, Character, String
Collection data types   Array, Set, Dictionary
Derived data types  Tuple, Optional, Range, Function types
User-defined data types struct, class, enum, protocol, typealias
Special data types  Any, AnyObject, Void, Never

Basic Data Types

Integer — Int

Stores whole numbers.

let age: Int = 30
let temperature: Int = -5

print(age)
print(temperature)

Output:

30
-5

Unsigned Integer — UInt

Stores only zero and positive whole numbers.

let totalStudents: UInt = 150
let availableSeats: UInt = 25

print(totalStudents)
print(availableSeats)

Output:

150
25

A UInt cannot store a negative value.

// let number: UInt = -10

Output:

Error: Negative integer cannot be converted to UInt
Float

Stores decimal values with lower precision.

let height: Float = 5.8
let weight: Float = 68.5

print(height)
print(weight)

Output:

5.8
68.5
1.4 Double

Stores decimal values with higher precision.

let price: Double = 999.99
let pi: Double = 3.141592653589793

print(price)
print(pi)

Output:

999.99
3.141592653589793
1.5 Boolean — Bool

Stores either true or false.

let isLoggedIn: Bool = true
let isAdmin: Bool = false

print(isLoggedIn)
print(isAdmin)

Output:

true
false

Boolean values are commonly used in conditions.

let hasPermission = true

if hasPermission {
    print("Access granted")
} else {
    print("Access denied")
}

Output:

Access granted
1.6 Character

Stores a single character.

let grade: Character = "A"
let currency: Character = "₹"
let emoji: Character = "😊"

print(grade)
print(currency)
print(emoji)

Output:

A
₹
😊
1.7 String

Stores text.

let name: String = "Ashwani"
let course: String = "Swift Programming"

print(name)
print(course)

Output:

Ashwani

Swift Programming

String interpolation example:

let name = "Ashwani"
let age = 30

let message = "My name is \(name) and I am \(age) years old."

print(message)

Output:

My name is Ashwani and I am 30 years old.

Collection Data Types

Array

An array stores multiple values of the same type in an ordered collection.

var fruits: [String] = ["Apple", "Mango", "Banana"]

print(fruits)
print(fruits[0])

Output:

["Apple", "Mango", "Banana"]
Apple

Adding and modifying values:

var fruits = ["Apple", "Mango", "Banana"]

fruits.append("Orange")
fruits[1] = "Grapes"

print(fruits)

Output:

["Apple", "Grapes", "Banana", "Orange"]

Looping through an array:

let subjects = ["Swift", "iOS", "Xcode"]

for subject in subjects {
    print(subject)
}

Output:

Swift
iOS
Xcode
2.2 Set

A set stores unique values. It does not guarantee order.

var skills: Set<String> = [
    "Swift",
    "Laravel",
    "Swift",
    "MySQL"
]

print(skills.count)

Output:

3

The duplicate "Swift" is stored only once.

Adding, removing, and checking values:

var technologies: Set<String> = ["Swift", "MySQL"]

technologies.insert("Laravel")
technologies.remove("MySQL")

print(technologies.contains("Swift"))
print(technologies.contains("MySQL"))

Output:

true
false

Dictionary

A dictionary stores data as key-value pairs.

var student: [String: String] = [
    "name": "Ashwani",
    "course": "Swift",
    "country": "India"
]

print(student["name"] ?? "Not found")
print(student["course"] ?? "Not found")

Output:

Ashwani
Swift

Adding and modifying values:

var employee: [String: String] = [
    "name": "Ashwani",
    "role": "Developer"
]

employee["city"] = "Bengaluru"
employee["role"] = "Senior Developer"

print(employee["city"] ?? "Not found")
print(employee["role"] ?? "Not found")

Output:

Bengaluru
Senior Developer

Derived or Compound Data Types

Tuple

A tuple groups multiple values, including values of different types.

var myValue = (value1, value2, value3, value4, , valueN)

let employee = ("Ashwani", 30, true)

print(employee.0)
print(employee.1)
print(employee.2)


Output:

Ashwani
30
true

var student = ("Robin", 21)

Access Tuple Elements

var result = tupleName.indexValue

Named tuple example:

let user = (
    name: "Ashwani",
    age: 30,
    isActive: true
)

print(user.name)
print(user.age)
print(user.isActive)

Output:

Ashwani
30
true

Function returning a tuple:

func getStudent() -> (name: String, marks: Int) {
    return ("Ashwani", 85)
}

let student = getStudent()

print(student.name)
print(student.marks)

Output:

Ashwani
85
3.2 Optional

An optional stores either a value or nil.

var email: String? = nil

print(email as Any)

Output:

nil

Optional with a value:

var email: String? = "ashwani@example.com"

if let validEmail = email {
    print(validEmail)
} else {
    print("Email not available")
}

Output:

ashwani@example.com

Using the nil-coalescing operator:

var phoneNumber: String? = nil

let displayNumber = phoneNumber ?? "Phone number not available"

print(displayNumber)

Output:

Phone number not available

3.3 Range
Closed range

Includes both starting and ending values.

for number in 1...5 {
    print(number)
}

Output:

1
2
3
4
5

Half-open range

Includes the starting value but excludes the ending value.

for number in 1..<5 {
    print(number)
}

Output:

1
2
3
4

3.4 Function Type

A function can be stored in a variable.

func add(_ first: Int, _ second: Int) -> Int {
    return first + second
}

let operation: (Int, Int) -> Int = add

let result = operation(10, 20)

print(result)

Output:

30

Another function type example:

func multiply(_ first: Int, _ second: Int) -> Int {
    return first * second
}

var calculation: (Int, Int) -> Int = multiply

print(calculation(5, 4))

Output:

20

User-Defined Data Types

4.1 Structure — struct

A structure groups related properties and methods.

Structures are value types.

struct Student {
    var name: String
    var age: Int

    func displayDetails() {
        print("Name: \(name)")
        print("Age: \(age)")
    }
}

let student = Student(
    name: "Ashwani",
    age: 30
)

student.displayDetails()

Output:

Name: Ashwani
Age: 30

Struct copy example:

struct Student {
    var name: String
}

var student1 = Student(name: "Ashwani")
var student2 = student1

student2.name = "Ravi"

print(student1.name)
print(student2.name)

Output:

Ashwani
Ravi

This shows that structures are value types. A separate copy is created.

4.2 Class — class

A class groups properties and methods.

Classes are reference types.

class Employee {
    var name: String
    var salary: Double

    init(name: String, salary: Double) {
        self.name = name
        self.salary = salary
    }

    func displayDetails() {
        print("Name: \(name)")
        print("Salary: \(salary)")
    }
}

let employee = Employee(
    name: "Ashwani",
    salary: 50_000
)

employee.displayDetails()


Output:

Name: Ashwani
Salary: 50000.0

Class reference example:

class Employee {
    var name: String

    init(name: String) {
        self.name = name
    }
}

let employee1 = Employee(name: "Ashwani")
let employee2 = employee1

employee2.name = "Ravi"

print(employee1.name)
print(employee2.name)


`Output:`


Ravi
Ravi

Both variables refer to the same class object.

4.3 Enumeration — enum

An enumeration defines a fixed group of related values.

enum UserRole {
    case student
    case trainer
    case admin
}

let role: UserRole = .trainer

switch role {
case .student:
    print("Student dashboard")

case .trainer:
    print("Trainer dashboard")

case .admin:
    print("Admin dashboard")
}

Output:

Trainer dashboard

Enum with raw values:

enum PaymentStatus: String {
    case pending = "Pending"
    case completed = "Completed"
    case failed = "Failed"
}

let status = PaymentStatus.completed

print(status.rawValue)

Output:

Completed

Enum with associated values:

enum PaymentResult {
    case success(amount: Double)
    case failure(message: String)
}

let result = PaymentResult.success(amount: 2500)

switch result {
case .success(let amount):
    print("Payment successful: ₹\(amount)")

case .failure(let message):
    print("Payment failed: \(message)")
}

Output:

Payment successful: ₹2500.0
4.4 Protocol — protocol

A protocol defines rules that a structure, class, or enum must follow.

protocol Printable {
    func printDetails()
}

struct Product: Printable {
    let name: String
    let price: Double

    func printDetails() {
        print("Product: \(name)")
        print("Price: ₹\(price)")
    }
}

let product = Product(
    name: "Laptop",
    price: 75_000
)

product.printDetails()


Output:

Product: Laptop
Price: ₹75000.0

Protocol with a class:

protocol Drivable {
    func drive()
}

class Car: Drivable {
    func drive() {
        print("The car is moving")
    }
}

let car = Car()
car.drive()

Output:

The car is moving

4.5 Type Alias — typealias

A type alias gives another name to an existing type.

typealias UserID = Int
typealias Price = Double

let userID: UserID = 101
let productPrice: Price = 999.99

print(userID)
print(productPrice)

Output:

101
999.99

Function type alias example:

typealias Calculation = (Int, Int) -> Int

func add(_ first: Int, _ second: Int) -> Int {
    return first + second
}

let operation: Calculation = add

print(operation(15, 25))

Output:

40

Special Data Types

5.1 Any

Any can store a value of any Swift type.

var value: Any = 100

print(value)

value = "Hello Swift"
print(value)

value = true
print(value)

Output:

100
Hello Swift
true

Mixed array example:

let values: [Any] = [
    "Ashwani",
    30,
    true,
    99.99
]

for value in values {
    print(value)
}

Output:

Ashwani
30
true
99.99

5.2 AnyObject

AnyObject can store an instance of any class.

class Car {
    let model: String

    init(model: String) {
        self.model = model
    }
}

let car = Car(model: "Honda City")
let object: AnyObject = car

if let validCar = object as? Car {
    print(validCar.model)
}

Output:

Honda City

5.3 Void

Void means that a function does not return a value.

func showMessage() -> Void {
    print("Welcome to Swift")
}

showMessage()

Output:

Welcome to Swift

It can also be written without -> Void:

func greetUser() {
    print("Hello, Ashwani")
}

greetUser()

Output:

Hello, Ashwani

5.4 Never

Never means that a function never returns normally.

func stopApplication() -> Never {
fatalError("Application stopped")
}

stopApplication()

Output:

Fatal error: Application stopped

Complete Classification

Most important user-defined data types

1. Structures — struct
2. Classes — class
3. Enumerations — enum
4. Protocols — protocol
5. Type aliases — typealias

swift is type safety programming language

It means that if a variable of your program expects a String, you can't pass int in it by mistake because Swift performs type-checks while compiling your code and displays an error message if it finds any type mismatch.

var varA = 42

// Here compiler will show an error message because varA 
// variable can only store integer type value
varA = "This is hello"

print(varA)

The output of the above example is:

main.swift:5:8: error: cannot assign value of type 'String' to type 'Int'
varA = "This is hello"

Type inference is a special feature of Swift language

Type inference is a special feature of Swift language; it allows the compiler to automatically deduce the type of the given expression at the time of compilation

import Foundation

// varA is inferred to be of type Int
var varA = 42
print("Type of varA variable is:", type(of:varA))

// varB is inferred to be of type Double
var varB = 3.14159
print("Type of varB variable is:", type(of:varB))

// varC is also inferred to be of type String
var varC = "TutorialsPoint"
print("Type of varC variable is:", type(of:varC))

output

The output of the above example is:

Type of varA variable is: Int
Type of varB variable is: Double
Type of varC variable is: String

Difference between let and var in swift

rakesh kumar — Thu, 23 Jul 2026 03:32:10 +0000

let (Constant)
var (Variable)
Memory Concept
With Objects
Best Practice

Interview Questions

Can a let value be modified
Can a let class object change its properties?
Can a let struct change its properties?

let (Constant)

Once a value is assigned, it cannot be changed.

let name = "Ashwani"

print(name)

Output:

Ashwani

Trying to modify it:

let name = "Ashwani"

name = "Raj"

Output:

Cannot assign to value: 'name' is a 'let' constant

var (Variable)

A var value can be changed anytime.

var age = 25

age = 26

print(age)

Output

26
Example
let company = "Apple"

var employee = "John"

employee = "Mike"

// company = "Google" ❌ Error

print(company)
print(employee)

Output

Apple
Mike

Memory Concept

let

let pi = 3.14159
pi
 │
 ▼
3.14159

Cannot change

var

var score = 10

score = 20
Initially

score
 │
 ▼
10

After update

score
 │
 ▼

With Objects

let Object

class Person {
    var name = "John"
}

let p = Person()

p.name = "Mike"

This is allowed because let makes the reference constant, not the object's internal properties.

p ─────────► Person
               │
               ▼
            name = Mike

But this is not allowed:

p = Person()

Error:

Cannot assign to value: 'p' is a 'let' constant

var Object

var p = Person()

p = Person()

This is allowed because the reference itself can change.

With Structs

Structs are value types.

struct Student {
    var name: String
}

let s = Student(name: "Ashwani")

s.name = "Raj"

Output

Cannot assign to property: 's' is a 'let' constant

Since the entire struct is constant, none of its properties can change.

Using var:

var s = Student(name: "Ashwani")

s.name = "Raj"

print(s.name)

Output

Raj

Best Practice

Swift encourages using let by default and switching to var only when a value truly needs to change.

// Good
let country = "India"

// Good
var counter = 0
counter += 1

Interview Questions

Q1. Can a let value be modified?

Answer: No. Once initialized, its value cannot change.

Q2. Can a let class object change its properties?

Answer: Yes, if those properties are declared with var. The object reference is constant, but the object's mutable properties can still change.

Q3. Can a let struct change its properties?

Answer: No. Since structs are value types, declaring a struct with let makes the entire instance immutable.