If you have been building with Large Language Models over the last two years, you have likely walked the same path as the rest of us. You started with a simple API call to GPT-5 or similar. Then, you realized the model didn’t know about your company’s private data or the events of last week. So, you built a simple Retrieval-Augmented Generation (RAG) pipeline: chunk a PDF, throw it into a vector database, look up the top-3 similar chunks, and feed them to the LLM. It felt like magic until you put it into production.

Suddenly, the cracks appeared. Users asked vague questions, and the vector search returned noise. They asked complex comparison questions, and the system failed because the answer wasn’t in a single chunk. Or worse, the model confidently hallucinated an answer based on irrelevant retrieval results.

We are now in the Post-Naive RAG era. The industry has moved beyond simple semantic search into complex, architectural patterns designed to handle ambiguity, reason over data, and self-correct. We aren’t just building pipelines anymore; we are building cognitive architectures.

This post is a deep technical dive into these emerging architectures. We will look at GraphRAG, which structures data for global reasoning; Speculative RAG, which trades compute for speed and accuracy; Agentic RAG, which gives the model autonomy; and Adaptive RAG, which routes traffic like a smart load balancer. We will explore the why and how of each pattern, looking at the algorithms, the implementation strategies, and the hard trade-offs you will face as a developer.

Naive RAG and the Bag of Chunks Problem

Before we appreciate the complex architectures, we need to understand exactly why the baseline fails. Naive RAG is the standard Retrieve-then-Generate workflow.

The Architecture

The workflow is linear and rigid

1. Indexing: You take your documents, split them into fixed-size chunks (e.g., 512 tokens), and embed them using a model like OpenAI’s text-embedding-3-small or similar

2. Retrieval: The user’s query is embedded. You perform a k-Nearest Neighbors search in the vector space using Cosine Similarity.

3. Generation: You take the top k chunks (usually 3 to 5), paste them into a prompt template and hit the LLM generation endpoint.

While this works for simple lookup tasks, it treats knowledge as a bag of chunks and can lead to a couple of problems

• Semantic Mismatch: A user might ask, “What goes wrong when the engine overheats?” The document might say, “Thermal throttling induces system shutdown.” A naive vector search might miss this connection if the embedding model hasn’t seen that specific terminology linkage.

• The Lost in the Middle Phenomenon: LLMs are not perfect readers. Research shows that models tend to focus on the beginning and end of their context window. If the crucial answer is buried in the middle of retrieved chunk #3 out of 5, the model might ignore it.

• Lack of Global Context: If you ask, “What are the main themes in this 100-page report?”, Naive RAG fails. It will retrieve 5 random chunks mentioning “themes” or specific details, but it cannot “read” the whole document to synthesize a summary. It suffers from a narrow field of view.

These limitations have driven the research community to develop the Advanced and Modular patterns we will discuss next.

Pre-Retrieval Optimization

The first line of defense against bad RAG performance is better inputs. If the user asks a bad question, a vector database will give you bad answers. Pre-retrieval strategies focus on Query Transformation - rewriting the user’s intent into a format the machine understands better.

RAG-Fusion: Multi-Query Triangulation

One of the most robust patterns to emerge is RAG-Fusion. It addresses the problem of user queries being too specific, too vague, or just poorly phrased.

The Developer’s Perspective: Imagine a user asks, “Why is the system slow?” In your vector DB, the relevant docs might be about “latency,” “throughput bottlenecks,” or “database locking.” A single query for “slow” might miss the “locking” document entirely.

How RAG-Fusion Works

1. Query Generation: Instead of searching for the user’s raw query, we use an LLM to generate N (usually 3-5) variations of that query from different perspectives.

   • User Query: “Why is the system slow?”

   • Generated Q1: “Common causes of latency in the application.”

   • Generated Q2: “Database locking and performance bottlenecks.”

   • Generated Q3: “Network throughput issues in the infrastructure.”

2. Parallel Vector Search: We run all these queries against the vector database. This casts a wider net, retrieving a diverse set of documents that might not overlap.

3. Reciprocal Rank Fusion (RRF): Now we have 5 lists of documents. We don’t just append them; we fuse them. RRF is a standard algorithm from information retrieval that ranks documents based on their position in multiple lists. If “Doc A” appears in the top 3 for all generated queries, it’s highly likely to be relevant.

The score for a document d is calculated as:

where k is a smoothing constant (often 60) and rq(d) is the rank of the document in query q’s list.

HyDE: Hypothetical Document Embeddings

HyDE takes a fascinating approach: “Fake it till you make it.”

The Problem: Vector search works best when the query and the document look similar. But a question (”How do I reset my password?”) looks very different from a procedural document (”To initiate a credential reset, navigate to settings...”). They have different lengths, structures, and vocabularies. This is the semantic gap.

The HyDE Solution

1. Hallucinate an Answer: We ask an LLM to write a hypothetical answer to the user’s question. We don’t care if the facts are wrong; we care about the patterns.

   • Prompt: “Write a short passage explaining how to reset a password in this system.”

   • Hypothetical Doc: “To reset your password, go to the user profile tab, click on security settings, and select the ‘Forgot Password’ link. You will receive an email...”

2. Embed the Hallucination: We encode this hypothetical document into a vector.

3. Retrieve Real Documents: We search the vector DB using this vector.

The hypothetical document is semantically much closer to the real manual than the user’s short question was. It acts as a bridge. HyDE aligns the retrieval task to be Answer-to-Answer rather than Question-to-Answer.

Semantic Routing

Sometimes, you don’t need RAG at all. If a user says “Hi”, retrieving documents is a waste of money. Semantic Routing acts as a traffic controller.

The mechanism works as such. You train a classifier (or use a zero-shot LLM call) to categorize the incoming query into buckets:

• Chit-chat: Route to a simple LLM (no RAG).

• Fact Retrieval: Route to Vector Search.

• Summarization: Route to a specialized summarization pipeline.

• Coding: Route to a code-specialized model.

This is the first step towards Adaptive RAG, which we will discuss later. It prevents the system from blindly running expensive retrieval pipelines for every input.

Post-Retrieval Optimization

Once you have retrieved a set of documents, your job isn’t done. The raw results from a vector database are often noisy. You might get 20 documents, but only 3 are useful. Post-retrieval steps refine this context.

Reranking: The Quality Filter

This is arguably the highest ROI upgrade you can make to a Naive RAG system.

Regular Vector search is fast but fuzzy. It compresses all meaning into a single vector. A Cross-Encoder is a different type of model (like a BERT classifier) that takes a pair of texts (Query, Document) and outputs a similarity score from 0 to 1.10

The Workflow

1. Retrieve Wide: Instead of getting top-5 documents, get top-50 from the vector DB.

2. Rerank: Pass all 50 pairs (Query + fetched documents) through the Cross-Encoder.

3. Sort and Slice: Sort by the new score and take the top-5.

Cross-Encoders are much more accurate than vector similarity because they can “pay attention” to the interaction between specific words in the query and the document. The trade-off is latency - running a Cross-Encoder on 50 documents takes significantly longer than a vector lookup. But for precision-critical apps (like legal search), it is non-negotiable.

Context Compression and Selection

Feeding 10,000 tokens of context to the LLMs is expensive and slow. Context Compression helps to reduce this load without losing information.

Couple of techniques that help us do this are:

• LLMChainExtractor: Using a smaller LLM to read the retrieved document and extract only the sentences relevant to the query, discarding the rest.

• Embeddings-based Filtering: Removing documents that are below a certain similarity threshold (e.g., discarding anything with a cosine similarity < 0.7).

This ensures that the final prompt sent to the generator is dense with signal and low on noise, which reduces hallucination risks.

GraphRAG

GraphRAG fundamentally changes how we index data. It moves away from flat lists of text chunks and towards structured relationships.

Vector RAG is great for “Needle in a Haystack” queries. It is terrible for Global Understanding queries. If you ask, “How do the relationships between the factions in this story evolve?” a vector search will find you snippets where factions are mentioned. It won’t find you the evolution or the structure of the conflict.

Building the Graph

GraphRAG, specifically the approach championed by Microsoft Research, uses an LLM to build a Knowledge Graph (KG) during the indexing phase.

The Pipeline

1. Source Parsing: Documents are split into chunks.

2. Extraction: An LLM processes each chunk to extract Entities (People, Places, Organizations) and Relationships(e.g., “Person A works for Organization B”).

3. Graph Construction: These form a graph structure (Nodes and Edges) stored in a graph database like Neo4j.

4. Community Detection: This is the sauce. The system uses algorithms like Leiden (a hierarchical clustering algorithm) to group nodes into communities.

   • Level 0: All nodes.

   • Level 1: Broad clusters (e.g., “Tech Companies,” “Regulatory Bodies”).

   • Level 2: Tighter clusters (e.g., “AI Startups in SF”).

5. Community Summarization: The LLM generates a summary for each community.

Global Search Mechanism

When a user asks a high-level question (”What are the major market trends in this dataset?”):

1. The system does not search the raw text chunks.

2. It searches the Community Summaries.

3. Because these summaries are hierarchical, the system can answer at the appropriate level of abstraction.

4. It synthesizes these summaries into a global answer.

Speculative RAG: Need for Speed

In production, latency is a killer. Users may dislike waiting 5 seconds for an answer. Speculative RAG is an architectural pattern designed to break the linear dependency of standard RAG to speed things up. It borrows the idea of “Speculative Decoding” from model optimization. The core idea is to separate the drafting of an answer from the verification of it.

The Roles

1. The Drafter (Specialist): A smaller, faster, perhaps fine-tuned model (e.g., Llama-3-8B).

2. The Verifier (Generalist): A larger, smarter model (e.g., GPT-5).

The Workflow

1. Parallel Drafting: Instead of one large prompt, we split our retrieved documents into subsets (e.g., 4 subsets of 2 docs each). We spawn 4 instances of the Drafter model in parallel. Each Drafter reads its small subset and generates a draft answer.

2. Verification: The Verifier looks at the question and the 4 draft answers. It doesn’t necessarily need to read all the original documents (saving tokens). It evaluates the drafts for consistency and rationale.

3. Selection: The Verifier picks the best draft or synthesizes them into a final answer.

You might think running 4 models is slower than 1. But because the Drafters run in parallel and use smaller context windows (fewer tokens), the Time to First Token and overall generation time can be significantly lower.

Research benchmarks on datasets like PubHealth show Speculative RAG can reduce latency by over 50% while actually increasing accuracy (by ~13%). The accuracy gain comes from the ensemble effect (remember Random Forests?) - multiple drafters looking at data from different angles reduce the chance of the model fixating on a single wrong detail.

The Critic: Self-Correcting Architectures

One of the biggest fears in RAG deployment is of Silent Failure. The system retrieves garbage, the LLM hallucinates an answer based on that garbage, and the user believes it. Self-Correcting RAG adds a feedback loop to catch these errors.

Corrective RAG (CRAG)

CRAG adds a lightweight Retrieval Evaluator (Relevance Checker) into the pipeline.

The Logic

1. Retrieve: Get documents.

2. Evaluate: A specialized model (often a T5 or small BERT-sized model) scores the relevance of the documents to the query.

3. Branching Decision:

   • Correct (High Confidence): Proceed to generation. Strip out irrelevant snippets.

   • Incorrect (Low Confidence): The retrieved docs are trash. Fallback: Trigger a web search or check a backup knowledge base. Do not use the bad docs.

   • Ambiguous: Combine the retrieved docs with a web search to fill in the gaps.

This simple Traffic Light - like system prevents the generator from ever seeing purely irrelevant context, which is the primary cause of hallucinations.

Self-RAG: Reflection Tokens

Self-RAG takes a different approach. Instead of an external evaluator, it trains the Generator LLM to critique itself.

Reflection Tokens: The model is fine-tuned to emit special tokens inside its generation stream:

• “I need more data for this next sentence.”

• “The document I just read is irrelevant.”

• “The sentence I just wrote is not supported by the evidence.”

• “This answer is useful for the user.”.

During inference, the model generates a thought, critiques it with a token, and if the token is negative (e.g., = False), it backtracks and regenerates. This happens at the token/sentence level, offering much finer-grained control than CRAG’s document-level filtering.

However, implementation is harder: you typically need to fine-tune your own model or use a specifically trained Self-RAG checkpoint

Adaptive RAG: The Manager

Adaptive RAG is about efficiency. Not every query needs a $0.05 web search and a complex graph traversal. Some queries just need a quick lookup. Adaptive RAG uses a Classifier to route queries to the cheapest effective pipeline.

Complexity Classification

The router analyzes the query and assigns a complexity level:

1. Simple (No Retrieval): “What is the capital of France?” -> Let the LLM answer from memory. Fast, free.

2. Moderate (Single-Step): “Who is the CEO of LangChain?” -> Vector Search -> Generate.

3. Complex (Multi-Step): “Compare the battery life of the iPhone 17 vs. Pixel 10 based on recent reviews.” -> This requires retrieving reviews for both, normalizing the data, and synthesizing.

Dynamic Routing Logic

In a framework like LangChain or LangGraph, you implement this as a conditional chain.

This architecture is critical for scaling. It optimizes your “Token Budget.” You spend your expensive compute only on the hard problems.

