In this blog, we will explore how to list, create, delete, and modify disk partitions in Ubuntu and Red Hat-based Linux distributions using practical commands.

Understanding Linux Disk Partitions

A physical disk can be divided into smaller logical sections called partitions. Each partition can contain a filesystem, swap space, or storage managed by LVM.

Common Linux disk naming conventions include:

• /dev/sda — Physical disk
• /dev/sda1 — First partition
• /dev/sda2 — Second partition
• /dev/nvme0n1 — NVMe disk
• /dev/nvme0n1p1 — First NVMe partition

Ubuntu and Red Hat-based systems support tools such as lsblk, fdisk, parted, and blkid.

Listing Physical Disks and Partitions

Before modifying storage, identify available disks and their partitions.

lsblk

Display disk sizes, filesystems, and mount points:

lsblk -f
sudo fdisk -l
sudo blkid

To check filesystem usage:

df -hT

Why? These commands help identify unused disks, existing partitions, and mounted filesystems.

Creating a New Partition

Suppose a new disk /dev/sdb is attached to your server.

Start the partitioning utility:

sudo fdisk /dev/sdb

Inside fdisk, use:

g    Create a GPT partition table (new disk only)
n    Create a new partition
p    Print partition table
w    Write changes to disk

Warning: Creating a new partition table destroys the existing partition layout. Use g only when initializing a disk that contains no data you need.

Next, create an ext4 filesystem:

sudo mkfs.ext4 /dev/sdb1

Mount the partition:

sudo mkdir -p /data
sudo mount /dev/sdb1 /data

For persistent mounting, obtain the UUID using blkid and add the appropriate entry to /etc/fstab.

Deleting a Partition

To delete an existing partition:

sudo umount /dev/sdb1
sudo fdisk /dev/sdb

Inside fdisk:

p    Display existing partitions
d    Delete selected partition
w    Save changes

Important: Back up critical data before deleting partitions. Removing a partition can make its data inaccessible.

Ubuntu vs. Red Hat: What Changes?

Conclusion

Linux partition management becomes straightforward once you understand the relationship between physical disks, partitions, filesystems, and mount points.

The essential commands are:

• List: lsblk, fdisk -l
• Create: fdisk, mkfs
• Delete: fdisk
• Modify: parted, resize2fs, xfs_growfs

Always verify disk names, back up important data, and check whether filesystems are mounted before making changes.

Remember: A single incorrect disk command can cause permanent data loss. Practice using disposable disks or virtual machines before modifying production storage.

Introduction: From Transformers to BERT and GPT

In 2017, Google researchers introduced the Transformer architecture in the famous research paper Attention Is All You Need.

The original Transformer had two important components:

• Encoder: Understands the meaning and context of input text.
• Decoder: Generates output text, one token at a time.

This architecture became the foundation for many modern AI models, including BERT and GPT.

Interestingly, these models use different parts of the Transformer architecture.

1. BERT: The Encoder-Based Model

BERT stands for Bidirectional Encoder Representations from Transformers.

Introduced by Google in 2018, BERT primarily uses the Transformer encoder.

Its main purpose is to understand language and the relationships between words.

How does BERT work?

Consider this sentence:

“The developer deployed the application to the server.”

BERT examines words using context from both the left and right sides.

This is called bidirectional understanding.

During its original pre-training, BERT used a technique called Masked Language Modeling (MLM).

For example:

“The developer deployed the [MASK] to the server.”

BERT predicts the missing word: “application”.

By learning from surrounding words, BERT develops a strong understanding of language.

Where is BERT useful?

• Sentiment analysis
• Text classification
• Named entity recognition
• Search relevance
• Extractive question answering

Key idea: BERT is designed primarily to understand text rather than generate long responses.

2. GPT: The Decoder-Based Model

GPT stands for Generative Pre-trained Transformer.

Introduced by OpenAI in 2018, GPT uses a decoder-only Transformer architecture.

Unlike BERT, GPT focuses on generating text.

How does GPT work?

Consider this sentence:

“The developer deployed the application to…”

GPT predicts the next token based on the previous tokens.

It might generate:

“The developer deployed the application to the production server.”

GPT uses causal self-attention, meaning each token can attend only to earlier tokens and itself.

This is called autoregressive generation.

GPT repeatedly predicts the next token to produce complete sentences, explanations, or code.

Where is GPT useful?

• Chatbots and AI assistants
• Content generation
• Code generation
• Text summarization
• Translation and reasoning tasks

Key idea: GPT is designed primarily to generate text based on learned patterns and context.

3. BERT vs. GPT: Understanding the Difference

4. Why Are Both Important?

BERT demonstrated how Transformers could achieve powerful language understanding through bidirectional context.

GPT demonstrated how predicting the next token could support increasingly capable language generation.

Although their architectures differ, both rely on the Transformer’s most important innovation: self-attention.

Modern GPT-style models can also perform many language-understanding tasks, even without a separate encoder.

Conclusion

BERT and GPT represent two influential approaches to building language models.

BERT focuses on understanding context, while GPT focuses on generating sequences.

Understanding this architectural difference is an important foundation for anyone learning AI engineering, Large Language Models, and Generative AI.

This paper introduced the Transformer architecture, which became the foundation of modern AI models such as GPT, BERT, and many other Large Language Models (LLMs).

Why Did We Need Transformers?