Tree of Clarifications

A sub-pattern of adaptive RAG handles Ambiguity. If a user asks “Who won the game?”, Adaptive RAG shouldn’t guess. The Tree of Clarifications architecture generates disambiguating questions (”Did you mean the NBA game last night or the World Cup final?”), constructs a tree of possible paths, retrieves info for each, and prunes the dead ends.

The Autonomous: Agentic RAG

If Adaptive RAG is a manager, Agentic RAG is an autonomous worker. It moves beyond pipelines (DAGs) to loops (Cyclic Graphs). This is the current frontier of RAG development.

The ReAct Loop

The core of Agentic RAG is the ReAct (Reason + Act) pattern.

The agent doesn’t just retrieve; it thinks.

1. Thought: The user wants to compare two stocks. I need the price of AAPL first.

   Action: Call Tool get_stock_price(”AAPL”).

   Observation: AAPL is $150.

2. Thought: Now I need the price of MSFT.

   Action: Call Tool get_stock_price(”MSFT”).

   Observation: MSFT is $300.

3. Thought: I have both. Now I will compare.

4. Final Answer: MSFT is double the price of AAPL.

Tool Use and Autonomy

In Agentic RAG, the “Retriever” is just one tool in a toolkit that might also include:

• Web Search (for real-time data).

• Calculator (for math, where LLMs fail).

• SQL Connector (for structured DBs).

The agent decides when to use the retriever. If the first retrieval is bad, the agent can observe that (”I didn’t find the answer”) and decide to rewrite the query and try again. This Retry Loop is what makes Agentic RAG so powerful—and so dangerous (infinite loops are possible!). For more on this, you can read my article below on AI agent tooling.

Chain-of-Note: Noise control

We talked about noise earlier, but Chain-of-Note (CoN) deserves its own section as a specific architectural remedy for the “Unknown” problem.

The Problem: Standard RAG is terrified of saying “I don’t know.” If you ask “Who is the King of Mars?” and the retriever brings back a document about the “King of Burgers,” a standard RAG model might hallucinate “The King of Mars is the King of Burgers.”

The CoN Solution: CoN forces the model to take notes before answering.

1. Read Doc 1: “This document talks about burgers. It is irrelevant to Mars.”

2. Read Doc 2: “This document discusses Mars geology. It mentions no monarchy.”

3. Synthesize: “Based on the notes, there is no information about a King of Mars. The retrieval results were irrelevant.”

This architecture drastically improves Robustness. It creates a “Null” state. It turns the model from a Sycohphant (always trying to please) into a Critic (assessing the validity of its own inputs).

Choosing Your Stack

With so many architectures, how do you choose? Here is a comparison guide that can help.

The Gold Standard Stack

If you are building an enterprise RAG system today, a robust starting point is often a hybrid

1. Routing: Adaptive front-end (don’t RAG everything).

2. Retrieval: Hybrid Search (Vector + Keyword) with Reranking

3. Architecture: Modular. Start with a linear pipeline. Upgrade to Agentic only for specific complex query types (using the Router).

4. Database: A store that supports both Vector and Metadata filtering (e.g., Pinecone, Weaviate, or pgvector).

The Road Ahead

The days of pip install langchain; qa_chain.run() are over. RAG has matured into a serious systems engineering discipline.

We are moving towards Cognitive RAG: systems that model the user’s intent, structure the knowledge globally (Graphs), and reason iteratively (Agents). The trade-offs are no longer just about accuracy; they are about

As a developer, your job is no longer just to connect the LLM to the DB. It is to architect the flow of thought. Whether you choose the structural rigor of GraphRAG or the dynamic flexibility of Agentic RAG, the goal remains the same: building systems that don’t just retrieve data, but actually understand it.

Welcome to the next generation of Intelligent Information Retrieval. Thank you so much for reading this super-long post, and I hope you have a wonderful day.

Welcome to the Agentic Era

Hello, and welcome to the deep end of the AI pool. If you are reading this, you are likely a software engineer who has moved past the “honeymoon phase” of Generative AI. You have played with chat prompts, maybe built a simple RAG (Retrieval-Augmented Generation) application using a few API calls, and now you are hitting a wall. The wall is determinism. You need your application to do more than just talk; you need it to act, adhere to business logic, and scale without hallucinating its way into a production incident.

This post is designed as a comprehensive, developer-to-developer tutorial on Google’s Agent Development Kit (ADK). We are going to move beyond simple scripts and build robust, production-ready multi-agent systems. The ADK is not just another wrapper around an LLM API; it is an opinionated framework designed to bring software engineering discipline—modularity, type safety, observability—to the probabilistic world of AI. This post has code that I’ve implemented on Github for you to run at your end.

Why ADK? The Code-First Philosophy

In the current landscape, you have options. You could use LangChain, which is fantastic for its breadth of integrations but can become “glue code hell” in production. You could use Firebase Genkit, which is excellent for adding AI features to full-stack apps but is less specialized for complex, autonomous agent hierarchies.

The ADK is different. It is built for complex multi-agent orchestration. It treats agents not just as prompts, but as software components with defined inputs, outputs, and state lifecycles. It allows you to define “How does this agent think?” separately from “What tools can this agent use?” and “Who does this agent talk to?”.

The ADK shines when you need predictability. By using primitives like SequentialAgent, ParallelAgent, and strict FunctionTool definitions, you constrain the LLM’s vast creative potential into a useful, reliable laser beam of utility.

Key capabilities

Agent Orchestration

You can structure complex agent behaviors using explicit controls like sequential, parallel, or looping workflows rather than relying solely on prompts. It enables hierarchical delegation, where a Manager agent can route specific sub-tasks to specialized Worker agents and synthesize their outputs. This combination of deterministic code structures and probabilistic LLM routing creates stable, multi-agent systems.

Web UI

The kit includes a local developer dashboard, often called ADK Web, which lets you chat with your agent and visually inspect its reasoning process in real-time. It provides a graphical trace of every step—from user input to specific tool calls—making it significantly easier to debug logic errors than reading raw logs. Newer features also support visual, drag-and-drop construction of agent workflows to speed up prototyping.

Tools & Capabilities

ADK supports the Model Context Protocol (MCP), enabling plug-and-play connections to external data sources like SQL databases or Slack without writing custom glue code. It also implements the Agent-to-Agent (A2A) protocol, allowing your ADK agents to communicate and negotiate tasks with agents built on completely different frameworks. Out of the box, it includes essential tools for grounded Google Search and sandboxed code execution.

API Server & Runtime

ADK allows you to deploy agents directly into the Vertex AI Agent Engine or as a standalone service, automatically exposing them as scalable, production-grade API endpoints. It supports standard frameworks like FastAPI for custom implementations while managing the complex, asynchronous request/response lifecycle. This setup handles long-running agent reasoning seamlessly without timing out connections or blocking the main thread.

Sessions & Memory

ADK treats memory as infrastructure, distinctly separating temporary conversation context from persistent user state and preferences. It integrates with Vector DBs to create a Memory Bank, allowing agents to programmatically save and semantically retrieve information across different sessions. This enables true long-term recall, allowing the agent to “remember” details from weeks ago rather than just the current chat window.

Ease of Deployment

ADK follows a “Code Local, Deploy Global” philosophy, ensuring that agents are container-ready and can be deployed to Vertex AI or Cloud Run with a single CLI command. You can also deploy an ADK server on any other cloud provider or on-prem depending on your needs.

Prerequisites and Setup

Before we write a single line of code, let’s get our environment ready. The ADK is a modern Python framework, and it demands modern tooling.

Hard Requirement: You must use Python 3.10 or higher. The ADK leverages advanced typing features available in newer Python versions, and trying to run this on Python 3.9 will result in immediate breaking errors.

I recommend using uv (a fast Python package manager) or standard venv.

Once installed, the ADK gives you a CLI tool (adk) that we will use later for deployment and local testing. But first, let’s understand the atoms that make up the universe.

The Atom of Intelligence: The Agent Class

In the ADK, an Agent is the fundamental unit of execution. It is not just a prompt; it is a container that holds:

1. Model Configuration: Which brain are we using? (e.g., Gemini 2.5 Flash).

2. Instruction (System Prompt): The personality and constraints.

3. Tools: The capabilities (functions, APIs).

4. Internal State: Context management.

Let’s build a “Hello World” agent, but let’s make it robust. We will use the Agent class to create a helpful coding assistant.

Your First Agent

Create a file named agent.py. This is the convention ADK expects for deployment later. Create this file

parent_folder/
    first_agent/
        __init__.py
        agent.py
        .env

Now write the following code in agent.py. You can find the code implementation in a Github Codespace here for easier access and experimentation at your end.

Deconstructing the Code:

• model: We specify the model ID string. ADK abstracts the API calls to Vertex AI or Google AI Studio.

• name: This isn’t just a label. In a multi-agent system, if a Manager agent wants to ask the Coding Buddy for help, it uses this name to route the request.

• instruction: This is your System Prompt. Notice the specific guidelines. In Agent Engineering, being prescriptive here is better than hoping the model figures it out.

We’ll need 2 more files apart from this

• __init__.py is an empty file that the ADK requires

• .env file is used to store your Gemini API Key, which can be created google AI studio. You can use a free Gemini API key for this example.

Ensure that your .env file contains the newly created Gemini API Key

echo ‘GOOGLE_API_KEY=”YOUR_API_KEY”’ > .env

If you’re getting an error stating that you’ve reached the end of free quota, it’s likely that your key isn’t getting picked up automatically and you should export the key to your shell with

export GOOGLE_API_KEY=”YOUR_API_KEY”

Once you’re ready, navigate to your parent folder and run the following command on your terminal.

adk web

And you’ll get the following screen. You can find the code shown in this example in my Github repository here and if you’d like you can even use Github Codespaces to spin it up without having to set up anything on your own computer.

Let’s dive deeper and build more complex use-cases.

Read more

If you’ve been building AI agents recently, you’ve probably hit the “lonely island” problem. You build a fantastic agent in CrewAI, your friend builds one in LangGraph, and I build one using Google’s Agent Development Kit (ADK). They are all brilliant, but they can’t talk to each other. They are siloed intelligent systems.

Google recently released the Agent to Agent (A2A) Protocol, and it might just be the “TCP/IP moment” for Agentic AI. Let’s dive into what this protocol is, how it works, and why it’s different from things like MCP.

What is the Agent to Agent (A2A) Protocol?

In simple terms, A2A is a standard that allows AI agents to communicate, collaborate, and exchange information regardless of how they were built or where they are running.

Think of it as HTTP for AI Agents. Before HTTP, computers had a hard time talking to different networks. A2A wants to do the same for agents. It doesn’t matter if your agent is a “customer support” bot written in Python or a “inventory manager” written in Java; if they speak A2A, they can work together.

The Core Problem It Solves

Right now, if I want my “Travel Planner Agent” to book a flight using your “Airline Booking Agent,” I usually have to write custom integration code. I need to know your API schema, your auth headers, and your specific quirks.

With A2A, my agent can just “discover” your agent, read its Agent Card (more on this later), and start a structured conversation to get the job done.

How Does It Actually Work?

The protocol is built on web standards we already know and love: HTTP, JSON-RPC, and SSE (Server-Sent Events). It’s not some obscure binary format; it’s just web requests.

Here is the high-level flow:

1. Discovery (The Agent Card): Every A2A-compliant agent hosts an agent.json file (the Agent Card) at a well-known URL. This is like a business card. It tells other agents:

   • “Hi, I’m the Weather Agent.”

   • “I can give you forecasts and historical data.”

   • “Here is how you authenticate with me.”

2. Handshake: My agent reads your card and understands your capabilities.

3. Task Execution: My agent sends a Task to your agent. This isn’t just a single prompt; it can be a long-running job.

4. Asynchronous Communication: Your agent might need to ask clarifying questions (”Which city?”). A2A handles this back-and-forth negotiation, including waiting for human input if needed.

A2A vs. MCP: What’s the Difference?

This is the most common question I see. “We already have Anthropic’s Model Context Protocol (MCP), why do we need this?”

It helps to visualize them as Vertical vs. Horizontal:

• MCP is Vertical (Agent ↔ Tool): MCP connects an agent to a database, a file system, or a GitHub repository. It gives the agent “hands” to do things.

• A2A is Horizontal (Agent ↔ Agent): A2A connects an agent to another agent. It allows for delegation and teamwork.

In a real-world scenario, you would use both. Your “Project Manager Agent” uses A2A to talk to a “Coder Agent.” That Coder Agent then uses MCP to access the GitHub API and write code.

Why You Should Care

1. No Vendor Lock-in: You aren’t stuck in the LangChain or Google ecosystem. You can mix and match.

2. Opaque Collaboration: You can use an external agent (like a payment processor agent) without needing to know its internal prompt engineering or logic. You just care about the result.

3. Standardization: We stop rewriting the same “how do I send a message” logic for every new agent framework.

Final Thoughts

We are moving away from single, god-mode agents toward multi-agent systems (MAS). The A2A protocol is a massive step toward making that ecosystem interoperable. It’s open-source (now with the Linux Foundation), which gives me hope that it will become a genuine standard rather than just a “Google thing.”

If you are building agents today, it is definitely worth looking into making them A2A compliant. It might just be the difference between building a tool and building a teammate. I’ve created a Github repository where I’ve been experimenting with the A2A protocol. Feel free to check it out if you like.

This week, on the 6th of October 25, OpenAI released AgentKit, a collection of tooling designed to make it easy to build and work with Agentic systems. There are 3 main components within this AgentKit ecosystem

1. Agent Builder

2. Connector Registry

3. ChatKit

This article focuses on the first part of the AgentKit ecosystem, which is the agent builder.

Agent Builder⁠ is a no/low code tool that provides a visual canvas for composing logic with drag-and-drop nodes, connecting tools, and configuring custom guardrails. It supports preview runs, inline eval configuration, and full versioning—ideal for fast iteration.

In a market that has increasingly seen the likes of Langflow, n8n, crewAI and other low/no code tools, agent builder is OpenAI’s version of this low/no code agent building SaaS. I spent some time digging into this platform and built a couple of agents with increasing levels of complexity.

Agent 1 - A simple web search agent

I built the first agent by connecting the start node, the agent node and the end node. The agent instructions were simple - use the necessary tools and craft a response. The tool that I added was OpenAI’s web search tool and the model that I used was GPT-5. You can see in the screenshots below how the setup looks like. This took me under 5 minutes, and the agent did a good job of answering the question on the weather in New York. Nice!

Agent 2 - Stock Market Analysis and Plotting

The second agent I built with the agent builder was to build a flow in which one agent would help me at doing market research about various company stocks. And the other agent would excel at generating plots. The overall high level design of nodes looks like the screenshot below

In the stock finder agent, I added the web search tool so that the agent could look up stock information from the internet. I added a structured response from my first agent in the following way. This is so that the later steps can reference these json fields and make deterministic decisions. (Not everything in an Agentic system needs to be non-deterministic.) The If/Else node will be utilizing this structured response to route the flow of execution further.

I then used the set state node to set a new variable named stocks_str to this structured output. You’ll see why this was a key step a bit later. I then added the If/Else node to check if the stock_name as a field was found in the output of the first agent. This would ensure that the plotting agent wouldn’t be triggered unless the stock data was found and was available for us to use.

Further, I added the second agent which is our plotting agent, and gave it access to Code Interpreter tool (which allows an agent to write it’s own python code, more here). To give it the context of the structured json, I added the following prompt which also contains the state.stocks_str that we had defined earlier. The passed context must be a string and hence the implementation.

You can see the final output in a 3 minute video below. The agentic workflow successfully found the stock price of Amazon for the last 6 months, and gave me the code to plot it using python. I wish it’d have rendered the code directly in-line but in my testing, I couldn’t get the plot to render on my screen. The widget output format didn’t work for me, even after I added a custom widget with graphs. I did however copy-paste the code in google colab and got a nice plot as you can see below.

My observations

1. The handling of conversion history is seamless. The agent remembers what the user chatted about and follow-up questions are answered without any development effort from the user.

2. MCP support is okay. The connectors from OpenAI at launch are very few and there’s a lot of work required to get them set up properly. MCP at launch does not support OAuth and the multiple users have reported connectors generally not working, which is something I assume will eventually be fixed in the future. However, this definitely does limit the kind of projects that I can build at launch. I was planning on building a 3rd more complex agent, but the general errors in the platform made it impossible to do so

3. Tools like these are more common than ever, and I’d argue that if your current workflow is living happily in n8n or similar, I see no reason to switch at the moment. The idea behind this one again is just OpenAI entering the game of low/no code agent builder SaaS. At this time, this platform does not have any strategic advantage except the name of OpenAI to back it up.

It’d be interesting to see how this integrates with chatkit and connector registry. I’ll be exploring that next and see what I can build with this. In the meantime, thank you so much for reading and I hope you have a wonderful day!

With the recent launch of GPT-5, a few weeks ago, we’ve started to see a decline in the expansion of capabilities of Large Language Models. While the benchmarks associated with GPT-5 look promising, some industry experts think that the actual implementation seems a bit more focused on cutting down costs and increasing optimizations for running at scale, at OpenAI. The question at this stage in AI research is how much more capable, are LLMs going to get, and with the recent research by Apple on the illusion of thinking, and the more recent MIT study highlighting the zero return obtained by 95% of organizations using AI, the question around the ROI of AI agents is ever-more relevant. How can we derive the value with these LLMs that we’ve built, and assuming that the pace of gains in LLM capabilities is going to slow down, how can we build AI solutions that deliver impact early and using the existing capabilities of LLMs, instead of their future promise.

The way I like to think of AI agents is to think of the large language model as the brain, and the tools as it’s arms and legs. You can have a great brain, but if you store that brain in a jar, there’s not much that the brain will be able to do. In the AI industry, people understood this problem fairly early, and we now have a plethora of tools and techniques to give our AI brains, capabilities for them to make a difference. But as I interact with people about their understanding of Agents, I find that not many people are really aware of the scope of tools that are available for these LLM brains to utilize. And your AI agent’s chance of delivering impact and value, highly depends upon your ability to provide it with the right tooling. This is what we’ll focus on in this article.

There are 5 types of tools that we’ll talk about in this article

1. Code Interpreter

2. Function calling

3. File Search

4. Web Search

5. MCP Servers

Code Interpreter

This tool can write it’s own code to solve specific problems. This is a very powerful capability as the LLM is provided a sandbox environment where it can run its code and do things that LLMs are bad at - like arithmetic problems. Suppose you want a large language model to compute compound interest for you. The large language model by itself does not have a good capability to do this for you, because it’s a language model. It can attempt to do this using some prompting technique like chain-of-thought etc, but generally, LLMs struggle a lot with arithmetic computations.

However, if the LLM can write it’s own code and run it in its own sandboxed runtime, it can potentially find the answer to most arithmetic problems extremely easily. With libraries like numpy and pandas available in python, data analysis is generally just a couple of lines of code, which the LLM can write and with this tool, run. The LLM can also generate plots and images for you, essentially acting as a super efficient data analyst, and with this, covers its limitation of not being natively good at arithmetic.

Function calling

This tool can choose which function in your codebase to call, and provide you with the right arguments to be passed to that function. The large language models acts as the decision making authority, choosing for you, which function in your codebase to call, depending upon the context. This is extremely powerful as well. Your functions written in C#, Java, or any programming language for that matter, can be utilized this way, and that is the point.

Traditional programming tells us what to do based on conditional statements like if-else statements. Machine learning solves specific problems after some kind of training - supervised or unsupervised. This is different as the LLMs come ready, out of the box with this functionality, and you don’t really need to change your programming stack to enable these capabilities. This is why, function calling has such a high potential of delivering value and remains one of the most impressive tools for modern agent development.

File Search

File search tool basically acts like a RAG - Retrieval Augmented Generation system. One of the most popular uses of LLMs is in RAG systems. And building these RAGs have never been simpler as they now essentially come as just another tool for LLMs to use, known as the file search tool. You can upload your own data in vector databases by uploading your own files like PDFs, word documents etc. This information is then stored in a vector database, fetched back by the retriever and curated by the LLM. RAGs used to be messy to build at one point of time, but the modern AI development landscape has made building RAG as simple as adding the file search tool to your LLM capabilities.

You can read more about RAGs over here at my article on RAG.

Web Search

All large language models today, have a cutoff date, on which their training dataset was cut-off. We solve the problem of giving the right context to an LLM through file search tool or an RAG, but what if we need something even more recent than what our RAG can offer. Also if we do not have information in our vector database, the LLM can use the web search functionality to figure out the right information it needs to make a decision and act on it. Web search allows a LLM to have access to a search engine the same way you and I run web searches. This addresses the cutoff date problem for LLMs, and makes them capable of knowing what is happening today, right now through search capabilities.

MCP Servers

The most recent, standard and industry accepted way of sharing information and context with LLMs is Model Context Protocol - MCP. It came out as a result of solving the frustrations seen at Anthropic (the company behind Claude LLM), while integrating LLMs with various other programs. It’s going to be a year since the inception of MCP and its safe to say that there’s very wide adoption of MCP across the industry. And for good reason, MCP solves the burning question - How to design AI systems such that they’re extensible, maintaining and discoverable. This means that sharing information from APIs, static files, blob storages, non-relational databases etc can be done in a standard way. MCP also defines server primitives that all servers can follow so that the users (MCP clients) can discover capabilities smartly. To learn about MCP more you can read my article on MCP in detail here.

When you put this together, you get something that looks like this diagram that I put together, below

This sums up the important pieces of tooling that enables AI agents to unlock capabilities never seen before in software engineering. These tools are the main reasons behind the automation capabilities of LLMs. Modern Agentic development hence, isn’t limited by the progress that we’re making on LLMs. We’re also making significant progress in tooling and as we make it easier and easier for these AI brains to use various types of tools, we should start seeing automation capabilities never seen before.

Everyone is talking about MCP. And until about two months ago, I didn’t understand it very well. With a ton of information coming from various sources, about how MCP is a “game-changer” and how it will revolutionize everything, I personally found it very hard to find content that helped me understand what MCP is. And I think we’re in such dearth of good quality sources of information these days, places that don’t “sell” an idea and instead help us understand the idea so that we ourselves can determine its worth. But that is a rant for some other day.

I went the rabbit hole of going through the documentation, discussions from industry experts and basically every good source that I could get my hands on, and well, understood MCP for what it is. And then I went ahead and started implementing my own MCP components and performed a bunch of interesting experiments with it. So if you find this topic interesting, let me tell you what I learnt and I’ll let you decide how impactful this is really going to be.

What is MCP?

MCP stands for Model Context Protocol. The term says it all. It’s a protocol. It’s a spec that was created by Anthropic, to standardize the way Large Language Models can get access to information and tools. Tooling is a big component of what truly makes these LLMs, behave like agents. If you’re new to AI agents, I’d recommend reading this article that I wrote earlier about what AI agents really are.

Compute - A programming blog

What are AI agents really?

We as humans have always been trying to make our computers do more and more things. In the last 40 years alone as a species, we’ve gone orders of magnitudes further in field of computing than we have in our entire 10,000+ year old history. We have developed cheap storage, better and faster compute every year. We optim…

Read more

a year ago · Anshaj

If you’re already comfortable with the idea that an AI agent is essentially a LLM with capabilities to interact with its environment (tools etc), this is where MCP really comes in.

MCP is an attempt to standardize the way LLMs can call these tools, access data etc. As a developer, for every single integration, you don’t need to reinvent the wheel about “how” to integrate your API, data source etc with a LLM to make it an agent. MCP is a “good” or a standard way to integrate your tooling with LLMs that the entire industry focused on AI can follow and make it easier for all of us to use each other’s tooling. Suppose you develop a new capability to have a relational database (SQL Server etc) connect with a LLM so that the LLM can query your database for information, if you expose this implementation as an MCP component (we’ll talk about this next), it can give other people & other agents access to your implementation easily, without really having to write custom code to integrate with your solution. And that is the entire point!

Architecture of MCP system

There are 3 main components in a MCP system

1. Host

2. Client

3. Server

Each of these 3 have their dedicated roles, and are arranged such that the system that MCP envisions, is secure, scalable, and actually makes it easy to build agentic systems faster.

MCP Host

The MCP host is the LLM application (e.g., Claude Desktop, VS Code) that acts as the container and coordinator. The host creates and manages multiple client instances, controls their connection permissions and lifecycles, enforces security policies, handles user authorisation, coordinates LLM integration and sampling, and manages context aggregation across clients. Think of this as the orchestrator of the entire MCP workflow.

MCP Client

Each MCP client is created by the host and maintains an isolated, stateful JSON RPC session with a specific server. Clients handle protocol negotiation, capability exchange, bidirectional message routing, subscriptions, and notifications, while maintaining security boundaries between servers. There is a 1:1 relationship between a client and a server. One host can spin up multiple MCP clients to interact with multiple MCP servers.

MCP Server

MCP Servers are independent processes that provide context and capabilities to the LLM. Servers expose resources, tools, and prompt templates via MCP primitives (we’ll discuss them in detail). Servers can be local processes (running on the same machine as the host) or remote services (hosted in the cloud).

Some of the design principles should be noted while building MCP servers

1. Servers should be extremely easy to build

2. Servers should be highly composable meaning that each server provides focused functionality in isolation thus allowing multiple servers to be combined seamlessly

3. Servers should not be able to read the whole conversation, nor “see into” other servers

4. Features can be added to servers and clients progressively

Server primitives

While we talk about an MCP server, its important to understand the server primitives that the MCP protocol expects. There are 3 main server primitives

Tools: These are discrete actions or functions that an AI agent can call. An example includes a get weather tool from a weather service, a create event tool from a calendar service, or a create postgres database tool from a database provider. Servers advertise the name, description, and input/output schema of each tool in their capabilities listing. When an LLM invokes a tool via a client, the MCP server executes the underlying function.

Resources: These are read-only data items or documents that the server can provide, and the client can retrieve on demand. Examples include text files, database schemas, file contents, or entries from a knowledge base. They allow the LLM to access and incorporate external information into its context.

Prompt Templates: These are predefined templates providing suggested prompts that can be injected into the LLM's context window. They can guide the model's approach to certain tasks or data and often appear as slash commands in AI applications, saving users time.