Before Transformers, models like RNNs and LSTMs processed text sequentially, one word after another.

This created two major challenges:

• Slow training: Sequential processing limited parallel computation.
• Long-range dependencies: Understanding relationships between distant words was difficult.

Transformers addressed these challenges using a powerful concept called Self-Attention.

Understanding Transformer Architecture

The original Transformer consists of two main components:

1. Encoder — Understanding the Input

The encoder processes input text using:

• Input Embeddings: Convert words into numerical vectors.
• Positional Encoding: Adds information about word positions.
• Multi-Head Self-Attention: Identifies relationships between words.
• Feed-Forward Networks: Transform the information into useful representations.

2. Decoder — Generating the Output

The decoder uses masked self-attention, encoder-decoder attention, and feed-forward networks to generate output tokens one at a time.

What Makes Self-Attention Special?

Consider this sentence:

“The animal didn’t cross the road because it was tired.”

Self-attention helps the model connect “it” with “animal”, even though other words appear between them.

Unlike traditional sequential models, Transformers can process all input tokens simultaneously during training.

Why Was This a Game Changer?

Transformers introduced three major advantages:

1. Parallel Processing: Faster and more efficient training.
2. Better Context Understanding: Captures relationships between distant words.
3. Scalability: Supports training incrasingly large AI models.

Final Thoughts

The Transformer architecture changed how machines understand and generate language.

Research reference: Vaswani et al. (2017), “Attention Is All You Need.”

I am excited to share that I have joined the Forward Deployed Engineer (FDE) Bootcamp by Krish Naik Academy.

This is not just another course or certification for me. It is a personal commitment to challenge myself, expand my engineering capabilities, and prepare for a future where technology, especially Artificial Intelligence, is changing faster than ever.

And this time, I am taking everyone along on the journey!

Why Am I Learning Forward Deployed Engineering?

Over the years, my professional journey in Site Reliability Engineering, DevOps, Cloud Computing, Linux, Kubernetes, and Platform Engineering has taught me one important lesson:

Technology will keep changing. The ability to learn, adapt, and solve problems is what keeps an engineer relevant.

With the rapid evolution of Generative AI, Agentic AI, and intelligent automation, I believe the boundaries between traditional engineering roles are becoming increasingly interconnected.

A Software Engineer builds applications.

An AI Engineer develops AI-powered solutions.

A Forward Deployed Engineer goes a step further by understanding real business problems, designing solutions, integrating technologies, and deploying them into real-world enterprise environments.

An FDE needs to combine technical expertise with problem-solving, communication, system architecture, and business understanding.

And that is exactly what makes this role challenging and exciting!

My Motivation: Be Ready for Anything!

I am not learning FDE because I want to abandon my existing engineering experience.

Quite the opposite!

I want to build upon everything I have learned so far.

My experience in infrastructure, automation, reliability, cloud, and production systems provides a foundation. Now I want to strengthen that foundation with AI Engineering, advanced software development, and enterprise AI integration.

My goal is simple:

Be the kind of engineer who can understand a problem, design a solution, build it, deploy it, secure it, and maintain it — regardless of how technology evolves.

I don’t know exactly what the technology landscape will look like five years from now.

But I can prepare myself to adapt to it.

That is what being ready for anything means to me.

What Will I Learn Over the Next 5–6 Months?

This bootcamp is going to challenge me across multiple engineering disciplines.

The learning journey includes:

• Software Engineering: Advanced Python, asynchronous programming, FastAPI, REST APIs, GraphQL, and testing.
• Cloud and DevOps: AWS, Docker, CI/CD pipelines, networking, and cloud deployments.
• Generative AI: LLM fundamentals, prompt engineering, structured outputs, and function calling.
• RAG and Vector Databases: Embeddings, Pinecone, Qdrant, hybrid search, reranking, and knowledge graphs.
• Multimodal AI: Vision Language Models, document processing, and advanced retrieval.
• Agentic AI: LangGraph, multi-agent orchestration, memory, human-in-the-loop workflows, and Model Context Protocol (MCP).
• Enterprise Integration: Connecting AI with existing enterprise systems, databases, APIs, Jira, and Slack.
• AI Security: OAuth, SSO, RBAC, prompt injection protection, and AI guardrails.
• Production AI: Observability, evaluation, reliability, tracing, and monitoring AI applications.

What excites me most is the opportunity to connect these technologies rather than learning each one in isolation.

The curriculum also includes two major hands-on projects:

OmniGuard — Secure AI Integration: Building an enterprise AI integration solution with secure database access, RAG, access controls, and security guardrails.

AuditMesh — Multi-Agent Compliance System: Developing a multi-agent system using LangGraph, MCP, human approvals, and production observability.

These projects will be an opportunity to apply engineering concepts to realistic enterprise challenges.

My Commitment: Learn Every Day, Build Every Day, Share Every Day

One thing I have learned from my previous learning experiences is that knowledge becomes more valuable when we apply it and share it.

For the next 5–6 months, I intend to document this journey consistently.

Not just the successful implementations.

I also want to share the challenges, debugging sessions, mistakes, failed experiments, and lessons learned along the way.

My daily learning updates will focus on three simple questions:

1. What did I learn today?

A simple explanation of the technical concepts I explored.

2. What did I build today?

Hands-on experiments, code, architectures, and working implementations wherever possible.

3. What challenges did I face, and how did I solve them?

Because real engineering is not about writing perfect code on the first attempt. It is about learning how to solve difficult problems.

I will continue documenting my experiences through technical blogs, LinkedIn updates, GitHub projects, and YouTube content.

My objective is not simply to complete another course.

I want to finish this journey with stronger engineering skills, practical projects, and a portfolio that demonstrates what I can actually build.

Why Am I Sharing This Journey Publicly?

Because I believe learning should not happen in isolation.

Someone might be starting their AI Engineering journey today.

Someone might be transitioning from DevOps to AI.

Someone might be wondering whether they need to learn new technologies after spending years working in traditional IT roles.

And someone might simply need a little motivation to start learning again.

If my daily experiments, mistakes, and discoveries can help even one person move forward, sharing this journey will be worthwhile.

I am not positioning myself as an expert in everything I am about to learn.

I am a learner, documenting the journey of becoming a better engineer, one day at a time.

The Journey Begins Now!

The next 5–6 months will require discipline, consistency, patience, and plenty of hands-on practice.

There will be difficult concepts.

There will be broken code.

There will be moments when things don’t work as expected.

But that is part of the journey.

I am looking forward to discovering how far I can push my existing engineering skills into the world of AI-powered enterprise solutions.

My philosophy remains unchanged:

Keep learning. Keep building. Keep sharing. Keep evolving.

And most importantly:

Don’t prepare yourself for just one job title. Prepare yourself to solve whatever engineering challenges the future brings.

So, keep an eye on this space!

Every day, I will be sharing what I am learning, what I am building, and how I am progressing toward becoming a Forward Deployed Engineer.

Let’s see what we can build over the next 5–6 months!

#ForwardDeployedEngineer #FDE #AIEngineering #AgenticAI #GenerativeAI #DevOps #PlatformEngineering #SRE #1000DaysOfLearning #ContinuousLearning #BuildInPublic #KrishNaikAcademy

LangChain and LCEL is useful in connecting an LLM with prompts, databases, and other components.

What is LangChain?

LangChain is an open-source framework that helps developers build applications powered by Large Language Models (LLMs).

Instead of writing everything from scratch, LangChain provides reusable components to connect:

• LLMs: Generate answers using AI models.
• Prompt Templates: Structure instructions sent to models.
• Retrievers: Fetch relevant information from external sources.
• Output Parsers: Convert model responses into usable formats.
• Tools: Allow AI applications to interact with external systems.

For example, imagine building an AI chatbot that answers questions using your company’s documents.

LangChain helps connect document retrieval, prompt creation, and answer generation into one workflow.

And LCEL connects these components efficiently?

What is LCEL?

LCEL stands for LangChain Expression Language.

LCEL is a declarative way to connect LangChain components and create execution pipelines called chains.

Think of LCEL as an assembly line in a factory.

Each component performs a specific task and passes its output to the next component.

LCEL uses the pipe operator (|) to connect components.

For example:

chain = prompt | model | output_parser

Here:

1. The prompt prepares instructions.
2. The model generates a response.
3. The output parser formats the result.

Each step automatically receives the previous step’s output.

Building Your First LCEL Chain

Let’s create a simple application that explains technical concepts.

First, install the required packages:

pip install -U langchain-core langchain-openai

Set your OPENAI_API_KEY environment variable, then write:

from langchain_core.prompts import ChatPromptTemplatefrom langchain_core.output_parsers import StrOutputParserfrom langchain_openai import ChatOpenAI# Create a promptprompt = ChatPromptTemplate.from_template(    "Explain {topic} in simple English.")# Initialize the language modelmodel = ChatOpenAI(model="gpt-4.1-mini")# Create the LCEL chainchain = prompt | model | StrOutputParser()# Execute the chainresponse = chain.invoke({"topic": "Kubernetes"})print(response)

The application sends the topic to the prompt, passes the formatted instructions to the LLM, and converts the response into a Python string.

All three components work together through one chain.

Why is LCEL Useful?

LCEL offers several important benefits.

1. Simple and readable code

Developers can connect components without writing complicated orchestration logic.

2. Reusable components

The same prompt, model, or parser can be reused across different applications.

3. Streaming support

Using stream(), applications can display generated output progressively instead of waiting for the complete response.

4. Parallel execution

LCEL supports running independent operations concurrently using components such as RunnableParallel.

5. Asynchronous and batch processing

Developers can process requests using ainvoke() or multiple inputs using batch().

These capabilities make LCEL particularly useful when building RAG pipelines, document-processing systems, and other LLM workflows.

Final Thoughts —

LangChain provides the building blocks for developing AI applications, while LCEL provides a simple way to connect those blocks.

Instead of writing complex code to manage every operation, developers can create readable and reusable pipelines.

For beginners learning AI Engineering, LCEL is an important concept because it introduces how prompts, models, retrievers, and output parsers work together.

Although newer LangChain agent workflows often use LangGraph-based orchestration, LCEL remains useful for composing straightforward chains.

The key takeaway: LangChain gives us the components. LCEL helps us connect them into working AI applications.

The answer lies in understanding two important concepts: Parametric Memory and Non-Parametric Memory.

These concepts form the foundation of Retrieval-Augmented Generation (RAG), a technique that helps AI systems generate more accurate, relevant, and knowledge-grounded responses.

The Research Behind RAG

In 2020, researchers from Facebook AI Research (FAIR), along with collaborators, published a research paper titled:

“Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”

The paper introduced an architecture combining two different types of memory to improve language generation.

Let’s understand both concepts using simple examples.

1. What Is Parametric Memory?

Parametric memory refers to knowledge learned and encoded within a language model’s parameters (weights) during training.

Imagine preparing for an examination. You read several books, understand concepts, and remember information.

During the examination, you answer questions using what you have learned without opening those books.

This is similar to parametric memory.

For example, ask an LLM:

“What is Kubernetes?”

The model generates an explanation using patterns and knowledge learned during training.

However, parametric memory has limitations:

• Knowledge may become outdated after training.
• Updating knowledge generally requires additional training.
• Models can generate incorrect information, called hallucinations.
• Private organizational information is unavailable unless incorporated through training or provided as context.

2. What Is Non-Parametric Memory?

Non-parametric memory refers to knowledge stored outside the language model and accessed through retrieval.

Imagine taking an open-book examination.

Instead of depending entirely on memory, you search your textbook, locate relevant information, and prepare your answer.

This is similar to non-parametric memory.

In RAG systems, external knowledge may include documents, databases, technical manuals, and company policies.

For example, consider asking:

“What is our company’s Kubernetes deployment policy?”

The language model might not know your company’s internal policies.

However, a RAG system can retrieve the relevant document and provide it to the model as context.

This enables the model to answer using organization-specific knowledge without retraining.

3. How RAG Combines Both Memories

The original Facebook research used:

• Parametric Memory: A pretrained BART sequence-to-sequence language model.
• Non-Parametric Memory: A dense vector index of Wikipedia passages accessed through Dense Passage Retrieval (DPR).

The workflow is straightforward:

1. A user submits a question.
2. A retriever searches external knowledge.
3. Relevant passages are retrieved.
4. The language model combines the question with retrieved information.
5. The model generates an answer.

The retriever supplies relevant knowledge, while the language model interprets that knowledge and generates natural-language responses.

4. Why Does This Matter for AI Engineers?

Understanding these memory types helps AI engineers build applications that use private data, support frequently updated knowledge, improve answer traceability, and reduce hallucination risks.

However, RAG does not guarantee correctness. Retrieval quality and source reliability remain critical.

Conclusion

Parametric memory is what an AI model has learned. Non-parametric memory is what it can retrieve.

RAG combines both approaches to build more useful, adaptable, and knowledge-grounded AI applications.

Research Reference: Patrick Lewis et al. (2020), Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020.

Research paper: https://arxiv.org/abs/2005.11401

So how can an AI system understand that words like “car”, “vehicle”, and “automobile” have similar meanings?

The answer is Embedding.

What Is an Embedding?

An embedding is a way of converting information such as text, images, audio, or documents into a list of numbers called a vector.

For example, imagine these sentences:

• “I like Kubernetes.”
• “I enjoy working with containers.”
• “The weather is sunny today.”

An embedding model converts each sentence into something similar to:

"I like Kubernetes"
→ [0.21, -0.45, 0.72, 0.18, ...]

"I enjoy working with containers"
→ [0.25, -0.40, 0.68, 0.20, ...]

"The weather is sunny today"
→ [-0.62, 0.31, -0.15, 0.79, ...]

Real embeddings can contain hundreds or even thousands of numbers.

The important idea is that similar information gets similar vectors.

Therefore, the vectors representing Kubernetes and containers may be closer to each other than the vector representing weather.

Why Do We Need Embeddings?

Traditional computers are very good at exact matching.

Suppose a user searches:

How do I monitor Kubernetes?

A document may contain:

Observability helps engineers track the health of containerized workloads.

The exact words are different, but the meaning is related.

A traditional keyword search may not always understand this relationship. Embeddings allow systems to compare meaning instead of only matching words.

Embeddings are therefore widely used in:

• Semantic search
• Recommendation systems
• Retrieval Augmented Generation (RAG)
• Document search
• Chatbots
• Image search
• Similarity detection
• Classification systems

How Are Embeddings Created?

Embeddings are normally generated using a trained machine learning model.

The basic process looks like this:

Input
   ↓
Embedding Model
   ↓
Numerical Vector

For example:

"Kubernetes manages containers"
        ↓
Embedding Model
        ↓
[0.34, -0.12, 0.81, 0.42, ...]

During training, embedding models learn patterns and relationships between words, sentences, and concepts.

Words or sentences with similar meanings are placed closer together in a mathematical space.

You can imagine this like a huge map.

On this map:

Docker ─ Kubernetes ─ Containers

Python ─ Java ─ Programming

Apple ─ Banana ─ Mango

Concepts with similar meanings appear near each other.

The distance between vectors can then be measured using techniques such as cosine similarity, Euclidean distance, or dot product.

Popular Embedding Algorithms and Models

Several techniques have been developed to generate embeddings.

Word2Vec is one of the earliest popular techniques. It creates numerical representations of individual words based on the words appearing around them.

GloVe, or Global Vectors for Word Representation, creates word embeddings by studying how frequently words appear together across large amounts of text.

FastText, developed by Facebook AI Research, improves on traditional word embeddings by also considering parts of words. This can help with uncommon or misspelled words.

Modern applications commonly use transformer-based embedding models.

Sentence-BERT generates embeddings for complete sentences and paragraphs, making it useful for semantic search.

Other modern embedding models are available from providers and projects such as OpenAI, Google, Cohere, Hugging Face, and many open-source communities.