An easy reference to the information above can be found in the table below,

Capability Negotiation

Capability negotiation in the MCP allows different AI components to understand and interact with each other effectively. It is a system where both MCP clients and servers explicitly declare the features and functionalities they support during the initialization of a session

• The primary goal is to ensure that both the client and the server have a clear understanding of which protocol features and primitives are available for use throughout their interaction

• This negotiation is crucial for AI agents to successfully integrate with external data sources and tools, such as databases or APIs.

• It enables dynamic discovery, allowing an AI agent to query an MCP server at runtime to determine its available functionalities and then invoke those capabilities in a standardized way

The dedicated roles of MCP Host, Client and Server, combined with capability negotiation etc, creates a standard way for building agentic applications. This also paves way for developers to build on top of each other’s work and can significantly increase the pace at which agentic applications are developed. That is the promise of MCP.

I’ve complied a bunch of useful links in the section below in case you’re interested

• How to stay updated with the updates on the MCP protocol

• Best practices

• Security best practices

Well, now you know how the key specifications behind the MCP protocol. In an upcoming article, I’ll demonstrate how to use fastmcp to build your own MCP server easily. If that is something that interests you, feel free to subscribe to the compute blog using the button below. With this, thank you so much for reading and I hope you have a wonderful day!

Retrieval Augmented Generation (RAG) is an AI technique that enhances the quality of Large Language Model (LLM) responses by grounding them in external, verifiable knowledge sources. It combines the generative power of LLMs with the precision of information retrieval, leading to more accurate, up-to-date, and contextually relevant outputs.

Bridging the knowledge gap of LLMs

LLMs are trained on vast but static datasets, meaning their knowledge is frozen at the point of their last training. This can lead to outdated information, a lack of domain-specific knowledge, and a tendency to "hallucinate" or generate plausible but incorrect information. Retrieval Augmented Generation (RAG) has emerged as a powerful solution to address these challenges, significantly enhancing the reliability and accuracy of LLM-generated content. Since the information is grounded based on an existing knowledge source, this makes it very unlikely for an LLM to cook up some random information against a search query.

Core Idea

At its core, RAG is an architectural approach that combines the generative capabilities of LLMs with an external knowledge retrieval system. Instead of relying solely on the information embedded in its training data, a RAG system first fetches relevant information from a specified knowledge base (e.g., a collection of documents, a database, or an API) based on the user's query. This retrieved information is then provided as context to the LLM, which uses it to generate a more informed and accurate response.

Think of it like an open-book exam for an LLM. Rather than trying to recall information from memory (its training data), the LLM gets to consult relevant notes (the retrieved documents) before answering the question. This process grounds the LLM's response in factual, up-to-date, or domain-specific information.

The key benefits of RAG

1. Improved Accuracy and Reduced Hallucinations: By providing relevant, factual context, RAG significantly reduces the likelihood of LLMs generating incorrect or nonsensical information (hallucinations). The responses are grounded in the retrieved data.

2. Provide LLM, Access to Up-to-Date Information: LLMs inherently possess static knowledge. RAG allows them to access and utilize the latest information from external sources without needing to be retrained, which is a costly and time-consuming process.

3. Enhanced Domain-Specific Knowledge: RAG enables LLMs to provide expert-level responses in specific domains (e.g., medical, legal, finance) by connecting them to curated, domain-specific knowledge bases. This allows for tailored and accurate information delivery.

4. Increased Transparency and Trust: Because RAG systems retrieve information from specific sources, they can often cite these sources in their responses. This allows users to verify the information and builds trust in the system's outputs.

5. Cost-Effectiveness: Compared to fine-tuning an LLM with new data for every specific task or knowledge update, RAG is generally more cost-effective. Updating the external knowledge base is typically simpler and cheaper than retraining a massive language model.

6. Personalization: RAG can be used to personalize responses by retrieving information relevant to a specific user's context, history, or preferences.

Key Components

Knowledge base

This is the foundation of the "retrieval" aspect. It's the external corpus of information that the RAG system will draw upon to inform its responses. It can consist of a wide variety of data, including unstructured data like PDFs, Word docs, TXT files, articles, web pages, FAQs, internal wikis, semi structured like JSON files, CSV files with textual content etc.

The quality, relevance, and comprehensiveness of the knowledge base directly impact the accuracy and usefulness of the RAG system's outputs. If the information isn't in the knowledge base, the RAG system can't retrieve it.

The Data Preprocessing and Indexing Pipeline

This offline process prepares the knowledge base for efficient and effective retrieval. The key steps in this are

• Data Loading: Ingesting the raw data from the specified sources.

• Chunking: Breaking down large documents into smaller, semantically meaningful segments or "chunks." This is crucial because the LLMs have limited context window sizes and smaller chunks allow for more precise retrieval of relevant information. It’s important to note that chunking strategies can significantly impact retrieval performance.

• Metadata Extraction: Optionally, extracting and associating metadata with each chunk (e.g., source document, creation date, author, keywords). This can be used for filtering or providing context during retrieval.

The Embedding Model