What Is a Vector Database?

Once we generate thousands or millions of embeddings, we use vector database to store them and search them efficiently.

A vector database is designed to store vectors and quickly find vectors that are mathematically similar.

The architecture is simple:

Documents
    ↓
Embedding Model
    ↓
Vectors
    ↓
Vector Database
    ↓
Similarity Search

Suppose a user asks:

How can I troubleshoot Kubernetes pods?

The question is converted into an embedding.

The vector database then compares that vector with stored document vectors and returns the documents with the closest meaning.

This is one of the main building blocks of RAG systems.

Why Use a Vector Database?

A normal relational database is excellent for queries such as:

SELECT * FROM users WHERE country = 'Netherlands';

But AI applications often need a different type of query:

Find documents that mean something similar to this question.

Searching millions of high-dimensional vectors efficiently requires specialized indexing and similarity-search techniques.

Vector databases are designed for this purpose.

Types of Vector Databases

There are several approaches.

Dedicated vector databases are designed primarily for vector search. Examples include Pinecone, Milvus, Weaviate, and Qdrant.

Traditional databases with vector support add vector capabilities to existing database systems. A popular example is PostgreSQL with the pgvector extension.

Search engines with vector search combine traditional keyword search with semantic vector search. Examples include Elasticsearch and OpenSearch.

There are also local libraries such as FAISS, which are commonly used for experimentation and smaller AI projects, although they are better described as vector-search libraries rather than complete databases.

Summary

Embeddings provide the bridge between human meaning and machine mathematics.

They convert text, images, and other information into vectors that machines can compare.

Vector databases store these vectors and allow AI applications to find information based on similarity and meaning rather than exact keywords.

Together, embeddings and vector databases form an important foundation for modern AI applications, especially semantic search, recommendation systems, AI assistants, and Retrieval Augmented Generation.

A simple way to remember the complete flow is:

Data → Embedding Model → Vector → Vector Database → Similarity Search → Relevant Information

Understanding this flow is important step toward understanding how modern RAG and Generative AI applications work.

We can ask questions, write code, summarize documents, create content, and solve problems using natural language.AI chatbots can write poems and explain code, but ask one about your company’s leave policy and it will guess. RAG is the simple idea that fixes this: let the AI look things up before it answers.

But before understanding RAG — Retrieval-Augmented Generation, it is useful to understand where language models came from and, more importantly, why they need technologies such as RAG.

It Starts with NLP

Natural Language Processing (NLP) is a field of Artificial Intelligence that helps computers understand, process, and generate human language.

For example, NLP can help computers:

• Understand a question
• Translate languages
• Analyze sentiment
• Summarize documents
• Extract information from text
• Generate human-like responses

Earlier NLP systems relied heavily on predefined rules and traditional machine-learning algorithms.

Modern AI systems use language models that learn patterns from enormous amounts of text.

This brings us to Small Language Models and Large Language Models.

Small Language Models vs Large Language Models

Language models come in two broad sizes. Size is measured in parameters, the internal “settings” a model learns during training. More parameters usually means more knowledge and skill, but also more cost.

A Small Language Model (SLM) is a relatively smaller AI model.

SLMs usually require fewer computing resources and can often run on laptops, edge devices, or smaller servers.

They can be useful when we need:

• Lower infrastructure cost
• Faster responses
• Better privacy
• Specialized tasks
• Local AI applications

A Large Language Model (LLM) is trained with much larger datasets and generally has significantly more parameters.

Models such as GPT and other modern generative AI systems fall into this broad category.

LLMs are powerful because they can perform many different tasks:

Question answering → Coding → Writing → Translation → Reasoning → Summarization

Think of an SLM as a pocket guidebook and an LLM as a whole library. Both are useful, and both have the same blind spots, as we will see next.

The Problem with Language Models

Imagine asking an AI assistant:

“What was the root cause of yesterday’s production incident in my company?”

The model may understand every word in your question.

But how would it know what happened inside your company’s production environment?

It probably cannot.

This exposes several important limitations.

1. Knowledge Cutoff

A language model learns information during its training process.

Think of its training data as a very large snapshot of knowledge.

If something happened after the model’s training data was collected, the model may not know about it.

For example:

Model Training
2019 ───── 2022 ───── 2025
                         │
                    Knowledge
                      Cutoff
                         │
                         ▼
                    New Events

The world continues changing after the model is trained.

2. Lack of Domain-Specific Knowledge

A general-purpose model may know Kubernetes, Linux, banking, healthcare, networking, and thousands of other subjects.

But it may not understand the details of your organization’s environment.

For example:

Company Kubernetes Architecture
Internal Deployment Process
Incident Runbooks
Custom APIs
Engineering Standards
Product Documentation

These may never have existed in the model’s training dataset.

3. No Access to Private Data

Organizations have huge amounts of valuable private information.

For example:

Internal Wiki
     +
Confluence
     +
SharePoint
     +
PDF Documents
     +
Databases
     +
Git Repositories
     +
Support Tickets

A public language model does not automatically know this information.

And in many cases, we do not want to train a completely new AI model using all of this information.

4. Answers May Not Come from Trusted Sources

A language model generates responses based on patterns learned during training.

It may produce an answer that sounds very convincing without showing where the information came from.

For enterprise applications, this can be a problem.

We often want answers based on trusted sources such as:

Official Documentation
Company Policies
Internal Knowledge Base
Product Manuals
Approved Procedures

Instead of relying only on the model’s internal knowledge.

5. Language Models Generate Probabilistic Outputs

LLMs do not work like traditional databases.

A database retrieves an exact stored value.

A language model generates the next most probable token repeatedly until it creates a response.

A simplified view is:

Input
  ↓
Language Model
  ↓
Probability of possible next words
  ↓
Generated Response

Parameters such as temperature influence this generation process.

Lower temperature generally makes the response more predictable.

Higher temperature allows more variation and creativity.

That is excellent for brainstorming or creative writing.

But when asking:

“What is our company’s production recovery procedure?”

we probably want accuracy and trusted information rather than creativity.

Why Not Simply Train Our Own LLM?

A natural question is:

Why don’t companies simply train an LLM using their own data?

Because training large models from scratch can be extremely expensive.

Large-scale training can require hundreds or even thousands of GPUs, depending on the model size and training strategy.

Imagine an infrastructure like:

Huge Dataset
     ↓
Hundreds of GPUs
     ↓
Days / Weeks of Training
     ↓
Huge Infrastructure Cost
     ↓
New Language Model

Training also requires expertise in:

• Machine learning
• Distributed computing
• GPU infrastructure
• Data preparation
• Model optimization
• Model evaluation

For most organizations and developers, building a new LLM from scratch is unnecessary.

Instead, we can use an existing language model and provide it with the right information when the question is asked.

This is where RAG becomes extremely useful.

What Is RAG?

RAG stands for:

Retrieval-Augmented Generation

Let us break those words down.

Retrieval

Find relevant information from an external knowledge source.

Augmented

Add that information to the user’s question as additional context.

Generation

Ask the language model to generate an answer using that context.

So instead of expecting the LLM to know everything, we first retrieve the knowledge it needs.

A simple RAG architecture looks like this:

               USER QUESTION
                       │
                       ▼
                ┌─────────────┐
                │  Retriever  │
                └──────┬──────┘
                       │
                       ▼
             ┌───────────────────┐
             │ Knowledge Source  │
             │                   │
             │ PDFs              │
             │ Documentation     │
             │ Wiki              │
             │ Database          │
             │ Company Data      │
             └────────┬──────────┘
                      │
               Relevant Information
                      │
                      ▼
               ┌─────────────┐
Question ─────►│     LLM     │◄──── Retrieved Context
               └──────┬──────┘
                      │
                      ▼
                 FINAL ANSWER

Consider our earlier question:

“What was the root cause of yesterday’s production incident?”

Without RAG:

Question
   ↓
LLM
   ↓
"I don't know your internal systems."

With RAG:

Question
   ↓
Search Internal Incident Reports
   ↓
Retrieve Yesterday's Incident Report
   ↓
Send Relevant Information + Question to LLM
   ↓
Generate Answer

Now the LLM does not need to have learned your incident report during training.

The information is provided when it is needed.

The Key Idea Behind RAG

RAG does not make a model perfect. If the search step finds the wrong documents, the answer will suffer. But it is the cheapest and fastest way to make a general AI useful with your own knowledge.

LLM
"What I learned during training"

             +

RAG
"What I can retrieve right now"

             =

More Context-Aware AI

This makes RAG extremely useful for building AI applications using:

• Company documentation
• Technical documentation
• Support knowledge bases
• Product manuals
• Internal engineering information
• Policies and procedures
• Frequently changing information
• Private organizational data

The quality of the final answer still depends on whether the system retrieves the correct information, how that information is provided to the model, and how the model is instructed to use it.

In short: LLMs are great at language, RAG gives them the facts. Try it on your own documents and see the difference.

Requirements → Design → Development → Testing → Deployment → Maintenance

That model is still relevant, but the environment around software has changed dramatically.

Applications are now cloud-native, API-driven, distributed, AI-enabled, highly integrated, and expected to evolve continuously. More importantly, companies are no longer asking only:

“Can we build this software?”

They are increasingly asking:

“Can we solve this business problem quickly, integrate the solution into our existing environment, make it intelligent, secure it, and operate it reliably?”

This evolution is creating a shift from the traditional Software Engineer, to the AI Engineer, and increasingly to the Forward Deployed Engineer (FDE).

Stage 1: The Software Engineer

A Software Engineer primarily focuses on building reliable software systems.

The traditional responsibility is to translate requirements into maintainable software:

Requirement → Architecture → Code → Test → Deploy → Maintain

Software Engineers typically have strong expertise in programming, data structures, APIs, databases, testing, system design, scalability and production-quality software.

Their priorities often include:

• Clean and maintainable code
• Testing
• Reliability
• Scalability
• System architecture
• Performance
• Long-term maintainability

The Software Engineer remains the foundation of modern technology organizations.

But AI has introduced another layer.

Stage 2: The AI Engineer

An AI Engineer takes software engineering principles and combines them with LLMs, machine learning models, retrieval systems and AI workflows.

The development lifecycle starts looking different:

Problem → Data → Model/LLM → Prompt → Retrieval → Evaluation → Application → Production

An AI Engineer may work with:

• LLM APIs
• Prompt engineering
• Embeddings
• Vector databases
• RAG
• Knowledge graphs
• Model evaluation
• Tool/function calling
• Agentic workflows
• Multimodal models
• AI observability

The challenge is no longer deterministic software alone.

Traditional code might behave like:

Input → Logic → Output

AI applications behave more like:

Input → Context → Model → Reasoning → Tools → Retrieval → Output

That introduces uncertainty.

Therefore, AI engineering requires new practices around evaluation, guardrails, hallucination management, retrieval quality, observability and AI security.

The role consequently places much more emphasis on applied AI and LLM systems than a traditional software-engineering position.

Stage 3: The Forward Deployed Engineer

The Forward Deployed Engineer takes this evolution one step further.

An FDE does not simply receive a well-defined requirement and implement it.

Often, the requirement itself needs to be discovered.

The lifecycle becomes:

Business Problem → Discovery → Requirements → Prototype → Architecture → Integration → Security → Production → Feedback → Business Outcome

This is fundamentally different.

Imagine a customer saying:

“We have thousands of internal documents, multiple databases, Jira, old SOAP services and several teams. We want AI to help employees find information and automate workflows — but users must only access information they are authorized to see.”

This is not simply a coding problem.

The engineer needs to understand the business workflow, enterprise data, existing infrastructure, security boundaries and expected outcome before deciding what should actually be built.

That is where the Forward Deployed Engineer becomes valuable.

An FDE may need to combine:

Python + APIs + Cloud + Containers + LLMs + RAG + Agents + Databases + Enterprise Integrations + IAM + Security + Observability

Enterprise integration becomes especially important because real organizations do not consist entirely of modern APIs. AI systems may need to interact with SQL databases, XML/SOAP services, Jira, collaboration platforms and existing internal systems. FDE BootCamp V1.0 (1)

Software Engineer vs AI Engineer vs FDE

The roles overlap significantly. The difference is primarily where each engineer spends their attention.

A Software Engineer asks:

How should we engineer this system?

An AI Engineer asks:

How can AI solve this problem reliably?

A Forward Deployed Engineer asks:

What is the actual problem, what should we build, and how do we make it work inside this customer’s environment?

The FDE role therefore tends to emphasize rapid prototyping, stakeholder interaction, applied AI, enterprise data and integration while still requiring strong system-architecture and production-engineering fundamentals.

The SDLC Is Becoming a Continuous Discovery Cycle

Perhaps the biggest change is that modern SDLC is becoming less linear.

Traditional SDLC:

Plan → Build → Test → Deploy

Modern AI-driven development:

Discover → Prototype → Evaluate → Integrate → Secure → Deploy → Observe → Learn → Improve

And then the cycle repeats.

For engineers, this means knowing one technology deeply is no longer enough.

The most valuable engineers will increasingly be those who can connect software, infrastructure, AI, security and business context.

That is why I see the Forward Deployed Engineer not as a replacement for Software Engineering or AI Engineering, but as an evolution in how engineering expertise is applied to real-world problems.

The future engineer in not asked:

“Can you build this?”

They are asked:

“Here is the problem. Can you figure out what we should build — and make it work in production?”

Thus, it changes the SDLC completely.

There was too much work, too many commitments, too many goals, and, most importantly, poor prioritization.

I kept pushing.

I kept telling myself that I could manage one more task, one more late evening, one more learning goal, one more responsibility.

But eventually, my body started sending a very clear signal:

Fatigue.

Not the normal tiredness that disappears after one good night of sleep.

It was persistent fatigue. The kind where you wake up tired, work tired, think tired, and end the day completely drained.

That experience forced me to reconsider something I should have understood much earlier:

Health cannot be one item on your priority list. Health is the foundation that makes every other priority possible.

When Productivity Starts Working Against You

There is nothing wrong with ambition.

There is nothing wrong with working hard, learning continuously, building a career, earning certifications, creating content, or trying to improve your life.

The problem begins when achievement starts consuming the very system responsible for producing those achievements: your body and mind.

For some time, I was optimizing almost everything except my health.

Work needed attention.

Learning needed attention.

Career goals needed attention.

Personal projects needed attention.

Content creation needed attention.

But sleep could be reduced.

Exercise could wait.

Meditation could be skipped.

Meals could become whatever was convenient.

Water could be forgotten.

Rest could happen “after everything was finished.”

The problem is that everything is never finished.

There will always be another email, another course, another certification, another project, another meeting, another goal.

If health continuously receives whatever time remains after everything else, eventually there may be very little health left to support everything else.

Fatigue Is Information

One important lesson I am taking from this period is that persistent fatigue should not automatically be treated as something to defeat with more coffee, motivation, or discipline.

Sometimes fatigue is information.

It may be telling you that your workload, recovery, sleep, nutrition, stress, or priorities need attention.

Persistent exhaustion can also have medical causes, so prolonged or unexplained fatigue deserves proper medical evaluation rather than being self-diagnosed as burnout.

But from a lifestyle perspective, I realised something important:

My current way of operating was not sustainable.

And sustainability matters.

A person who works at maximum intensity for three months and collapses is not necessarily more productive than someone who works consistently for three years.

Long-term success requires recovery.

Health Is Not Separate From Performance

We often think about health and productivity as two separate topics.

They are not.

Sleep affects concentration.

Exercise affects energy.

Hydration affects physical and cognitive performance.

Food affects recovery and overall wellbeing.

Rest affects your ability to think clearly.

Stress management affects how you respond to difficult situations.

When these foundations become weak, everything built on top of them becomes harder.