The embedding model is responsible for transforming text (both the document chunks from the knowledge base and the user's query) into numerical representations called vector embeddings. Typically, these are sophisticated neural network models, often based on Transformer architectures (e.g., BERT, Sentence-BERT, Ada from OpenAI, or open-source alternatives like those from Hugging Face).

An embedding model captures the semantic meaning of the text. Text segments with similar meanings will have vector embeddings that are close to each other in the high-dimensional vector space, while dissimilar texts will be further apart.

The quality of the embedding model is paramount. A good model will:

• Accurately represent the semantics of the text.

• Distinguish subtle differences in meaning.

• Align well with the types of queries and documents the RAG system will handle.

Note: The same embedding model must be used for embedding the knowledge base documents and for embedding the user queries at runtime to ensure that the similarity comparisons are meaningful.

The Vector Database

Vector database is a specialized database designed to store, manage, and efficiently search through large quantities of vector embeddings. It has the following main functions

• Storage: It stores the vector embeddings generated from the document chunks, often alongside the original text chunks themselves or a reference to them, and any associated metadata.

• Indexing: It creates an index of these vectors to enable fast similarity searches. Common indexing techniques include Approximate Nearest Neighbor algorithms which trade off a small amount of accuracy for significant speed gains, especially with large datasets.

• Similarity Search: When a user query (also converted to a vector embedding) is received, the vector database compares this query vector to the vectors in its index and retrieves the 'k' most similar vectors (and their corresponding text chunks). The similarity is typically measured using metrics like cosine similarity or Euclidean distance.

Some examples of popular vector databases are Pinecone, Weaviate, Milvus, Chroma, FAISS etc.

The Retriever Component

Retriever orchestrates the process of fetching relevant information from the vector database based on the user's query. The retriever performs the following steps

• Takes the user's query.

• Uses the embedding model to convert the query into a vector embedding.

• Sends this query embedding to the vector database.

• Receives the top-k most relevant document chunks (the "context") from the vector database.

• May include logic for filtering results based on metadata, re-ranking retrieved chunks, or combining results from multiple retrieval strategies.

The retriever is the bridge between the user's need for information and the stored knowledge. Its efficiency and accuracy in finding the right context are critical.

The Large Language Model (LLM):

A LLM like GPT, Gemini etc serve as the generative engine of the RAG system. It takes the user's original query and the retrieved context and synthesizes them to produce a coherent, human-like answer. The LLM layer is responsible for

• Prompt Augmentation: The original user query is combined with the retrieved context. This is often done by formatting a new, augmented prompt that instructs the LLM to use the provided context to answer the query. For example:

  "Context: [retrieved document chunk 1] [retrieved document chunk 2] ... 
  Question: [original user query] 
  
  Answer based on the provided context:"

• Information Synthesis: The LLM processes this augmented prompt. Its pre-trained ability to understand language, reason, and generate text allows it to:

  • Understand the query in light of the new information.

  • Extract relevant facts from the context.

  • Synthesize these facts into a fluent and relevant answer.

  • Avoid relying solely on its internal, potentially outdated or generic knowledge.

• Response Generation: Produces the final textual response for the user.

The LLM's capabilities in comprehension, reasoning, and generation determine the quality, naturalness, and usefulness of the final output. Its ability to perform "in-context learning" using the provided context effectively is key to RAG's success.

In summary, a RAG system is a multi-stage process where data is first processed and stored in a searchable vector format. Then, at query time, relevant information is retrieved, and finally, this retrieved information is used by an LLM to generate an informed and contextually grounded response (LLM + Orchestrator).

I’ve been building RAGs using various LLMs and frameworks, and you’d be surprised at how easy it is to build one. If you’d like to read more about Agentic AI and other aspects of modern computation, feel free to subscribe to the compute blog for free. With that, thank you so much for reading and I hope you have a wonderful day!

One of the best ways to learn about AI agents is to build them. And this does not have to be hard and you don’t even need to be a developer to do this. Armed with the basics of AI, which I’ve covered for you in the article below, you can start building AI agents with very minimal setup and coding experience required at your end. This is because we now have frameworks that have drag and drop based interfaces to create agents intuitively. One of the best open frameworks doing this today is Langflow.

If you’ve read the article above, you know that there are only a couple of important things required to build your own AI agent. Luckily, langflow abstracts most of the implementation behind a friendly user interface for you to focus on how you want your agent to work, instead of spending a lot of time writing code. And if you want to write code and make your own customizations, there’s support for that as well. How nice!

The target demographic for langflow

Langflow reminds me of Figma, which has become synonymous with UI/UX workflows. Designing and prototyping frontend applications, became super easy due to Figma and most of the companies working on products started relying on it to work on their UI/UX flows. Langflow is like figma for AI agents. You can design an agent with a drag-drop interface and develop smart agents without really having to write any code.

At the same time, if you are comfortable writing your programs, you can implement your own tooling which langflow can then utilize making it a powerful tool even for experienced software engineers.

How is it different from others agentic AI tools?

Here’s a small table comparing the different popular agentic AI frameworks in the market right now in case you’d like to take a quick look.

Setting up langflow on your computer

The steps for this are fairly straightforward, if you’d like to set it up on your computer for playing around with langflow

1. Have python version >= 3.10, installed in your machine

2. Create a virtual environment with python3 -m venv .venv

3. Load the virtual environment with source .venv/bin/activate

4. Langflow is best installed using uv

5. To install langflow run the following uv pip install langflow

6. You run langflow with uv run langflow run

When the command finishes execution, this is what you'd be able to see on your terminal.

Visual agent builder

Langflow is an intuitive visual flow builder. This drag-and-drop interface allows people to create complex AI workflows without writing extensive code. You can easily connect different components, such as prompts, language models, and data sources, to build sophisticated AI applications.

What is a flow?

A flow is an application. It receives input, processes it, and produces output. Flows are created in the workspace with components dragged from the components sidebar.

A flow can be as simple as the basic prompting flow, which creates an OpenAI chatbot with four components.

• Each component in a flow is a node that performs a specific task, like an AI model or a data source.

• Each component has a Configuration menu. Click the Code pane to see a component's underlying Python code.

• Components are connected with edges to form flows.

When a flow is run, Langflow builds a Directed Acyclic Graph (DAG) graph object from the nodes (components) and edges (connections between components), with the nodes sorted to determine the order of execution. The graph build calls the individual components' build functions to validate and prepare the nodes. This graph is then processed in dependency order. Each node is built and executed sequentially, with results from each built node being passed to nodes that are dependent on the previous node's results.

Components

A component is a single building block within a flow and consists of inputs, outputs, and parameters that define its functionality. To add a component to your flow, drag it from the sidebar onto the workspace. To connect components, drag a line from the output handle (⚪) of one component to the input handle of another

Project - Youtube video summary agent

One of the fun ideas I had while experimenting with langflow, was to build an agent that would summarize the youtube videos, and DM it to me for safekeeping. As someone who doesn’t want to spend a lot of time watching youtube, this would’ve been a good solution to save time and check whether a video is even worth watching.

I used youtube transcripts tool, to get the transcripts for any youtube video, attached the chat input and output to the agent, used gemini 2.0 flash for the LLM layer and the overall flow was surprisingly simple. You can see the entire flow in the picture below.

I also gave my agent very clear instructions on what it needs to do. I instructed it to summarize the video in not more than 3 main points. At the same time, I wanted the agent to provide me a a list of all the important points that were discussed in the video. The idea was to distill information as much as possible, while retaining the important information that I can reference later, if required. The instructions to my agent were as below.

It all came together. Here, in a video of less than 1 minutes, I’ll show you how the end to end implementation of this looks like, including receiving my agent sending a message to me, on Discord (an IM platform)

Langflow is a surprisingly good open-source framework that makes it super easy & fun to build AI agents, but it’s far from the only one. If you’d like to read about other agentic AI frameworks and other modern computation practices & solutions, feel free to subscribe to my blog - compute for free. With that, thank you so much for reading and I hope you have a wonderful day!

We as humans have always been trying to make our computers do more and more things. In the last 40 years alone as a species, we’ve gone orders of magnitudes further in field of computing than we have in our entire 10,000+ year old history. We have developed cheap storage, better and faster compute every year. We optimized our supply chains to get hardware around the globe faster. We developed cloud and made it super convenient for people to build applications and software. We developed GPUs and figured out ways to use them to perform computations orders of magnitude faster.

All of this came together to realize the dream that computer scientists have long wanted to realize ever since the conception of computers. What if computers could learn behavior without explicit programming. You know - instead of do this when x happens, what if the machine learns on its own to decide what should be done. What if it could mimic how the human brain works? That would be wonderful wouldn’t it?

We developed Machine learning algorithms and the idea of an artificial neural network before 2000s but we did not have the computation, storage and a global infrastructure to make this economically viable. Until we did.

Agents, are what we’ve always wanted our computers to be. Computers “thinking” on their own and also being autonomous, which implies that they will act on their own. The “act on their own” part is what really differentiates an agent from what we’ve been doing with AI so far. This is the main bit. An agent can act based on various inputs that it takes from its environment. It can utilize a series of tools to do complex tasks.

Let me show you some examples.

Firebase studio

This right here is Firebase studio, an excellent implementation of agentic AI. You tell the agent the kind of application you want to build, and the features that you need. The agent that goes ahead and figures out the frontend, the backend and the various building blocks required to build your application. It then starts to put together code using Large Language Models (like GPT and Gemini) and checks whether the code actually works. If the code works, it knows that the job is done and waits for you to give it more instructions.

Figma, a UI/UX prototyping tool came a couple of years ago and made it very simple to see how an application would look and feel before the development even begins. It significantly changed the industry over the years. Now, Imagine being able to prototype an entire application, in minutes, and not just its mockup. Getting from ideas to products is going to be so much faster with tools like this in the market. And this is far from being the only tool that’s changing the way, we’ve through about software development.

VS Code Agent

VS Code is one of the best and most popular free coding editors available for software engineers today. It integrates super well with another tool called Github copilot to give you a fantastic “agent mode” experience. Let’s say you want to build an application in typescript but do not know the nuances of it. Maybe you know a bit of typescript but there’s a lot of work that is usually required to set up your project and even getting the basics to work on your machine. There might be software dependencies, and other things that are required before you can see a UI render for your application.

Similar to firebase studio, VS Code agent mode will figure out the commands for you, and run those commands for you. It will observe the output of the execution of those commands and gradually make its way towards giving you a fully functional project. That is great news for developers and PMs who want to prototype things but do not possess deep expertise in the hundreds of frameworks that are often required in making an application. And even for a seasoned developer, the productivity gains are immense. Being able to prototype ideas quickly, without having to spend a ton of time purely typing does increase the speed of writing code significantly.

What can agents do?

Here are some examples that I’ve seen agents being able to do, with the right integrations

1. Search the internet

2. Send emails

3. Crawl & scrape the internet for information

4. Send messages

5. Write custom code to do solve basically problems of any nature

6. Talk to other agents

If you provide an agent with the right set of tools, it’ll be able to accomplish many things that were considered impossible a couple of years ago. For example, here’s an implementation by Manus AI (a state of the art Agentic AI solution) to understand public sentiment related to a topic by going through conversation happening on twitter, youtube and other social media platforms.

What is needed to build agents?

AI agents are systems designed to perceive their environment, make decisions, and take actions to achieve specific goals, autonomously. Some of the main building blocks of AI agents are

Perception

AI agents gather information from the environment through, Sensors in physical robots (e.g., cameras, LIDAR) or APIs or data streams in software agents (e.g., websites, databases, user interactions)

For example:

• A chatbot sees user text as input.

• A trading bot reads real-time market data.

• A social sentiment analysis agent goes through crawls and scrapes websites

Reasoning and Decision Making

Once data is received, agents, analyze the input, maintain a state or memory of previous interactions and use rules, models, or AI techniques to decide what to do next Some of these techniques can be Rule-based logic, Machine learning models (e.g., classification, reinforcement learning), Planning algorithms (e.g., A* search, Monte Carlo Tree Search) or Large Language Models for high-level reasoning and planning. Due to the recent rapid advances in LLMs, and LLMs becoming increasingly cheaper and bigger (more context tokens), agents have been becoming better at solving complex problems.

Action

After deciding what to do, agents can perform an action via actuators (robots) or function calls (software). These actions affect the environment, completing the perception-action loop

Some examples are:

• An AI assistant books a meeting, based on everyone’s availability and sends out a pre-read for the meeting’s topic

• An LLM-based agent queries a database based on a user’s question and formats a report

Environment

The world the agent interacts with can be:

• Physical like real-world robotics and IoT devices

• Digital like web browsers, APIs, games and simulations

• Abstract like mathematical problems and data science tasks

An environment allows an agent to interact and learn. It acts as a source for feedback that agent can use to experiment iteratively. It allows agents to learn from both successful and failed experiments much like a baby learns from interacting with his/her environment while growing up.

Memory (State) Management

Memory management within agents allows the agent to keep track of past interactions. This is why you’re able to have a natural conversation with the chatGPT these days. If your first question is like, “What are the available macbooks in the market”, followed up by “What is the price of the latest one?”, you know that the the agent is going to find the price for the latest macbook. Memory also allows the agent to make intermediary decisions that might be important to solve your problem better. This is very similar to how we sometimes make a to-do list before solving a complicated multi-step problem.

Frameworks & Tools

For building advanced agents, there are multiple frameworks out there already. Some of these frameworks help you build LLM agents, some are components within agents to let you perform tasks easily. Here are some of the them

• LangChain / LlamaIndex

• Autogen / BabyAGI

• Haystack, CrewAI, MetaGPT

• Langflow

• LLMs/APIs (OpenAI, Claude, Mistral, local models)

I’m planning to cover these frameworks in my blog, soon. If you’re interested in free weekly articles on the latest agentic AI frameworks, tutorials and engineering trends, feel free to subscribe to compute for free by clicking the button below. With that, thank you so much for reading and I hope you have a wonderful day!

Overview

FastAPI is a modern, fast (high-performance), web framework for building APIs with Python based on standard Python type hints.

The key features are:

• Fast: Very high performance, on par with NodeJS and Go. One of the fastest Python frameworks available.

• Fast to code: Increase the speed to develop features by about 200% to 300%.

• Fewer bugs: Reduce about 40% of human (developer) induced errors.

• Intuitive: Great editor support. Completion everywhere. Less time debugging.

• Easy: Designed to be easy to use and learn. Less time reading docs.

• Short: Minimize code duplication. Multiple features from each parameter declaration. Fewer bugs.

• Robust: Get production-ready code. With automatic interactive documentation.

• Standards-based: Based on (and fully compatible with) the open standards for APIs: OpenAPI (Swagger) and JSON Schema.

Let’s dive in

Super fast to get started

FastAPI allows you to set up a fully functional API with just a few lines of code. For example, this is all you need to create a simple "Hello World" endpoint:

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Hello, World!"}

Save it as main.py, run it with uvicorn main:app --reload, and voilà! You have a running API.

Built-in Validation

FastAPI uses Pydantic (really cool data validation library) to validate your data automatically. Just define your input schema, and it handles the rest. If someone sends invalid data, FastAPI will return a detailed error message explaining what's wrong. This is how easy it is to implement data validation

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class Item(BaseModel):
    name: str
    price: float
    in_stock: bool

@app.post("/items/")
def create_item(item: Item):
    return {"item": item}

Asynchronous by Design

FastAPI is built on top of Starlette, which means it fully supports asynchronous programming. This is great if your API interacts with databases, external APIs, or other time-consuming operations. This is unlike Flask, which another popular micro-service framework in python.

Asynchronous Endpoints

FastAPI’s support for asynchronous programming allows developers to handle multiple requests concurrently, leading to better performance in high-throughput applications. Unlike traditional synchronous frameworks, where each request is processed sequentially, async endpoints enable non-blocking operations using Python’s async and await keywords.

When to Use Async Endpoints

• When dealing with I/O-bound operations such as database queries, external API calls, or file processing.

• When handling a high number of concurrent users efficiently.

• When integrating with modern async-based libraries like httpx (for HTTP requests) or databases (for async database operations).

Interactive Documentation

One of FastAPI's coolest features is interactive documentation. Once your API is up, visit /docs or /redoc, and you'll find auto-generated, interactive docs based on your code. No extra effort needed!

Dependency Injection

Dependency Injection (DI) is a software design pattern that promotes modularity, reusability, and testability by allowing dependencies to be injected into functions or classes rather than being hardcoded. FastAPI has built-in support for dependency injection, making it a powerful feature for handling dependencies such as database connections, authentication mechanisms, and business logic.

How FastAPI Handles Dependency Injection

FastAPI’s DI system is declarative and built into the framework using Python’s type hinting. It enables developers to define dependencies separately and inject them into route handlers using Depends. The dependency function is executed before the route function and its return value is passed as an argument.

Basic dependency injection

How it works:

• common_dependency() is a simple function that returns a string.

• The Depends function tells FastAPI that this dependency should be executed before handling the request.

• The result of common_dependency() is injected into the route function as the data parameter.

Advanced Dependency Injection

FastAPI allows injecting more complex dependencies like database sessions, authentication checks, and configuration settings.

Example: Database Connection as a Dependency

How it works:

• The get_db function initializes a database session and ensures it is closed after use.

• yield is used for cleanup after the dependency is executed.

• The Depends(get_db) injects the database session into the route.

Key differences with Flask

Flask and FastAPI are two of the most popular web frameworks in Python, but they have key differences in design philosophy, performance, and features.

I’ve summarized the key differences between the frameworks in the table below.

When to use one over the other

While both flask and fastapi are great frameworks, there are areas where one shines over the other. The table below summarizes this.

Final Verdict

• Choose FastAPI if you need a high-performance, async-ready API with built-in documentation and validation.

• Choose Flask if you're building a traditional web application with templating (like Jinja2) or if you prefer a lightweight framework with more flexibility.

The code for the examples shared for this post are available for free on my Github repository python-frameworks.

Conclusion

FastAPI is a game-changer for modern API development in Python. Its built-in validation, high performance, and async capabilities make it an excellent choice for both small and large-scale projects. If you’re looking for a framework that makes API development fast and enjoyable, FastAPI is worth exploring!

Happy coding!

The why of containers

“It works on my machine, I’m not sure why it’s breaking in yours” is a problem that plagued developers for years. With the rise of agile, and quantifying developer’s productivity, it also became clear that such problems require solutions. If you cannot be sure that the software that runs on your machine will work on your fellow dev’s machine, you cannot be sure that it’ll work on production either.

This is one of the major problems that containers solved. Let’s understand this more. The problem of "it works on my machine" arises when an application behaves differently in different environments (e.g., development, testing, or production) due to discrepancies in dependencies, configurations, or operating system setups.

Containers effectively address this issue by providing a consistent and isolated runtime environment by

1. Encapsulating Dependencies

   Containers package all the dependencies (libraries, frameworks, configuration files, etc.) an application needs to run. This ensures the application behaves the same way regardless of where it's deployed, as the container runs with its bundled dependencies.

2. Portability Across Platforms

   Containers abstract away the underlying infrastructure by providing a consistent runtime. Whether it's running on a developer's laptop, a testing server, or a production environment, the container ensures uniform behavior.

3. Isolation

   Containers run in isolated environments, meaning they are unaffected by the host system's configuration or other applications running on the same host. This eliminates conflicts like mismatched library versions or environmental variables.

4. Reproducibility

   Containers are built using Dockerfiles or equivalent configuration files, which describe the environment setup in a version-controlled and reproducible manner. Teams can rebuild containers identically at any time, ensuring consistency across environments.

5. Simplified Onboarding

   New developers or team members don’t need to replicate complex environment setups. They can simply use the containerized application, ensuring they work with the exact same environment as everyone else.

What are containers

Containers are lightweight, standalone, and executable packages of software that include everything needed to run an application: the code, runtime, libraries, and system tools. They provide a consistent computing environment, making applications portable across different systems.

What Containers do

1. Encapsulation: Bundle applications and their dependencies together.

2. Portability: Run consistently across various environments (development, testing, and production).

3. Isolation: Ensure that one container doesn't affect others running on the same host.

4. Efficiency: Use system resources effectively without the overhead of full virtualization (e.g., virtual machines).

What is Docker?

Docker is one of the many ways of building and running containers. It is one of the most popular and widely adopted containerization platforms, there are several alternatives that can build, run, and manage containers. Each has its own strengths and use cases. The reason docker is the first thing, people think of when talking about containers is that for a very long time, docker was the most popular choice for working with containers.

Docker is a great platform and toolset for creating, deploying, and managing containers. It simplifies containerization by providing:

• A Dockerfile to define the container’s configuration.

• A Docker Engine to build, run, and manage containers.

• A Docker Hub for sharing and distributing container images.

Let’s see how a Dockerfile looks like

# Use an official Python runtime as a parent image
FROM python:3.9-slim

# Set the working directory inside the container
WORKDIR /app

# Copy the current directory's contents into the container
COPY . /app

# Install the Python dependencies
RUN pip install --no-cache-dir -r requirements.txt

# Expose port 5000 for the application
EXPOSE 5000

# Command to run the application
CMD ["python", "app.py"]

Let’s understand an overview of what this script is doing

1. FROM: Specifies the base image (e.g., python:3.9-slim) that the container will build upon.

2. WORKDIR: Sets the working directory inside the container where commands will be executed.

3. COPY: Copies files and directories from the host machine to the container.

4. RUN: Executes a command during the build process, such as installing dependencies.

5. EXPOSE: Declares the port on which the containerized application will listen.

6. CMD: Defines the default command to run when the container starts, such as launching the application.

Now that we’ve seen how a Dockerfile looks like, let’s see how to build an image and run it

Building an image

Building a Docker image is the process of creating a container image by executing the instructions defined in a Dockerfile. The result is a self-contained package that includes the application, its dependencies, and any configurations needed to run it.

In our Dockerfile example above, the following commands in your shell will build and run the container

1. Build the container

   docker build -t my-python-app .

   1. -t my-python-app: Tags the image with the name my-python-app.

   2. . Refers to the directory containing the Dockerfile.

2. Run the container

   docker run -p 5000:5000 my-python-app

   1. -p 5000:5000: Maps port 5000 of the container to port 5000 on the host.

   2. my-python-app: The name of the image to run.

Key things to remember

• A Dockerfile is a script with instructions to build a container image.

• Each instruction creates a new layer in the container, contributing to efficiency (layer caching).

• It’s designed to be simple yet powerful, enabling consistent and reproducible environments.

Kubernetes - Managing a ton of containers

As systems scale, managing and deploying containers manually becomes challenging. You can have hundreds of containers running on hundreds of servers. There are some challenges that show up on scales like this

1. Orchestration difficulty: Applications often consist of multiple services (e.g., frontend, backend, database) running in many containers. Orchestrating these containers manually is cumbersome.

2. Scaling: Handling variable workloads requires scaling containers up or down dynamically, which is difficult to do without automation.

3. Availability: Ensuring that applications are always running, even if some containers or nodes fail, requires self-healing capabilities.

4. Load Balancing: Distributing traffic effectively across multiple instances of a service ensures reliability and efficiency.

5. Deployments: Rolling updates, canary deployments, and rollbacks are difficult to manage manually.

If Docker is the tool used to create and run containers, Kubernetes is the system that orchestrates and manages those containers at scale. Here’s a metaphor and a more technical explanation to clarify their relationship:

Containers vs. Kubernetes

• Docker (Containers): Imagine containers as individual delivery trucks. Each truck is self-contained, carrying specific goods (an application and its dependencies). Docker is the tool that builds, loads, and drives these trucks.

• Kubernetes (Orchestrator): Now imagine you manage a large logistics company with thousands of delivery trucks. Kubernetes is the system that plans routes, monitors truck conditions, schedules deliveries, ensures trucks aren’t idle, and reroutes trucks when one breaks down.

While Docker focuses on managing single containers, Kubernetes coordinates how all containers work together across multiple machines.

With Docker alone:

• You manually start containers, stop them, and figure out how to connect them.

• You’re responsible for scaling and handling failures.

With Kubernetes:

• You define the system’s desired state (e.g., "run 5 instances of my app and scale if CPU usage exceeds 70%").

• Kubernetes handles starting, scaling, load balancing, and restarting containers automatically.

Let’s get a bit more technical about Kubernetes

How Kubernetes Works

At its core, Kubernetes uses a cluster-based architecture. There is a master node and worker nodes, with their own sets of responsibilities

1. Master Node (Control Plane):

   1. Responsible for managing the cluster, scheduling workloads, and maintaining the desired state.

   2. Key components:

      • API Server: Central communication point between users and the cluster.

      • Scheduler: Assigns workloads to worker nodes.

      • Controller Manager: Ensures the cluster matches the desired state.

      • etcd: Stores all cluster data persistently.

2. Worker Nodes:

   1. Run the actual containerized applications.

   2. Key components:

      • Kubelet: Ensures containers are running as instructed by the control plane.

      • Kube-proxy: Manages networking and forwarding of requests to the correct containers.

      • Container Runtime: Runs containers (e.g., Docker, containerd).

Key Kubernetes Abstractions

1. Pods: The smallest deployable unit in Kubernetes, typically running one or more tightly coupled containers.

2. Services: Abstracts access to a group of pods, providing load balancing and stable networking.

3. Deployments: Manages the deployment and scaling of pods, ensuring the desired number of replicas are running.

4. Namespaces: Logical partitions within a cluster to separate resources and workloads.

5. ConfigMaps and Secrets: Manage application configuration and sensitive data securely.

Workflow

Declarative Configuration: You define the desired state of your application (e.g., run 3 replicas of a web server) in YAML or JSON.

• Control Plane Actions:

  1. The API server processes the configuration and stores it in etcd.

  2. The scheduler assigns pods to suitable worker nodes.

  3. The kubelet on each worker node ensures containers are running.

• Dynamic Adjustments:

  • Kubernetes monitors the system and adjusts the cluster automatically, such as scaling pods up or down based on CPU usage.

Here’s a diagram to understand this process easily

Managed Kubernetes

Managed Kubernetes services provided by major cloud providers, such as Managed Kubernetes services provided by major cloud providers, such as Azure, AWS, and Google Cloud, offer fully managed, scalable, and secure Kubernetes clusters to simplify container orchestration.

• Azure Kubernetes Service (AKS): Azure's managed Kubernetes service provides a simple, fast, and secure way to deploy and manage Kubernetes clusters. It handles tasks such as automated patching, scaling, and high availability, while allowing users to focus on application deployment and management. AKS integrates seamlessly with other Azure services, offering built-in monitoring, logging, and identity management through Azure Active Directory.

• Amazon Elastic Kubernetes Service (EKS): AWS’s EKS is a highly available and scalable service that takes care of cluster management, including provisioning, patching, and scaling. EKS supports a wide range of integrations with AWS services such as IAM, CloudWatch, and Route 53, offering enhanced security and observability. It also ensures the control plane is automatically managed and fully resilient.

• Google Kubernetes Engine (GKE): GKE is known for its seamless integration with Google Cloud services and its native support for Google’s deep Kubernetes expertise. GKE automates key aspects such as updates, scaling, and monitoring. It also integrates with Google’s advanced AI/ML tools, making it a strong choice for developers building modern, cloud-native applications.

All these services reduce the operational overhead of Kubernetes management, allowing developers to focus more on application development rather than cluster administration. They provide features like automatic scaling, high availability, and integration with the cloud provider's ecosystem, helping businesses achieve faster deployment and improved efficiency.

Now you know quite a bit about containers and their orchestration. In an upcoming article, I’ll be sharing a playground for you to experiment with these and gain a hands on experience without setting anything up on your computer. Till then, I hope you enjoyed reading this one. Have a wonderful day!

What is CI/CD?

CI (Continuous Integration) and CD (Continuous Delivery/Continuous Deployment) are practices within DevOps aimed at automating and streamlining the software development lifecycle to improve speed, quality, and consistency.

Continuous Integration

Continuous Integration is a development practice where developers frequently integrate their code changes into a shared repository, often several times a day. Each integration is automatically tested and validated through a series of automated tests to detect errors early. This approach allows for quicker detection and resolution of integration issues, which helps maintain code quality.

Continuous Delivery

Continuous Delivery is the practice of automatically preparing code changes for release to production. With CD, the codebase is always in a deployable state, allowing teams to release updates reliably and more frequently.

Continuous Deployment

Continuous Deployment is the next step after Continuous Delivery. Here, every code change that passes automated testing is automatically deployed to production without human intervention. Continuous Deployment allows for faster feedback and iterative improvement but requires very high test coverage and automation.

The classic cycle of pushing code looks like

Github Actions

GitHub Actions is a powerful tool for automating tasks and workflows directly within GitHub. It's integrated into the GitHub platform and is primarily used for Continuous Integration (CI) and Continuous Deployment (CD), though its capabilities go far beyond that.

Key features of Github Actions

1. Automate your workflows: Automate software development workflows like testing, building, and deploying code.

2. Event driven workflows: Trigger workflows based on GitHub events, such as pushes, pull requests, releases, or even at scheduled times.

3. Customize to your liking: Define workflows using YAML files in a .github/workflows directory within a repository.

4. Reuse and save time: Create or use existing actions shared by the community to simplify workflow design.

5. Matrix Builds: Run jobs in parallel for multiple combinations of environments, dependencies, or configurations.

6. Manage secrets safely: Securely store and use sensitive information like API keys and credentials.

7. Built-in Logs: Access detailed logs for debugging and performance analysis.

Structure of Github actions workflow

A workflow is defined in a YAML file and consists of the following parts:

• Name: Optional, used for identifying the workflow.

• Trigger: Defines when the workflow should run (e.g., push, pull_request, or schedule).

• Jobs: Workflows consist of one or more jobs that run in parallel or sequentially.

• Steps: Each job has multiple steps, which include actions or shell commands.

Here’s an example of a very basic Github Action workflow

# .github/workflows/basic-workflow.yml
name: Basic Workflow

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v3

      - name: Print Hello World
        run: echo "Hello, World!"

Let’s play with Github Actions

I’ve created a template repository to make it easy for you to play and experiment with Github actions. Just navigate to this template repository on Github and select the button on the top right that says, “Use this template” and then select “Create a new repository”

Provide a name for your repository like how I do it in the screenshot below and then create your repository.

A few seconds after creating your repository, refresh your browser and you should see a green tick, denoting the first run of your Github action

Navigate to the actions tab in your newly created repository and you’ll see the full details of the run of your workflow.

Once you navigate into the details of your workflow run, you’ll find that some basic echo commands were called from your runtime, like in the screenshot below. This is because the repository that I’ve provided to you as a template, contains a basic workflow, the purpose of which is to print “Hello world” and run a multi-line script.

If you’d like to change and experiment with this workflow, just edit the workflow file for the Github actions and experiment away

Now that you have access to a runtime, setting up builds and releases is simply a matter of adding the right jobs and the right dependencies. Feel free to modify this script to your liking and try building some source code in the language of your choice in your newly created repository. Good luck!

Overview

I want to show you something incredible. In this post, I’ll talk about Hasura - an open-source engine that provides instant, real-time GraphQL and REST APIs for your databases and applications. It acts as a data access layer, simplifying the process of building and managing APIs by automating the generation of GraphQL or REST endpoints based on your existing database structure. The Hasura engine is an open source project which supercharges the building of modern applications by providing access to data via a single, composable, secure API endpoint.

But first … a quick refresher on GraphQL

GraphQL is a query language for APIs and a runtime for executing those queries by using a type system that you define for your data. It was developed by Facebook and released as an open-source project in 2015. Unlike traditional REST APIs, where each endpoint returns a fixed structure of data, GraphQL allows clients to request exactly the data they need, making data retrieval more efficient and flexible.

Below is an example of a Graphql API call

I’ve added a link at the end of the article, in case you’d like to experiment with GraphQL queries yourself.

So how does Hasura help?

Hasura lets you provision instant, real-time GraphQL and REST APIs for your data, making it very easy to build

1. Data-Driven Applications: It is ideal for quickly building applications where real-time data interaction is important, such as dashboards, collaborative tools, or social feeds.

2. Backend for Mobile Apps: Hasura can serve as the backend to mobile applications needing consistent and efficient data querying and updates.

3. Microservices Integration: It can be used to unify different data sources, making it easier to expose a unified API across a microservices architecture.

Key Features of Hasura

• Instant GraphQL API Hasura automatically generates a fully functional GraphQL API based on your database schema, allowing for flexible and efficient data querying.

• Real-Time Capabilities: It supports real-time data updates with GraphQL subscriptions, enabling applications to receive live updates as data changes.

• REST Endpoints: While primarily a GraphQL engine, Hasura also allows users to create REST endpoints from the same data source.

• Authorization and Security: Built-in role-based access control (RBAC) and security policies let you define granular access permissions for different users.

• Supports Multiple Databases: Hasura supports various databases, with strong initial support for PostgreSQL and extending to others like MySQL and SQL Server.

• Remote Schemas and Integrations: It allows the integration of other GraphQL services as remote schemas, combining various APIs into a single endpoint.

• Custom Business Logic: Users can add custom business logic through serverless functions or REST APIs that Hasura can integrate with.

Let’s play around with Hasura

I created an account on Hasura.io and chose the free-tier for my experimentation. This did not require a credit card, which was very welcome. I chose AWS as my cloud provider for this demo and I was surprised to see this setup becoming available to me in under 30 seconds. Here’s how my account looked like, after creation.

Now let us see what all we can do with Hasura

It’s really simple to connect your data

I did not have a database lying around, so I provisioned a free Postgres instance using Neon. This was pretty good but I needed data to start playing around with the same. I wrote a simple ChatGPT prompt to create some mock data and populate my database with the same.

Now that my table was created and the data became available, it was time to start exploring the graphql API. And voila! This happened instantly. The moment my database connection became available, the API was ready to go. This is absolutely amazing because I can start using this API in a web application right away.

What about security?

This is also where I was very pleasantly surprised to find very intuitive controls available in the UI. I was able to enable

• Rate-limits

• Node limits

• Depth limits

• Timeout and

• Batch-request limits

for a global user as well as a user that I created for testing. This is very useful as implementing this was actually quite a messy affair, when I did this on my own, using a flask-backend in python a few years ago.

Schema-introspection can also be limited to roles and that is a very welcome feature that is available right in the UI.

Making a REST endpoint

It was comically easy to make a REST endpoint on top of my data. All of the methods of GET, POST, PUT, PATCH and DELETE are available to the user while creating the endpoint. This is a great feature for systems that want to leverage everything that Hasura offers, without having to switch to a GraphQL API.

Actions

Actions in Hasura are custom queries or mutations that are resolved via HTTP handlers. Actions can be used to carry out complex data validations, data enrichment from external sources or execute just about any custom business logic.

An action would end up executing custom logic that you can call via a webhook or a REST endpoint and basically work with any external system. Creation of an action is also very straightforward. You define your configuration and select how you want to handle the same. The execution allows for both synchronous and asynchronous calls which is excellent and ends up allowing for all sorts of custom implementations.

Remote Schemas

Remote schemas in Hasura are external GraphQL services which can be merged with Hasura to provide a unified GraphQL API. Think of it like automated schema stitching. All you need to do is build a GraphQL service and then provide its HTTP endpoint to Hasura. Your GraphQL service can be written in any language or framework.

Event triggers

An Event Trigger atomically captures events (insert, update, delete) on a specified table and then reliably calls a HTTP webhook to run some custom business logic.

Monitoring

Hasura's GraphQL Engine includes several built-in monitoring features and integrates with external monitoring tools to help users track, optimize, and troubleshoot their API performance. Here are the main monitoring features available in Hasura:

• Health Check Endpoint: Hasura provides a /healthz endpoint to check the status of the Hasura server, which is useful for setting up basic health monitoring.

• Readiness Endpoint: The /readiness endpoint can be used to check if Hasura is ready to accept traffic, helpful for auto-scaling and load balancing setups.

• GraphQL Engine Logs: Hasura generates logs for requests, response times, and errors. These logs can be configured for various verbosity levels and can be directed to log aggregation tools for better insights.

• Request/Response Metrics: Hasura provides metrics for query and mutation execution time, including metadata about each query, mutation, and subscription.

• Real-time Analytics for Active Subscriptions: Hasura’s console allows you to monitor active subscriptions in real-time, showing which users are subscribed to which queries and for how long.

• Hasura integrates with OpenTelemetry and Jaeger for distributed tracing, allowing users to monitor each stage of query execution. You can trace requests from the frontend through Hasura to the underlying database and identify slow-performing queries.

• Hasura provides a native integration with Prometheus to export monitoring metrics, such as request latency, response status codes, and other performance indicators.

• Hasura can also work with third-party observability tools such as Datadog, New Relic, and others by exporting logs and metrics. This flexibility enables more advanced monitoring setups for larger applications or specific enterprise needs.

Conclusion

All in all, Hasura is an excellent project and I can’t wait to implement my upcoming projects with it. With a generous-free tier on Hasura cloud, I want to start hosting some of my APIs and start implementing some web dev projects using the same. Also, I am going to going to self-host Hasura engine and see how I can leverage it with an existing infrastructure on my personal cloud subscription.

If you’re interested in reading about my implementations or similar topics in the engineering space, feel free to subscribe to my blog for free using the button below.

This was a long post and if you’ve stuck around, I’d like to thank you for reading. And I hope you have a wonderful day!

Resources

Want to experiment with how GraphQL API works? Here’s a handy link for you to experiment with queries in GraphQL.

What are orchestrators?

Orchestrators are tools designed to manage, schedule, and monitor complex workflows in data pipelines and software systems. They allow developers to automate a sequence of tasks or workflows, define dependencies between tasks, and ensure that each task is executed in the right order, typically handling data processing, ETL (Extract, Transform, Load) operations, and other repetitive tasks.

Core Functions

1. Workflow Scheduling: Orchestrators schedule tasks to run at specific times or intervals, allowing for automating workflows. This is essential for pipelines that require regular updates, like daily data ingestion or processing tasks.

2. Dependency Management: Workflows often involve tasks that depend on the completion of other tasks. Orchestrators allow you to define these dependencies so that tasks are executed in the correct order.

3. Error Handling and Logging: Orchestrators track the success and failure of each task and offer logs for debugging. If a task fails, they can retry it or notify the appropriate team, ensuring that errors are caught and handled efficiently.

4. Parallelization and Scalability: Orchestrators can run multiple tasks in parallel if they are independent, which helps reduce the total time required for workflow execution. They also integrate with distributed computing resources, making them scalable as workload demands increase.

5. Monitoring and Alerting: They provide tools to monitor workflow execution in real time and can send alerts if tasks fail or if there are delays. This helps maintain reliability and uptime, especially for critical pipelines.

Benefits of Using Orchestrators in Software Systems:

• Automation: By automating repetitive workflows, orchestrators save developers time and minimize manual errors.

• Reliability & Resilience: The ability to handle dependencies and retry failed tasks ensures that workflows are resilient to interruptions.

• Scalability: As workflows grow in complexity, orchestrators can scale to accommodate more tasks, dependencies, and larger volumes of data.

• Better Collaboration and Visibility: Teams can easily visualize, monitor, and manage workflows, improving collaboration and transparency.

Popular orchestrators in the data engineering space

Apache Airflow

Apache Airflow allows you to define almost any workflow in Python code, no matter how complex. Because of its versatility, Airflow is used by companies all over the world for a variety of use cases.

Some of the main characteristics of airflow are

• Python-Based DAGs: Workflows are defined as Directed Acyclic Graphs (DAGs) in Python, allowing for great flexibility and customization.

• Dependency Management: Supports complex dependency handling to sequence tasks.

• Extensibility: Integrates with many tools and services through a vast array of plugins and operators.

• Strong UI for Monitoring and Control: Offers a user-friendly web interface for monitoring and managing workflows.

Luigi

Luigi is a Python package that helps you build complex pipelines of batch jobs. It handles dependency resolution, workflow management, visualization, handling failures, command line integration, and much more.

Some of the main characteristics of Luigi are

• Dependency Resolution: Particularly strong at handling complex dependencies across a wide array of tasks.

• Pipeline Simplicity: Ideal for simpler, sequential pipelines with many tasks but relatively straightforward logic.

• Command-Line Interface: Workflow management and execution are command-line-driven, which suits developers comfortable in that environment.

Prefect

Prefect is one of the newer names in the market. It allows you to orchestrate your code with scheduling, automatic retries, and prioritized instant alerting, giving you full observability into your workflows. Of all the orchestrators in the list, Prefect is my favorite as the implementation is simply, really good!

Some of the main characteristics of prefect are

• Pythonic and Flexible: Also Python-based like Airflow but with a focus on easy-to-use syntax and configuration.

• Dynamic Task Mapping: Allows for dynamic task creation at runtime, which is beneficial for variable-length workflows.

• Fault Tolerance and Resilience: Provides robust error handling, making it easy to rerun workflows from a failed task.

• Hybrid Cloud Execution: Supports both cloud and local execution, allowing users to manage infrastructure more flexibly.

KubeFlow Pipelines

Kubeflow Pipelines (KFP) is a platform for building and deploying portable and scalable machine learning (ML) workflows using Docker containers.

Some of the main characteristics of kubeflow pipelines are

• Kubernetes-Native: Designed for running on Kubernetes, making it ideal for containerized applications.

• Machine Learning (ML) Focused: Specifically built to manage ML workflows, including model training, deployment, and monitoring.

• Parameterization and Iteration: Great support for hyperparameter tuning, parameterized runs, and experiment tracking.

• Integration with ML Tools: Works well with TensorFlow, PyTorch, and other popular ML frameworks.

Dagster

Dagster models pipelines in terms of the data assets they produce and consume, which, by default, brings order and observability to your data platform. Assets in Dagster can model data produced by any system, such as dbt models, Snowflake tables, or even CSV files.

Main characteristics of Dagster are

• Type-Safe and Data-Driven: Incorporates type-safety and data validation, making it a popular choice for data-centric applications.

• Modular and Component-Based: Allows users to manage individual tasks as reusable modules, simplifying complex workflows.

• Strong Debugging and Testing Support: Provides tools for developing, testing, and debugging data pipelines.

In future articles, we’ll dive deep into each of these and see how we can set these up fast and understand their fundamentals and intermediate concepts. If you’re interested in reading about them or similar topics, feel free to subscribe to my blog for free using the button below.

Thanks for reading! I hope you have a wonderful day!

It’s been a few years since I’ve been working as a software engineer. During this time, I’ve worked on various domains - backend, data science, data engineering, devops to name a few. I’ve worked for multiple organizations ranging from the biggest names in tech to small scale startups building products from the ground up.

Here are 5 things that I’ve learned in the last 8 years of my software engineering career that no one told me about, when I started. And note that are all of these are skills that you can hone and sharpen over the course of your own journey

Growth mindset is your most important asset

A growth mindset is the belief that abilities and intelligence can be developed over time through effort, learning, and persistence. This concept was popularized by psychologist Carol Dweck. In contrast to a "fixed mindset"—the belief that abilities are static and unchangeable—a growth mindset encourages a person to view challenges as opportunities to grow, embrace failure as a learning experience, and focus on improvement rather than fearing mistakes.

People with a growth mindset tend to:

• Believe that effort leads to improvement.

• Embrace challenges rather than avoid them.

• Learn from criticism and feedback.

• Persist in the face of setbacks.

In your professional setting, you’re going to receive critical feedback. Whether you’ve just started or have reached more than 20 years in your discipline, one always makes mistakes and one can always be better. To become better however, you have to learn how to not take feedback personally but instead, see the situation objectively. What could you indeed do better? Is there something you missed? Instead of being hard on yourself, that you made a mistake, remember that you’re human and even if you’re one of the best in your field, there’ll always be room for growth. Be kind to yourself and allow yourself to grow, allow yourself to see things that you can do better, and make it a habit. Like a plant by design, always grows towards light, allow yourself to always find your way towards growth.

Your only competition is you

You’ve heard this countless times and hence I’m not gonna bore you with an explanation of this. Compete with your yesterday’s self and not other engineers, people etc. You may have been conditioned to compare yourself with others, by your family, teachers etc, but it is time that you unlearn this mindset and grow a mindset of getting better than what you were yesterday. Focus on consistent growth instead of impulsive growth and you’ll find yourself finding your direction much more easily than others

Stakeholders are not your enemies

If you’re working as an engineer, you’ve at least once blamed the problem on a stakeholder. It’s either - “Requirements change way too often.” or “I don’t understand why they can’t make up their mind”. As a software engineer, it’s easy to fall into the trap of viewing stakeholders—be they product managers, business leaders, designers, or clients—as adversaries or obstacles in the development process. This mindset often stems from a perception that stakeholders are out to impose unrealistic demands, disrupt your workflow, or dictate technical decisions without understanding the complexities of software engineering.

This mindset won’t help you. And what doesn’t help can change for good. Stakeholders are your partners in creating successful products. They’re not your enemies—they’re the key players who ensure that your work aligns with business goals, user needs, and market realities. In order to become a better engineer, you need to understand your product. And it’s very likely that you do not understand your product as well as your stakeholders do. Here are some things that you can do to understand your stakeholders better and to co-partner with them in building great products

1. Understand your customers. One of the primary roles of stakeholders is to advocate for the needs and desires of the customer or end-user. As a software engineer, you may not always have direct access to the people using the product, but stakeholders do. Their job is to gather insights, feedback, and market research, ensuring that what you build solves real problems and provides value.

2. Understand the context for decision making. Stakeholders often hold a broader view of the product's goals, vision, and market positioning. While you may be an expert in how things work from a technical perspective, stakeholders understand why those things matter in the larger business context. They can provide critical context when making decisions about features, timelines, and trade-offs.

3. Most stakeholders come from non-tech backgrounds. They can give you insights about your work, that may not be apparent to you. There’s a huge potential for growth by analyzing the perspective of someone who comes from a different background than you, and sees the world differently than you.

In truth, once I learned this myself, I started having a much better time in my stakeholder talks. I became friends with many of them, and I’ve had great discussions with some of my stakeholders and continue to enjoy spending time with them outside of work as well.

Being a problem solver is better than being a language specialist

In the world of software engineering, there's often a debate about the best path to success: Should you become an expert in a particular programming language or framework, or should you focus on developing problem-solving skills that are language-agnostic? While mastering a specific technology might give you deep expertise, becoming a versatile problem solver can offer far more long-term career benefits. It’s important to remember

Languages Are Tools, Not the End Goal

At its core, software engineering is about solving problems and building solutions. Languages, frameworks, and tools are just the means to that end. Whether you're working with Python, JavaScript, Java, C++, or even newer languages like Rust or Go, the programming language itself is just a tool to implement your ideas. What truly matters is your ability to break down complex problems and devise effective, efficient solutions, regardless of the technology stack you’re using.

It’s a rapidly Changing Industry

The tech industry evolves at a breakneck pace. New programming languages, libraries, and frameworks are being introduced constantly, and tools that were popular a few years ago may become obsolete or less relevant. A language specialist may find themselves tied to a technology that has lost favor in the industry, whereas a problem solver has the flexibility to pick up new tools and technologies as needed.

Being adaptable makes you more marketable and more likely to succeed over the long term, as you can take on a broader range of projects and adjust to the needs of your organization or the industry.

Cross-Disciplinary Expertise

In modern software development, projects often require collaboration with professionals from diverse disciplines, including UX/UI designers, product managers, QA testers, data engineers, and even non-technical stakeholders. A problem solver is better equipped to work in these cross-functional teams because they can communicate solutions and trade-offs in terms that everyone can understand—whether it's a technical team member or a business stakeholder.

This skill is especially crucial as software engineering has shifted towards full-stack development, where engineers are required to have a broader range of knowledge across both front-end and back-end development, as well as cloud infrastructure, databases, and security.

Long-Term Career Flexibility

Career longevity in software engineering is largely driven by your ability to adapt and solve problems rather than your deep knowledge of a specific technology. As the industry shifts and new trends emerge (such as the rise of AI, blockchain, and cloud computing), your ability to learn and apply new technologies quickly becomes much more important than your expertise in a particular language.

True Value Lies in Delivering Results

In the end, software engineering is about delivering results that meet user needs and business goals. While mastering a particular language might make you technically proficient in certain areas, the ability to consistently deliver effective solutions to real-world problems is what will make you stand out as an exceptional engineer.

Feynman technique for learning things

The Feynman Technique is a powerful method for learning and deeply understanding concepts, named after the Nobel-winning physicist Richard Feynman, who was known for his ability to explain complex scientific ideas in simple, clear terms. This technique involves four simple steps that help you internalize information and identify gaps in your understanding. Here’s how it works:

Choose a Concept You Want to Learn

The first step is to pick the topic or concept you want to understand. This could be anything from a specific software engineering concept like recursion or object-oriented design, to a broader topic like machine learning or quantum physics. The idea is to select something that you either don’t know well yet or want to deepen your understanding of.

Teach It to a Child (or Anyone Without Expertise)

This is the heart of the Feynman Technique: explain the concept as if you're teaching it to someone with no prior knowledge of the subject. The idea is to simplify the topic to the point where even a young child could understand it.

In the context of software engineering, this could mean explaining an abstract concept like polymorphism to a beginner by using everyday analogies (e.g., "Think of a car. A car can be driven, but depending on the car, the type of fuel it uses or the engine under the hood may differ, just like how polymorphism allows different classes to use the same method but behave differently.").

This step forces you to get rid of jargon and complex language, and distill the information to its most fundamental, easy-to-understand points. If you struggle to explain something, it’s a clear sign that your understanding of the concept isn’t as deep as it needs to be.

Identify Gaps in Your Knowledge

After attempting to explain the concept simply, you'll likely realize parts of the explanation are unclear or incomplete. This is where you spot gaps in your knowledge. If you can't explain a particular part of the concept easily, or if you’re unsure about certain details, it indicates that you need to study those parts more deeply.

At this stage, go back to your source material—be it textbooks, tutorials, or documentation—and review the areas that are unclear. This might involve re-reading concepts, seeking alternate explanations, or practicing the material through examples and exercises.

Simplify and Refine Your Explanation

Once you've identified your knowledge gaps and filled them in, go back and simplify your explanation again. The goal is to make your understanding as clear and concise as possible. This final step often involves refining your ability to explain the concept in an even more accessible way, ensuring that the information is both accurate and easy to understand.

Why It Works

The Feynman Technique works because it encourages active engagement with the material. Rather than passively reading or listening to explanations, you are forced to process and organize the information in your own words. This makes you internalize it much more deeply.

Additionally, by teaching the material to someone else (real or imaginary), you simulate a situation where you have to explain things clearly, which makes you more likely to remember and understand the topic thoroughly. The process of identifying gaps in your knowledge also ensures that you're constantly learning and improving.

Example: Feynman Technique in Software Engineering

Let’s say you want to learn about Asynchronous Programming in JavaScript. Here’s how you might apply the Feynman Technique:

1. Choose the Concept: Asynchronous Programming (Promises, async/await).

2. Teach It to a Child: Explain it like you're teaching a beginner or a child.

   • "Imagine you’re making a sandwich. Instead of waiting for the sandwich to be made before you can eat, you start another task, like making a smoothie. When the sandwich is ready, you come back to it. Asynchronous programming is like that—you don’t wait for one thing to finish before starting something else. You can work on multiple tasks at once."

3. Identify Gaps: While trying to explain it, you may realize you aren’t sure how Promises handle multiple tasks or how error handling works in asynchronous code. You go back and read up on Promise chaining or error handling in async/await.

4. Refine Your Explanation: After you’ve filled in your gaps, you rephrase your explanation:

   • "Asynchronous programming lets you start one task (like making a smoothie) while waiting for another (like the sandwich) to be completed. When the sandwich is done, you handle it. In programming, a Promise is like a waiter that will give you your sandwich when it’s ready. If something goes wrong, the waiter can tell you with an error message."

This was a long article. If you’ve made it so far, congratulations. You’re one of the rare people who are able to retain attention in a world where people are finding it harder and harder to concentrate. If you liked reading this, consider subscribing to this substack. I’ve reading and implementing ways to be more productive, and do meaningful work since the last 4 years and I’d like to share some of those things with the world. You may find some thing of value here afterall…

Subscribe now

I've been using Visual Studio Code (VS Code) for about five years now, and it has truly transformed the way I code for both personal and professional projects. This lightweight, open-source code editor has a fantastic ecosystem of extensions that enhance its functionality and make it an indispensable tool for developers. In this article, I'll share some of the best extensions that have helped me streamline my coding process and boost my productivity.

Visual Studio Live Share

VS Code live share extension is a game-changer for collaborative coding. It allows you to share your workspace in real-time with team members or colleagues, making it easier than ever to pair program, debug, and troubleshoot together. With Live Share, you can edit code simultaneously and even share your debugging session, which is incredibly helpful for remote work or distributed teams.

GitLens

For version control aficionados, GitLens is a must-have extension. It supercharges your Git experience within VS Code, providing an array of features like inline blame annotations, commit history exploration, and code lens for commit references. With GitLens, you'll have a deeper understanding of your code's history and who made what changes.

Remote Development Extensions

With the rise of remote and distributed work, the Remote Development extension pack is a valuable addition. It includes extensions like Remote - SSH, Remote - Containers, and Remote - WSL, which enable you to develop in remote environments seamlessly. Whether you need to code on a remote server, inside a Docker container, or on Windows Subsystem for Linux (WSL), these extensions have you covered.

Bookmarks

The Bookmarks extension in VS Code is a lifesaver when it comes to finding code snippets swiftly and programming with greater efficiency. It allows you to mark specific lines of code with bookmarks, which act as handy signposts for later reference. Whether you need to quickly revisit a critical section of code, navigate between different parts of a file, or keep track of important TODOs, bookmarks make it a breeze. With a single keyboard shortcut, you can toggle through your bookmarks, making it easy to jump to precisely where you need to be in your codebase. This feature not only enhances productivity but also reduces the time spent scrolling and searching, helping you code more effectively.

Dev Containers

The Dev Containers extension in VS Code revolutionises the way developers set up and maintain local development environments. It ensures consistency and streamlines the process of configuring development environments across a team. With Dev Containers, you can define your development environment as code, specifying all the necessary dependencies, tools, and configurations in a single configuration file. When a team member opens the project, VS Code automatically detects and prompts them to create or reopen the project in the specified development container. This not only saves time but also eliminates the "it works on my machine" problem, as all developers work within the same, standardized environment. Dev Containers truly fosters collaboration and ensures that every team member is on the same page, making development smoother and more efficient

Github Copilot

GitHub Copilot is like having a coding buddy who's not only super smart but also tons of fun to work with! It's your secret weapon for turbocharging software projects. Copilot helps you write code faster by suggesting what you need as you type, saving you time and effort. Plus, it makes coding feel like a game, thanks to its friendly and helpful suggestions. It's like having your very own co-pilot on the coding adventure, and it turns even complex projects into a breeze. With Copilot, software development becomes a fast, fun, and approachable journey that you'll look forward to every day!

Code Spell Checker

The Code Spell Checker extension in VS Code is a silent hero for programmers. It effortlessly catches spelling errors in your code and comments, ensuring that your communication is clear and professional. By preventing typos and misspellings from slipping through the cracks, this extension saves you the time and embarrassment of correcting them later. It's a small but incredibly valuable tool that helps you code with confidence, making you not only more efficient but also a more polished programmer.

Better Comments

The Better Comments extension in VS Code is very useful when it comes to writing meaningful and useful comments in your code. It adds color coding and custom syntax to your comments, making it easy to categorize and prioritize them. Whether you want to highlight important to-dos, mark code for review, or simply provide clarity within your codebase, this extension ensures that your comments are not just an afterthought but an integral part of your programming process. It encourages better documentation practices, ultimately improving code readability and collaboration within your team. With Better Comments, you'll find that your comments are no longer an obligation but a valuable asset in your programming journey.

Conclusion

Visual Studio Code's extensibility is one of its most significant strengths, allowing developers to tailor their coding environment to their specific needs. As someone who has relied on VS Code for half a decade, I can attest to the immense value these extensions bring to the table. Whether you're working on personal projects, collaborating with a team, or tackling complex codebases, these extensions will undoubtedly help you code faster, smarter, and with fewer headaches. Give them a try, and you'll wonder how you ever coded without them!

Overview

If you're like me and want an easy way to make and publish your website, this article is for you. I'll cover how I made and deployed this current site with minimal effort and zero investment.

Hugo is a static HTML and CSS website generator written in [Go](https://golang.org/). It is optimized for speed, ease of use, and configurability. Hugo takes a directory with content and templates and renders them into a full HTML website.

Some of it's key features are

1. Relies on Markdown files with front matter for metadata

2. Renders a typical website of moderate size in a fraction of a second

3. Is designed to work well for any kind of website including blogs, tumbles, and docs

Installation

Hugo is very simple to install. There are two things that you require

1. An installation of Golang

2. Installation of Hugo

Hugo can be easily installed if you have homebrew with

brew install hugo

If you're not on Mac or you don't have homebrew to install software and dependencies, here's the official installation documentation.

Quick start

Bootstrapping a website is as simple as running the command below

hugo new site quickstart

The theme I'm using for this website is the Anake theme. I'll explain how I set up this theme for this website. The complete list of themes for Hugo can be found at [themes.gohugo.io](https://themes.gohugo.io/)

Now, that we've picked up a theme, we'll do some quick setup by cloning the theme as a git submodule within our repository

cd quickstart
git init
git submodule add https://github.com/theNewDynamic/gohugo-theme-ananke.git themes/ananke
echo theme = \"ananke\" >> config.toml

Let's now add some content to our site with

hugo new posts/my-first-post.md

Let's now start the Hugo server with

hugo server -D

This is what should be visible when you navigate to localhost:1313

The website is now running locally on our machine.

Let's deploy

Websites can be hosted at a bunch of places easily. One of my favorite solutions to deploy my website for free is [netlify](https://www.netlify.com). You can sign up for a free account and have your website deployed in no time.

The best part about Netflify is that setting up a continuous deployment pipeline from github is fairly straightforward. Netflify will build your wesbite for you, and deploy it, while providing you a DNS service, if you're planning to use a personal domain. So the only investment I had in hosting is buying my own domain, which I bought separately from google domains. I'd highly encourage you to get a domain for yourself, if you don't have one already.

Here are the steps to deploy your freshly created website on netlify using github.

Prerequisites

1. Github account

2. Netflify account

Steps

1. Create a new file in your repo with the name netflify.toml and add the following

 [build]

    publish = "public"

    command = "hugo --gc --minify"

    [context.production.environment]

    HUGO_VERSION = "0.101.0"

    HUGO_ENV = "production"

    HUGO_ENABLEGITINFO = "true"

    [context.split1]

    command = "hugo --gc --minify --enableGitInfo"

    [context.split1.environment]

    HUGO_VERSION = "0.101.0"

    HUGO_ENV = "production"

    [context.deploy-preview]

    command = "hugo --gc --minify --buildFuture -b $DEPLOY_PRIME_URL"

    [context.deploy-preview.environment]

    HUGO_VERSION = "0.101.0"

    [context.branch-deploy]

    command = "hugo --gc --minify -b $DEPLOY_PRIME_URL"

    [context.branch-deploy.environment]

    HUGO_VERSION = "0.101.0"

    [context.next.environment]

    HUGO_ENABLEGITINFO = "true"

    [[redirects]]

    from = "/npmjs/*"

    to = "/npmjs/"

    status = 200

2. Check-in your code on github. Your repo should now look something like this

3. Open netlify and sign in with your github credentials. Alternatively, we can connect our github account later as well.

4. Now we need to allow netflify access to our repositories. We can follow the principle of least privilege here and only allow netlify access to the one repository containing our website code

5. Now, that we have our repo accessible from Netlify, Netlify will be able to see every time we push a new commit on github. This will ensure that our website is built and deployed automatically.

Our deployed site

At the end of the build-deploy stage, our website will get deployed to a unique url generated by netlify. We can always set up our own domain using Netflify DNS, but I won't be covering that in this post. Our newly website should now be running and looking something like this

Hugo provides multiple features for easy creation of new posts, image processing etc. For full documentation, please refer the official hugo docs