Learning becomes slower.

Decision-making becomes poorer.

Patience decreases.

Creativity decreases.

Focus becomes inconsistent.

Even small tasks begin to feel unnecessarily difficult.

That is why my approach is changing.

I am not abandoning ambition.

I am rebuilding the system that supports it.

My New Priority System

As I return to learning with full time of demanding work, and building things again, I am doing it differently.

These are the principles I want to protect.

1. Sleep Enough

Sleep is no longer something I want to sacrifice casually for productivity.

There will always be occasions where life disrupts sleep, but consistently cutting sleep to create more working hours is a poor trade.

Those additional hours may exist on the clock, but they often come with worse focus, weaker memory, slower thinking, and reduced recovery.

My goal is simple:

Respect sleep as part of the work, not as time away from the work.

2. Exercise Consistently

Exercise is not only about appearance.

It is about maintaining the physical capacity required to live an active life.

A career may be built at a desk, but a life cannot be lived entirely from a chair.

Walking, strength training, mobility, cardio, or any sustainable form of movement matters.

The goal does not have to be extreme.

The goal is consistency.

3. Meditate and Create Mental Space

A constantly stimulated mind rarely gets an opportunity to reset.

Work notifications, phones, social media, meetings, learning platforms, messages, and endless information can keep the brain permanently occupied.

Meditation is one way I want to deliberately create space between stimulus and response.

Even a few quiet minutes can be valuable.

Not because meditation magically removes every problem, but because awareness helps us notice when life is becoming unnecessarily chaotic.

4. Hydrate Regularly

This sounds almost too simple to mention.

Yet when work becomes intense, basic habits are often the first things to disappear.

Hours can pass between meetings, debugging sessions, writing, or studying without drinking enough water.

So hydration needs to become intentional rather than accidental.

Simple habits matter because health is largely built from repeated ordinary actions.

5. Treat Healthy Food Like Medicine

One mindset I am adopting is:

Eat clean, nutritious food as if it were part of your medicine.

Food should support the life you are trying to build.

That means prioritizing balanced, minimally processed meals where practical, along with enough protein, vegetables, fruit, whole foods, and sensible portions.

Perfection is unnecessary.

Consistency matters much more.

Your body has to process everything you give it.

It deserves quality inputs.

6. Prioritize Better

This may be the most important lesson.

Many problems that look like time-management problems are actually priority problems.

When everything becomes important, nothing is truly prioritized.

I want to ask myself more frequently:

Does this really need to be done today?

Does this really need to be done by me?

What happens if this waits?

Is this task worth sacrificing sleep, exercise, recovery, or family time?

Very often, the answer will be no.

7. No More Normalizing Overtime

There may occasionally be emergencies.

There may be production incidents.

There may be deadlines that genuinely require extra effort.

But extraordinary effort should remain extraordinary.

It should not quietly become the standard operating model.

Working additional hours continuously is not proof of commitment.

Sometimes it is evidence that capacity, expectations, planning, boundaries, or prioritization need to change.

My new rule is simple:

No routine overtime.

Work should have boundaries.

Recovery should have boundaries too.

The Goal Is Not to Slow Down

This experience has not reduced my desire to learn.

In fact, I am coming back to learning with more clarity.

I still want to study.

I still want to build.

I still want to create.

I still want to improve professionally and personally.

But this time, I want progress that I can sustain for years.

There is a huge difference between intensity and consistency.

Intensity asks:

How much can I achieve this week?

Consistency asks:

What kind of life can I continue living for the next ten years?

I am increasingly interested in the second question.

Your Body Eventually Collects the Debt

You can postpone sleep.

You can skip workouts.

You can live on convenience food.

You can ignore stress.

You can work long hours.

You can postpone rest.

For some time, everything may appear fine.

But the body has a way of collecting unpaid debt.

Sometimes the payment arrives as exhaustion.

Sometimes as loss of concentration.

Sometimes as irritability.

Sometimes as declining motivation.

And sometimes through health problems that are far more serious.

I would rather respond to the early signals than wait for louder ones.

Health Is the Infrastructure of Your Life

Coming from a technology mindset, this is perhaps the easiest way for me to understand it.

We spend enormous effort designing reliable systems.

We build redundancy.

We monitor CPU, memory, latency, disk usage, and error rates.

We define thresholds.

We create alerts.

We perform capacity planning.

We avoid running systems continuously at 100% utilization because we know there is no room for unexpected load.

Yet many of us operate our own lives at maximum capacity.

No buffer.

No recovery.

No redundancy.

No maintenance window.

And then we are surprised when the system becomes unstable.

Our bodies deserve at least the same level of care we give production systems.

My New Operating Model

So as I restart this journey, my priorities are becoming much clearer:

Sleep enough.

Exercise regularly.

Meditate.

Hydrate properly.

Eat clean and healthy food.

Prioritize ruthlessly.

Avoid unnecessary overtime.

Rest without guilt.

And then:

Learn.

Build.

Create.

Grow.

Because health does not compete with success.

Health enables it.

I still have many things I want to accomplish.

But I no longer want to achieve them at the expense of the person who has to live with those achievements.

This time, the goal is not simply to achieve more.

The goal is to become healthier, stronger, calmer, and more sustainable while doing it.

Because no career achievement, certification, promotion, project, or financial goal is worth consistently sacrificing your health.

Health comes first. Everything else has to fit around it.