DEV Community: Sh Raj

MCP vs API: What's the Difference? A Visual Guide for Developers

Sh Raj — Sat, 10 Oct 2026 19:45:24 +0000

MCP vs API: What's the Difference? A Visual Guide for Developers

Imagine building an AI assistant that can search GitHub issues, query databases, read documentation, create tasks, and send Slack messages.

All these services already have APIs.

So, why do we need MCP?

Is MCP replacing APIs? Is it just another type of API? And what actually happens when an AI agent calls a tool?

Let's break it down, from the fundamentals to production architecture.

1. First, what is an API?

An API (Application Programming Interface) defines how one piece of software can interact with another.

For example, imagine a task management application that exposes this endpoint:

GET /api/tasks/42
Authorization: Bearer YOUR_TOKEN

It returns:

{
  "id": 42,
  "title": "Fix login bug",
  "status": "in_progress",
  "assignee": "Sh"
}

Your application knows which endpoint to call, what authentication to provide, and how to interpret the response.

APIs aren't limited to REST or HTTP. They can also be library interfaces, GraphQL APIs, RPC interfaces, and more.

How does a typical API request work?

flowchart TD
    A[Frontend or Backend Client] -->|HTTP Request| B[API Server]
    B --> C[Authentication and Validation]
    C --> D[Business Logic]
    D --> E[(Database)]
    E --> D
    D --> B
    B -->|HTTP Response| A

The client constructs the request. The server validates it, executes the operation, and returns a result.

Simple enough!

But now imagine letting an AI model use hundreds of these APIs.

That's where things get interesting.

2. The problem: APIs weren't designed specifically for AI tool interoperability

Suppose you're building an AI coding assistant.

You want it to:

Read files from GitHub.
Search GitHub issues.
Query a PostgreSQL database.
Create tasks in Linear.
Read external documentation.
Send messages to Slack.

Each service may already provide an API.

However, your AI application still needs to understand:

Which operations are available.
What arguments each operation expects.
How to invoke an operation.
How to handle its output and errors.
How to manage credentials and permissions.
How to expose the capability to the AI model.

Traditionally, developers build custom integration code for these tasks.

flowchart TD
    A[AI Application] --> B[GitHub Adapter]
    A --> C[Database Adapter]
    A --> D[Slack Adapter]
    A --> E[Linear Adapter]

    B --> F[GitHub API]
    C --> G[(PostgreSQL)]
    D --> H[Slack API]
    E --> I[Linear API]

This works, but each integration can require its own implementation and maintenance.

Now imagine building another AI application that needs access to the same services.

You may end up repeating much of the integration work.

The problem isn't that APIs don't work with AI. The problem is that every AI application shouldn't have to reinvent the integration contract for every tool.

3. What is MCP?

MCP stands for Model Context Protocol.

It's an open protocol that standardizes how AI applications connect to external systems that provide tools, data, and reusable prompts.

Think of MCP as a common language for AI applications and the services that expose capabilities to them.

Instead of creating a completely different integration mechanism for every AI client, developers can expose capabilities through an MCP server.

Compatible clients can then discover and invoke those capabilities through a shared protocol.

The MCP architecture

flowchart TD
    A[User] --> B[AI Host]
    B --> C[AI Model]
    B --> D[MCP Client]

    D <-->|MCP Protocol| E[MCP Server]

    E --> F[Tools]
    E --> G[Resources]
    E --> H[Prompts]

    F --> I[APIs and Business Logic]
    G --> J[Files and Data Sources]
    H --> K[Reusable Templates]

There are three important components:

1. Host: The AI-enabled application coordinating the model and integrations.

2. Client: The component that communicates with an MCP server.

3. Server: The program that exposes capabilities through MCP.

An MCP server doesn't necessarily run on a remote machine. It can be a local process communicating through standard input/output (stdio), or a remote service using Streamable HTTP.

MCP's three core primitives

Primitive	Purpose	Example
Tools	Execute operations	`create_issue`
Resources	Provide contextual data	Database schema
Prompts	Provide reusable templates	Code review instructions

Tools can read data or modify state. Resources provide information that an application can use as context. Prompts define reusable interaction templates.

Not every MCP server needs to implement all three.

4. MCP vs API: the fundamental difference

Here's the simplest way to understand it:

An API defines how to interact with a service. MCP standardizes how AI applications discover and interact with capabilities exposed by a server.

These concepts are related, but they're not interchangeable.

Side-by-side comparison

Feature	API	MCP
Primary purpose	Expose functionality or data	Standardize AI-to-tool/context integration
Interface	Endpoints, functions, queries, RPC methods, etc.	Protocol messages and capability schemas
Discovery	Documentation, SDKs, schemas, or custom mechanisms	Protocol-defined capability discovery
AI-specific design	Not inherently	Designed for AI application integrations
Actions	Depends on the API	Tools expose callable operations
Context	Depends on the API	Resources can provide contextual information
Reusable prompts	Not a defining feature	A defined primitive
Transport	Depends on the API	Commonly stdio or Streamable HTTP
Can coexist with the other?	Yes	Yes

MCP uses JSON-RPC 2.0 for protocol messages. It can use HTTP for remote communication, but it isn't simply another name for a REST API.

An analogy

Imagine a restaurant.

API = the restaurant's ordering interface.

The menu describes what you can order, the available options, and how to submit an order.

MCP = a standardized ordering interface for compatible AI applications.

Different AI applications can discover available operations and invoke them through a common protocol.

The analogy isn't perfect, but it captures the central idea: standardizing how you interact with a service doesn't eliminate the service itself.

5. A real example: building a GitHub issue assistant

Let's say you ask an AI assistant:

"Find the open authentication bugs in my repository and summarize the most urgent ones."

Your assistant needs to search GitHub issues and retrieve their details.

Option A: Direct GitHub API integration

A developer could call GitHub's REST API:

GET /repos/OWNER/REPO/issues?state=open&labels=bug
Authorization: Bearer GITHUB_TOKEN
Accept: application/vnd.github+json

The application must then:

Authenticate with GitHub.
Make the HTTP request.
Handle pagination and rate limits.
Parse the response.
Define a tool the AI model can invoke.
Execute that tool when requested.
Return the results to the model.

A simplified model-facing tool definition might look like this:

const tools = [
  {
    type: "function",
    name: "search_github_issues",
    description: "Search open issues in a repository",
    parameters: {
      type: "object",
      properties: {
        owner: { type: "string" },
        repo: { type: "string" },
        label: { type: "string" }
      },
      required: ["owner", "repo", "label"],
      additionalProperties: false
    },
    strict: true
  }
];

This describes the tool the model can request. Your application still needs to implement the function that calls GitHub.

The API defines how to access GitHub. The tool definition tells the model how to request that access.

Option B: Expose the capability through MCP

An MCP server could expose a tool called search_issues.

A compatible client can discover the tool and its input schema, then request its execution.

An illustrative schema might look like this:

{
  "name": "search_issues",
  "description": "Search issues in a repository",
  "inputSchema": {
    "type": "object",
    "properties": {
      "owner": { "type": "string" },
      "repo": { "type": "string" },
      "state": {
        "type": "string",
        "enum": ["open", "closed", "all"]
      }
    },
    "required": ["owner", "repo", "state"]
  }
}

This is a simplified example of a tool definition, not a complete MCP protocol exchange.

The MCP server might internally call GitHub's REST API. The client doesn't need to know the underlying endpoint URL or HTTP headers if the server handles those details.

The complete flow

sequenceDiagram
    participant U as User
    participant A as AI Host
    participant M as MCP Client
    participant S as MCP Server
    participant G as GitHub API

    U->>A: Find authentication bugs
    A->>M: Discover available tools
    M->>S: tools/list
    S-->>M: Tool definitions
    A->>M: Call search_issues
    M->>S: tools/call
    S->>G: HTTP API request
    G-->>S: Issue data
    S-->>M: Tool result
    M-->>A: Return results
    A-->>U: Summarize urgent bugs

The host coordinates the model and tool execution. The MCP client handles protocol communication. The MCP server executes the operation, potentially using an existing API.

MCP doesn't replace GitHub's API. It provides a standardized AI-facing interface to the capability.

6. Build a simple MCP server with TypeScript

Let's make the example more concrete.

Imagine you already have a backend endpoint:

GET /api/tasks/:id

You want compatible AI applications to retrieve tasks through MCP without rewriting the backend.

Step 1: Install the SDK

npm install @modelcontextprotocol/sdk zod

Step 2: Create the server

The following example demonstrates the MCP server pattern using TypeScript:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from
  "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({
  name: "task-server",
  version: "1.0.0"
});

server.registerTool(
  "get_task",
  {
    description: "Get a task by its numeric ID",
    inputSchema: {
      id: z.number().int().positive()
    }
  },
  async ({ id }) => {
    const response = await fetch(
      `https://your-api.example.com/api/tasks/${id}`
    );

    if (!response.ok) {
      throw new Error(`Task API returned ${response.status}`);
    }

    const task = await response.json();

    return {
      content: [
        {
          type: "text",
          text: JSON.stringify(task)
        }
      ]
    };
  }
);

const transport = new StdioServerTransport();

await server.connect(transport);

This example assumes an SDK version that supports the shown registration pattern. Check the official TypeScript SDK documentation for the exact version-specific API.

Replace the placeholder URL with your actual backend and implement appropriate authentication, timeouts, authorization, and error handling.

What happens when the AI calls `get_task`?

The MCP client discovers get_task.
The model decides that the tool is relevant.
The host orchestrates the tool call.
The client sends the request through MCP.
The server validates the input and calls the existing API.
The server returns the task information.
The model uses the result to answer the user.

The MCP server acts as an adapter between the protocol and your existing service.

It doesn't eliminate your backend's business logic or security requirements.

7. When should you use MCP instead of a direct API integration?

Neither approach is universally better.

Use a direct API integration when:

You have one application you control.
You need a small number of fixed operations.
You want explicit control over requests and orchestration.
A separate protocol adapter would add unnecessary complexity.

Consider MCP when:

Multiple compatible AI clients need the same capabilities.
You want standardized tool discovery.
You want to expose reusable contextual resources.
You want to separate AI-facing integrations from backend implementations.
You are building an ecosystem of tools for AI agents.

The best production architecture may use both

flowchart TD
    A[Existing Backend] --> B[REST API]
    A --> C[Internal Service Layer]

    B --> D[Web and Mobile Apps]
    C --> E[MCP Server]

    E --> F[AI Client 1]
    E --> G[AI Client 2]
    E --> H[AI Client 3]

Your web and mobile applications can continue using the existing API, while compatible AI clients use MCP to access selected capabilities.

You don't need to rebuild your entire backend to support MCP.

8. Advanced considerations

8.1 Integration complexity

Suppose you have N AI applications and M external services.

With fully custom integrations, the potential number of application-to-service adapters can approach:

N × M

With compatible clients and servers using a shared protocol, the integration structure can often move toward:

N + M

This is a simplified architectural model, not a guaranteed reduction in engineering effort. Custom authentication, unsupported features, configuration, and service-specific logic can still require substantial work.

The advantage becomes more significant as the number of integrations grows.

8.2 Latency and performance

MCP does not automatically make requests faster.

A direct integration might look like:

Application → API → Application

An MCP integration might look like:

AI host → MCP client → MCP server → API

The second approach may add serialization, protocol handling, or network overhead.

However, an MCP server can also expose higher-level operations that reduce unnecessary round trips.

For example, a single summarize_project_health tool might internally retrieve issues, pull requests, and project metadata, then return a consolidated result.

Any performance improvement comes from the implementation and tool design, not from MCP alone.

8.3 Security is still your responsibility

MCP is not a security guarantee.

An MCP server may expose powerful capabilities such as reading files, querying databases, or modifying business records.

Production systems should implement:

Least-privilege credentials.
Server-side authorization.
Strict input validation.
Explicit confirmation for sensitive or destructive actions when appropriate.
Protection against prompt injection and untrusted tool output.
Secure secret management.
Audit logging and appropriate monitoring.
Duplicate-action safeguards for operations that need idempotency.

A tool description saying "read-only" is not a substitute for enforcing read-only access in the server.

The system must enforce permissions independently of what the model requests.

9. Common misconceptions

Myth 1: MCP replaces APIs.

No. MCP servers frequently call existing APIs. Both can coexist.

Myth 2: MCP is just another REST API.

No. MCP uses JSON-RPC 2.0 messages and defines an AI-oriented client-server protocol. Remote MCP can use HTTP as its transport.

Myth 3: Every API needs an MCP server.

No. Direct API calls remain perfectly reasonable for simple, fixed integrations.

Myth 4: MCP makes AI models smarter.

No. MCP provides standardized access to capabilities and context. The model, orchestration logic, available information, and tool design still determine the quality of its work.

Myth 5: MCP automatically makes applications secure.

No. Authentication, authorization, isolation, and approval workflows remain essential.

Myth 6: MCP servers must be remote.

No. MCP supports local stdio communication as well as remote Streamable HTTP.

10. Frequently asked questions

Is MCP an API?

MCP is a protocol that defines how compatible applications communicate with servers. It can expose capabilities backed by APIs, but the two are different interfaces.

Can I use MCP with a REST API?

Yes. An MCP server can translate tool calls into REST requests without requiring the underlying REST API to implement MCP.

Can I use APIs without MCP?

Absolutely. Traditional applications and AI applications can call APIs directly.

Is MCP the same as function calling?

No. Function calling lets a model request that an application execute a function. MCP standardizes communication with servers that expose tools and other capabilities. An MCP client can connect these capabilities to a model's tool-calling mechanism.

Does MCP work with any AI model?

MCP is model-independent at the protocol level. However, the host application must implement MCP support and integrate the discovered capabilities with its model.

Is MCP useful for agentic AI?

Yes. MCP can provide tools and contextual information for agents. Planning, reasoning, execution loops, and decision-making are separate concerns.

11. Further reading

If you want to go deeper, start with these resources:

These resources cover protocol concepts, implementation details, and practical integrations.

12. The final mental model

Remember these three layers:

Layer 1 — Reasoning: The AI model interprets the request and selects a capability.

Layer 2 — Integration: MCP or application-specific tool integration makes the capability discoverable and callable.

Layer 3 — Execution: APIs, databases, and business logic perform the actual work.

For example, the AI model decides to create a GitHub issue. The integration layer exposes create_issue. The underlying service checks permissions and creates the issue.

That separation is the core idea.

An API exposes functionality. MCP standardizes how AI applications can discover and access functionality.

They are complementary technologies, and many strong architectures use both.

Written for developers exploring AI integrations, MCP servers, and modern software architecture.

What do you think? Are you already using MCP in your projects, or are you still integrating AI tools directly through APIs? Share your experience in the comments!

How Hackers Mod APKs: Android Reverse Engineering Explained

Sh Raj — Sat, 10 Oct 2026 19:03:55 +0000

How Hackers Mod APKs: Inside Android Reverse Engineering, Runtime Analysis, and App Integrity

By StackShade · Android Security · Reverse Engineering

How does a modified Android application emerge even after developers add obfuscation, server-side validation, and integrity checks? The answer lies in understanding where an application executes, where its trust decisions live, and what an attacker can observe or control.

1. Introduction: The Endless Battle Over Modified APKs

In the video How Hackers Mod APKs, Manguman opens with the recurring problem of modified versions of popular applications breaking after backend changes, only for new versions to appear later.

The video uses Spotify, Netflix, and mobile games to illustrate a broader security problem: developers invest heavily in protecting their applications, yet unauthorized modifications remain possible.

The apparent contradiction disappears when we distinguish between making software difficult to modify and making unauthorized behavior impossible to authorize.

An Android application is a package of executable code, resources, configuration, and sometimes native libraries. Much of its behavior executes on a device that the developer does not physically control. A determined analyst can inspect the package, observe execution, and experiment with the application in a controlled environment.

Developers therefore use several layers of protection:

Code obfuscation to increase the cost of understanding an application.
Server-side authorization to keep valuable decisions outside the client.
Transport security to protect communications.
Integrity verification to identify potentially modified applications or untrusted environments.
Runtime defenses and abuse detection to respond to suspicious behavior.

None of these controls solves every problem independently.

The central security principle

If an attacker controls the client environment, any security decision made exclusively by that client should be treated as potentially manipulable.

This does not mean every Android device is compromised or every local check is useless. It means that client-side checks should not be the sole authority for valuable server-controlled operations.

2. Understanding the Android APK

Before examining reverse engineering, we need to understand what an APK actually contains.

An APK, or Android Package Kit, is an archive containing the files needed to install an Android application. Depending on the application, these can include:

AndroidManifest.xml — application components, permissions, and configuration.
classes.dex — compiled Android bytecode.
res/ — compiled resources such as layouts and drawable assets.
assets/ — application-specific files.
lib/ — native libraries, often compiled for particular CPU architectures.
META-INF/ and signing-related information — package metadata and signature-related artifacts, depending on the package and signing scheme.

An APK is not simply a Java source-code directory compressed into a ZIP file.

2.1 From Java or Kotlin to executable Android code

Consider a simplified Android build pipeline:

flowchart TD
    A["Java / Kotlin source"] --> B["Compiler output"]
    B --> C["DEX bytecode"]
    C --> D["APK packaging"]
    D --> E["APK signing"]
    E --> F["Installation and execution"]

This is a conceptual view rather than a complete build pipeline. Android Gradle Plugin, D8, R8, resource processing, desugaring, native compilation, and signing may introduce additional stages.

The important point is that the installed package contains compiled representations, not necessarily the original source code.

Android Studio's APK Analyzer can inspect the final package, its DEX files, resources, manifest, and size distribution. This is useful both for debugging your own build and for authorized security analysis.

Technical reference: Android Developers, Analyze your build with APK Analyzer.

2.2 DEX versus Smali

The video introduces DEX and Smali as different representations of application logic.

DEX, or Dalvik Executable, is a bytecode format designed for Android's runtime environment. ART executes DEX-based application code.

Smali is a human-readable assembly-like representation of DEX instructions. It exposes operations such as register access, method invocation, conditional branching, and returning values.

For example, the following is an illustrative Smali-like fragment:

.method public isFeatureEnabled()Z
    .locals 1

    const/4 v0, 0x1
    return v0
.end method

The method returns a boolean value of true.

This example demonstrates the representation, not a modification to any real commercial application.

A corresponding high-level method might look like this:

boolean isFeatureEnabled() {
    return true;
}

However, decompilation is not a perfect reversal of compilation. The reconstructed Java may have different names, missing comments, altered control flow, synthetic methods, or other differences from the original source.

Important distinction: Smali is not the original Java source code, and a decompiler cannot reliably recover information that was discarded during compilation.

3. Static Analysis: Understanding an Application Without Running It

Static analysis examines an application or its code without requiring the relevant functionality to execute.

The video describes a workflow in which an analyst decompiles an APK, searches through the resulting representation, and tries to understand how particular features work.

The underlying technique is legitimate and widely used in malware analysis, vulnerability research, compatibility testing, and software auditing.

3.1 Why static analysis works

Compiled code still has structure.

Even when meaningful identifiers disappear, an analyst may be able to infer functionality from:

Method parameters and return types.
Conditional branches and control flow.
String constants and resource identifiers.
Network endpoints and request models.
Calls into Android framework APIs.
Serialization and deserialization logic.
References between classes and methods.

For example, a method that reads a subscription status, parses a response, and selects a user interface state may remain recognizable from its surrounding data flow, even if its original class and method names are unavailable.

This is why renaming methods alone does not eliminate the information contained in program behavior.

3.2 The danger of trusting local feature flags

Suppose an application contains a local feature flag:

boolean canUseAdvancedFeature = false;

If the application uses this value as the sole authority for a valuable operation, the architecture is weak.

A local boolean can influence what the interface displays. But displaying a premium button and authorizing a premium transaction are fundamentally different operations.

A more robust architecture asks the backend to authorize the actual operation.

flowchart TD
    A["User requests a feature"] --> B["Android client"]
    B --> C["Authenticated API request"]
    C --> D["Backend authorization"]
    D --> E{"Entitled?"}
    E -->|Yes| F["Perform authorized operation"]
    E -->|No| G["Reject operation"]

The server must enforce the decision independently of the interface.

A modified interface might still display an enabled button, but that should not grant access to protected data or change a server-controlled account balance.

3.3 Obfuscation is not encryption

The video correctly identifies obfuscation as a technique for making code harder to understand.

Modern Android builds commonly use R8 to optimize and obfuscate application code. Depending on configuration, this can include renaming classes and methods, removing unreachable code, and simplifying program structure.

Consider the conceptual difference:

Technique	Primary purpose
Minification	Reduce application size by removing unnecessary code
Obfuscation	Make program structure and intent harder to understand
Encryption	Protect data from unauthorized disclosure when correctly applied
Integrity verification	Detect or establish evidence of modification
Server-side authorization	Decide whether an operation is permitted

Obfuscation changes how understandable the implementation is; it does not inherently make the application's behavior secret.

Encryption also requires care. If an application contains the decryption key and must decrypt a payload locally, a sufficiently privileged analyst may be able to inspect the key or the plaintext at runtime. Encrypting code or resources can increase complexity, but it is not a substitute for a sound trust model.

Additional technical context: OWASP's mobile security guidance treats obfuscation and anti-tampering as resilience measures, not replacements for core security controls. See OWASP MASVS: Resilience Against Reverse Engineering and Tampering.

4. Dynamic Analysis: Observing What Happens at Runtime

Static analysis answers questions about code structure. Dynamic analysis answers questions about actual behavior during execution.

The video explains that analysts can observe which functions execute when a user performs an action, even when the corresponding methods have meaningless names.

This is an important distinction: obscuring a method's name does not obscure the fact that it executes or the effects it produces.

4.1 What runtime analysis can reveal

In an authorized test environment, runtime analysis can help establish:

Which methods execute after a particular interaction.
Which values are passed between components.
Whether a security check actually affects a sensitive operation.
How network requests and responses influence application state.
Whether a supposedly protected value appears in memory.
Whether the application behaves differently on a modified or instrumented device.

The exact observations depend on the runtime, device privileges, available instrumentation, and the application's defenses.

4.2 Ghidra, IDA Pro, and runtime instrumentation

The video mentions Ghidra and IDA Pro as professional tools for analyzing applications.

The terminology needs some precision:

Static disassemblers and decompilers, including Ghidra and IDA, help analysts inspect machine code and reconstruct program structure.
Debuggers help inspect execution state, breakpoints, registers, and memory.
Dynamic instrumentation tools can observe or instrument running applications when the environment and protections permit it.

These capabilities overlap in some toolchains, but they are not interchangeable. A static disassembler does not, by itself, provide a complete live view of every function executing on an Android device.

4.3 Why runtime observation defeats some obfuscation strategies

Imagine a method named a() that returns an integer. Its name reveals almost nothing.

But suppose repeated observations establish that:

The method executes when an account screen opens.
Its result changes when the account's entitlement changes.
Its output influences a local interface decision.

The analyst has learned something about the method through behavior rather than its identifier.

This illustrates a broader principle from software security: program behavior can leak semantic information that names and source-code structure conceal.

It does not imply that every relevant function can be identified easily. Large applications, native code, asynchronous execution, reflection, and runtime protections can make analysis substantially harder.

5. Server-Side Validation: Moving Trust Away from the Device

The video next discusses a more meaningful architectural defense: moving sensitive logic and authorization to a backend.

Consider a streaming service. The mobile client sends a request to play protected content. The backend verifies the account's entitlement and determines whether the requested operation is allowed.

A simplified request might contain:

{
  "content_id": "example-content-123",
  "session_id": "authenticated-session"
}

This is an illustrative payload, not a real service API.

The server should not accept a client's assertion that the account is premium merely because the client says so.

Instead, it should establish the user's identity, retrieve authoritative entitlement data, evaluate the requested operation, and enforce the result.

5.1 The difference between authentication and authorization

These terms are related but distinct:

Authentication: Who is making the request?
Authorization: Is that identity permitted to perform the requested operation?
Integrity verification: Is there evidence that the client or execution environment satisfies expected integrity conditions?

A valid login does not automatically establish a paid entitlement. A valid subscription does not necessarily authorize every resource. A genuine application binary does not guarantee that the account has permission to access a particular feature.

A robust design evaluates the relevant conditions separately.

5.2 Backend authority and entitlement checks

For a subscription-based application, a backend can follow this pattern:

receive request
    ↓
validate session and identity
    ↓
load authoritative entitlement
    ↓
check resource and operation permissions
    ↓
apply rate limits and abuse rules
    ↓
allow or reject the operation

The client can cache information for responsiveness, but the backend must revalidate sensitive operations where appropriate.

This is especially important for purchases, virtual currency, competitive game results, protected content, account changes, and access to private data.

5.3 What server-side validation does not solve

Moving logic to the backend does not make all attacks disappear.

For example, a client may still:

Display an interface that suggests an unauthorized feature is available.
Extract information already delivered to the device.
Automate legitimate endpoints in abusive ways.
Exploit broken authorization rules on the server.
Misuse an account with otherwise valid access.

Server-side enforcement protects operations and data that remain under the server's control. It cannot retroactively make information secret after that information has been delivered to an untrusted client.

This is why server-side authorization must be combined with data minimization, appropriate session management, abuse prevention, and secure API design.

6. Network Interception and Response Tampering

The video describes an attacker intercepting a server response, changing an entitlement-related value, and returning the modified response to the client.

This is a useful conceptual illustration of why clients should not be trusted blindly. However, it simplifies the network-security problem.

6.1 HTTPS changes the situation

With correctly implemented HTTPS, traffic is encrypted and authenticated in transit. A passive observer on the network cannot simply read and modify the response without detection.

To inspect or alter HTTPS traffic, an analyst generally needs an additional capability or weakness, such as:

Control of the client or its runtime.
A test environment configured to trust an interception proxy.
A certificate-validation weakness.
A compromised endpoint or trust configuration.
Another application or protocol flaw that exposes the relevant data.

The specific possibilities depend on the implementation and the analyst's level of access.

6.2 Certificate validation and pinning

Android supports Network Security Configuration, which lets developers configure trust anchors and other network-security settings. Certificate pinning can further restrict which certificates or public keys an application accepts.

These controls can make certain interception scenarios more difficult. They must be implemented carefully, with backup pins and a tested certificate-rotation strategy where pinning is used.

See the Android Network Security Configuration documentation.

However, transport security and authorization address different questions:

TLS helps protect the authenticity and confidentiality of communication.
Certificate validation helps establish whether the peer's certificate chain is trusted.
Backend authorization determines whether an operation is permitted.

Even a perfectly encrypted connection does not fix an API that grants access based on a client-controlled entitlement field.

6.3 A safer mental model

flowchart TD
    A["Android client"] --> B["TLS-protected request"]
    B --> C["Backend"]
    C --> D["Authenticate identity"]
    D --> E["Authorize operation"]
    E --> F["Return permitted data"]
    F --> G["Client displays result"]

The backend's authorization decision must remain authoritative. The client should not be able to turn an unauthorized request into an authorized one merely by changing a locally interpreted response flag.

7. Google Play Integrity: What It Does and Does Not Do

The video describes Google Play integrity protection as a mechanism that checks whether the installed application matches its expected compiled state. It then suggests that removing the relevant library can make a modified application work again.

This description captures the general purpose of integrity protection, but it is not an accurate account of the complete Play Integrity architecture.

7.1 What the Play Integrity API actually provides

Google Play Integrity helps a developer assess whether requests or user actions are associated with a recognized application binary, an expected installation context, and a device environment that meets configured integrity criteria.

Depending on the API response and enabled capabilities, relevant signals can include:

App integrity: Whether the application binary is recognized as expected.
Account details: Information relevant to the app's installation or acquisition context.
Device integrity: Signals about the device environment.
Additional risk signals: Optional verdicts that can help identify suspicious access, known malware, or anomalous activity.

The exact verdicts depend on the API, configuration, and environment.

Official documentation: Overview of the Play Integrity API.

7.2 The backend is part of the design

A typical integrity-protected operation follows this sequence:

sequenceDiagram
    participant U as User
    participant A as Android App
    participant P as Google Play Integrity
    participant B as Application Backend

    U->>A: Request sensitive action
    A->>P: Request integrity token
    P-->>A: Return integrity token
    A->>B: Send action and token
    B->>P: Verify/decode token
    P-->>B: Return integrity verdict
    B->>B: Check verdict and authorize action
    B-->>A: Allow or reject

This is a simplified conceptual sequence. The precise verification flow differs by API request type and integration details.

The crucial architectural detail is that the application backend evaluates the integrity evidence. The token should not be treated as an arbitrary client-provided string or a permanent guarantee that every future request is safe.

For standard requests, developers should bind relevant request data to the integrity request and verify that binding on the backend. Otherwise, a valid verdict may not provide the intended assurance about the particular operation being authorized.

Google's guidance also recommends requesting verdicts close to the protected action and using a tiered enforcement strategy rather than treating every non-ideal signal identically.

7.3 Why a client-side integrity check is not enough

An integrity-related SDK running in the client is one component of a larger verification flow.

If the backend grants access solely because the client claims that an integrity check succeeded, the architecture has placed too much trust in the component it is trying to assess.

Instead, the backend should validate the integrity token using the documented verification process and combine the resulting verdict with authentication, authorization, and abuse controls.

This distinction matters because a local check, an integrity token, and a backend authorization decision are three different things.

7.4 Can integrity checks be bypassed?

The video suggests that removing or stubbing an integrity library can defeat the protection.

That may describe some poorly designed client-side checks or a simplified demonstration. It should not be generalized to the Play Integrity API as a whole.

Removing an SDK from a modified APK does not, by itself, produce a valid Google-issued integrity verdict or cause a properly configured backend to accept the modified application.

An application may still have weaknesses if it relies on local checks, mishandles tokens, accepts replayed or incorrectly bound requests, or fails to enforce the backend decision. The outcome depends on the actual implementation.

Play Integrity is a risk signal and integrity mechanism, not a magic shield. Its security value depends on correct server-side verification and enforcement.

8. Why the Cycle Continues: A Layered Security Model

The video repeatedly returns to the same pattern: developers introduce a defense, and analysts find new ways to study the application or its surrounding system.

The deeper lesson is not that every defense is useless. It is that each defense addresses a different part of the problem.

Defense	What it helps with	What it cannot guarantee
R8 obfuscation	Makes code structure harder to understand	That code cannot be analyzed
Resource protection	Reduces exposure of selected resources	That runtime plaintext remains secret
Runtime checks	Detects some forms of instrumentation or tampering	That every hostile environment is detected
TLS and certificate validation	Protects communications against many network attacks	That the client itself is trustworthy
Play Integrity	Supplies evidence about app and device integrity	That every request is authorized or every attack is prevented
Backend authorization	Enforces permissions for server-controlled operations	That already-delivered information stays secret
Abuse detection and rate limiting	Helps identify and constrain suspicious behavior	That every abusive action is detected immediately

OWASP's mobile security guidance emphasizes defense in depth and explicitly warns against using anti-tampering or obfuscation as a substitute for sound security architecture.

Reference: OWASP MASVS — Resilience.

8.1 The economics of reverse engineering

Security controls also change the cost of an attack.

An analyst may spend minutes inspecting an uncomplicated application, hours understanding an obfuscated codebase, or substantially longer investigating a complex application with native components, runtime checks, and backend dependencies.

These are illustrative possibilities, not predictable timelines.

The defender's goal is to make unauthorized modification more expensive, limit the value of any successful modification, and detect or constrain abuse when prevention fails.

A successful defense therefore need not make reverse engineering impossible. It can ensure that reverse engineering alone does not grant access to protected server-side capabilities.

9. A Defensive Architecture for Android Developers

For developers building subscription-based applications, games, or other Android products, a layered design is more reliable than relying on a single anti-modification technique.

Layer 1: Harden the application build

Enable appropriate R8 optimization and obfuscation for release builds.
Avoid shipping debug artifacts, unnecessary secrets, or internal endpoints.
Review resources and bundled assets for sensitive information.
Verify the final artifact rather than assuming the build configuration produced the intended result.

Layer 2: Keep authoritative state on the backend

Store subscription entitlements and virtual currency balances on the server.
Validate purchase information using the appropriate trusted purchase-verification flow.
Perform sensitive state transitions transactionally.
Do not accept client-reported prices, balances, or entitlement flags as authoritative.

Layer 3: Secure network communication

Use HTTPS with correct certificate validation.
Configure Android network security deliberately.
Consider certificate pinning when the threat model justifies its operational costs.
Never ship private server credentials or long-lived privileged secrets inside the APK.

Layer 4: Integrate integrity signals

Use Play Integrity where appropriate for the distribution model and risk profile.
Verify integrity tokens on the backend according to Google's documented flow.
Bind the verdict to the relevant request data.
Use verdicts in proportion to the sensitivity of the action being protected.

Layer 5: Detect and constrain abuse

Apply per-account and per-action rate limits.
Detect anomalous gameplay, transaction patterns, and request volumes.
Log security-relevant decisions without unnecessarily collecting sensitive user data.
Revoke sessions or restrict actions when evidence justifies intervention.
Provide recovery paths for legitimate users incorrectly classified as risky.

Layer 6: Test the system, not only the APK

A secure-looking client can still communicate with an insecure API. Security assessments should therefore examine both the Android package and the backend.

For a structured assessment, use the OWASP Mobile Application Security Verification Standard and its companion testing resources.

10. A Safe Reverse-Engineering Lab for Learners

The concepts in the video are best learned using an application you own or are explicitly authorized to test.

A small educational project can demonstrate compilation, decompilation, obfuscation, runtime behavior, and backend authorization without targeting a commercial application or defeating its access controls.

Lab A: Inspect your own APK

Create a minimal Android application with a non-sensitive feature flag.
Build a debug APK and inspect it using Android Studio's APK Analyzer.
Examine the manifest, DEX contents, resources, and package structure.
Compare the readable structure with a release build using R8.
Record which names, resources, and structural details remain visible.

Learning objective: Understand what compilation and obfuscation change—and what they do not.

Lab B: Observe runtime behavior

Add a harmless diagnostic method to your own application.
Log a feature decision and its inputs in a debug-only build.
Set breakpoints and observe the call sequence.
Compare source-level names with the optimized release representation.
Document the limits of what you can infer from a single execution.

Learning objective: Understand the difference between static code inspection and dynamic analysis.

Lab C: Compare client-side and server-side authorization

Build a small application with two feature implementations:

A local demonstration feature controlled by a boolean.
A protected test endpoint that independently checks an authenticated user's entitlement.

In the second implementation, make the backend authoritative. Test that an enabled interface does not grant access when the backend denies the operation.

Learning objective: Demonstrate why changing interface state must not change server-side permissions.

Lab D: Evaluate integrity decisions

In a development environment, document how your application responds to different integrity verdicts and how the backend handles missing, invalid, or mismatched verification data.

Use Google's official Play Integrity testing and integration guidance. Do not treat the absence of a verdict as proof that a user is malicious; design an appropriate fallback or restricted mode for your threat model.

Learning objective: Understand how integrity evidence contributes to a larger authorization decision.

11. Common Misconceptions to Avoid

Misconception 1: Decompiled code is the original source code.

No. Decompiled output is a reconstruction. It may be incomplete or structurally different from the original implementation.

Misconception 2: Obfuscation makes code impossible to understand.

No. Obfuscation increases the effort needed to interpret a program but does not guarantee secrecy.

Misconception 3: HTTPS prevents all response tampering.

HTTPS protects data in transit under its security assumptions. It does not prevent a sufficiently privileged analyst from manipulating a client or eliminate application-level authorization flaws.

Misconception 4: Keeping logic on the server makes everything secure.

Server-side enforcement protects operations controlled by the backend. It does not protect secrets that have already been delivered to the client or fix vulnerabilities in the backend itself.

Misconception 5: Play Integrity is just a library that crashes modified applications.

No. Play Integrity provides integrity verdicts through a documented verification flow. The backend's correct interpretation and enforcement of those verdicts are essential.

Misconception 6: If a mod works, the developer's entire security system has failed.

Not necessarily. A modified interface may appear to unlock a feature without obtaining the protected resource or successfully performing the protected operation. The security impact depends on what the modification actually enables.

12. Conclusion: Design for an Untrusted Client

Manguman's video provides an accessible introduction to a genuine and important area of Android security: the ongoing effort to understand and modify compiled applications.

Its main narrative moves through static analysis, obfuscation, runtime analysis, backend validation, and integrity checks. These techniques are useful concepts for developers and security learners to understand.

The technical nuance is that no individual technique establishes complete security. Obfuscation raises the cost of inspection. TLS protects communication. Integrity verdicts provide evidence about the application and environment. Backend authorization determines whether protected operations should proceed.

These mechanisms become more effective when they reinforce one another.

For Android developers, the most valuable design principle is straightforward:

Assume that the client can be inspected, that local state can be manipulated, and that requests can be replayed or automated unless your architecture prevents it. Then enforce security where the authority and valuable resources actually reside.

That approach does not eliminate reverse engineering. It ensures that understanding an application is not, by itself, enough to defeat its security model.

References and Further Reading

Android Developers — Analyze your build with APK Analyzer
Android Developers — Overview of the Play Integrity API
Android Developers — Make a standard Play Integrity API request
Android Developers — Network Security Configuration
OWASP — MASVS: Resilience Against Reverse Engineering and Tampering
OWASP — Mobile Application Security Verification Standard

Editorial note: The discussion of the Spotify incident and the individual techniques attributed to attackers follows the supplied transcript. Those claims are not independently verified here. The explanations of DEX, Smali, network security, and Play Integrity provide additional technical context based on the references above.

CampusLoop Atlas: I Built an Agent That Knows What Is Actually Happening on Campus

Sh Raj — Thu, 24 Sep 2026 08:38:55 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.

CampusLoop Atlas: I Built an Agent That Knows What Is Actually Happening on Campus

Ask the campus. Get an answer grounded in real, structured campus content.

Most "AI campus assistants" are really just chat UIs sitting on top of a search box.

I wanted to build something harder.

CampusLoop Atlas is an agent that answers questions about clubs, events, people, schedules, eligibility, locations, and opportunities by querying a structured Sanity content system through Sanity Context.

The important part is not that it can answer:

"What clubs exist?"

A keyword search can do that.

The interesting questions are things like:

"I'm a second-year CSE student, I like web development, I can only attend events after 5 PM on Friday, and I want something where beginners are welcome. What should I join, and why?"

That answer requires the agent to connect multiple pieces of structured content.

It has to reason over:

Student profile
     │
     ├──────────────┐
     │              │
     ▼              ▼
interests       availability
     │              │
     └──────┬───────┘
            ▼
          clubs
            │
      ┌─────┼─────┐
      ▼     ▼     ▼
    events people eligibility
      │
      ▼
   locations

That's the part I wanted Sanity to power.

What I Built

CampusLoop Atlas turns a structured campus content graph into a conversational agent.

The content model is intentionally richer than a collection of blog posts.

A typical record looks conceptually like:

Club
├── name
├── slug
├── description
├── categories[]
├── skills[]
├── audience[]
├── beginnerFriendly
├── members[]
├── events[]
└── socials

Event
├── title
├── startAt
├── endAt
├── venue
├── organizer
├── clubs[]
├── eligibility[]
├── skills[]
├── registrationUrl
└── status

Person
├── name
├── role
├── clubs[]
└── areas[]

Venue
├── name
├── building
└── campusArea

The agent can then answer questions that depend on relationships between documents, not just matching words.

Example

User:

"Which web-development opportunities can a first-year student attend this weekend?"

The agent needs to discover:

events occurring this weekend
their organizers
the organizer's associated clubs
the skills/category attached to those events
eligibility requirements
registration state
exact timing and venue

That's precisely the kind of task where structured content becomes useful.

The Problem With Normal Search

Suppose the dataset contains:

Web Development Club
HackQuest
Frontend Workshop
ACM Meetup
React Bootcamp

A search engine can find these words.

But the real question might be:

"Which beginner-friendly event this Saturday is run by a club that actively teaches frontend development, is on campus, and still has registration open?"

The answer is not a document.

It is a join across documents.

          ┌─────────────┐
          │    Events   │
          └──────┬──────┘
                 │
                 │ organizer
                 ▼
          ┌─────────────┐
          │    Clubs    │
          └──────┬──────┘
                 │
        ┌────────┼─────────┐
        ▼        ▼         ▼
     skills   audience   members
        │        │
        └────┬───┘
             ▼
       Candidate events
             │
       ┌─────┴─────┐
       ▼           ▼
   eligibility   schedule
       │           │
       └─────┬─────┘
             ▼
          Answer

Sanity stores the structure. The agent reasons over it.

Why Sanity?

Sanity's Content Lake stores content as structured JSON documents with schemas that I can design around the domain.

For this project, that means I can model the campus as actual entities and relationships rather than forcing everything into flat text.

Sanity Context then exposes that content to an agent through a hosted, read-only MCP server. In GROQ mode, Context provides tools for understanding the schema and querying documents; Knowledge Base mode provides access to pre-built indexed entries. citeturn545668search1turn545668search0

For this challenge I use Knowledge Base + Sanity Context MCP so the agent can retrieve the curated campus knowledge that I selected instead of relying on a generic web search.

The challenge explicitly calls for an agent backed by a Sanity Context MCP endpoint and a Knowledge Base, and says the strongest Path One submissions are ones that only work because the content is structured. citeturn545668view0

That is exactly the constraint I designed around.

How I Used Sanity

1. I modeled the campus as connected content

Instead of:

"ACM organizes HackQuest in the Main Auditorium..."

I store:

{
  "_type": "event",
  "title": "HackQuest",
  "organizer": {
    "_ref": "club-acm"
  },
  "venue": {
    "_ref": "venue-main-auditorium"
  },
  "skills": ["web-development", "ai"],
  "eligibility": ["students"],
  "status": "registration-open"
}

That small difference changes what the agent can infer.

The agent doesn't have to guess whether two pieces of text refer to the same entity.

The relationship is data.

2. I pointed Sanity Context at the content I actually care about

The Knowledge Base contains the campus sources used by the agent:

CampusLoop content
├── Clubs
├── Events
├── People
├── Venues
├── Eligibility rules
├── Categories
└── FAQs / announcements

Knowledge Bases are pre-built indexes over selected material and can combine sources so an agent can retrieve from one indexed knowledge layer. Sanity currently documents Knowledge Bases as a beta feature. citeturn545668search3turn545668search2

For this project, that means the agent sees a curated campus knowledge graph rather than an unstructured pile of pages.

3. I used the Context tools as an agent, not as a hidden search endpoint

Sanity Context's GROQ-mode tools include:

initial_context
schema_explorer
groq_query
array_field_reader

The schema-aware tools matter because the agent first needs to understand what kind of content exists and how it is shaped before it can ask useful questions of the data. citeturn545668search0

In Knowledge Base mode, the agent works with indexed entries instead of directly querying the live dataset. citeturn545668search0turn545668search3

The important workflow is:

User question
      │
      ▼
Agent interprets intent
      │
      ▼
Sanity Context
      │
      ├── discover relevant content
      ├── follow structured relationships
      ├── retrieve source-backed facts
      │
      ▼
Agent synthesizes answer
      │
      ▼
Answer + evidence

A Question That Breaks Keyword Search

Here is the type of question Atlas is designed for:

"I am a first-year student interested in AI and frontend development. I don't want competitive coding events, I can only attend after 6 PM, and I want something that doesn't require prior club membership. What can I attend this week?"

Notice how many constraints are hidden inside one sentence.

The agent needs to combine:

Constraint	Structured field
First-year	`eligibility`
AI	`skills[]`
Frontend	`skills[]` / `categories[]`
Avoid competitive coding	`categories[]`
After 6 PM	`startAt`
No membership required	`eligibility[]`
This week	event date

A plain text search engine may retrieve relevant pages.

But it isn't naturally performing this structured filtering and relationship traversal.

That's why the content model is part of the product.

The Agent's Answer

Instead of dumping search results, Atlas is designed to return something closer to:

I found 3 opportunities that match your constraints.

1. Frontend Workshop
   Friday • 6:30 PM
   Web Development Club
   Beginner-friendly
   No club membership required
   Main Lecture Hall

   Why it matches:
   ✓ frontend
   ✓ after 6 PM
   ✓ beginner-friendly
   ✓ open to students

2. AI Build Night
   Saturday • 7:00 PM
   AI Club
   ...

3. Open Source Sprint
   Sunday • 6:30 PM
   Developer Community
   ...

I excluded 4 other events because they:
• started before 6 PM
• required prior membership
• were categorized as competitive programming

The final response is generated by the agent.

But the facts come from structured content.

🔍 The "Why?" Button

One feature I care about a lot is showing why the agent reached its conclusion.

For every recommendation, the UI can expose:

Matched because:

✓ skill = frontend
✓ audience = first-year
✓ beginnerFriendly = true
✓ startAt > 18:00
✓ registrationStatus = open

Source:
→ Frontend Workshop
→ Web Development Club
→ Main Lecture Hall

This makes the result inspectable.

Sanity Context is read-only and the connection is scoped by its configured sources and filters, which is useful for keeping the agent inside the content boundary I explicitly gave it. citeturn545668search10

🧠 Handling Conflicting Information

Another reason I chose Sanity Context instead of simply scraping pages at runtime is provenance.

The challenge specifically highlights that Knowledge Base entries remain linked to their source and that contradictory source claims can be surfaced together. citeturn545668view0

That matters on a campus.

Imagine:

Club page:
"Workshop starts at 5 PM"

Official event page:
"Workshop starts at 6 PM"

A generic chatbot might confidently choose one.

Atlas can treat those as conflicting source-backed claims and surface the discrepancy for resolution instead of silently inventing certainty.

That is a much safer interaction model for real-world content.

🛠️ Architecture

The production architecture is intentionally small:

                   ┌─────────────────────┐
                   │   CampusLoop Atlas  │
                   │      Web App        │
                   └──────────┬──────────┘
                              │
                              ▼
                   ┌─────────────────────┐
                   │      AI Agent       │
                   │                     │
                   │ intent + planning   │
                   │ answer synthesis    │
                   └──────────┬──────────┘
                              │
                              │ MCP
                              ▼
                   ┌─────────────────────┐
                   │   Sanity Context    │
                   │                     │
                   │ Knowledge Base      │
                   └──────────┬──────────┘
                              │
                       indexed content
                              │
                              ▼
                   ┌─────────────────────┐
                   │   Sanity Content    │
                   │       Lake          │
                   └─────────────────────┘

The frontend is only the interface.

The interesting system is:

structured content
       +
retrieval
       +
agent reasoning
       =
grounded campus answers

💻 The Data Model

The schema is deliberately relationship-heavy.

A simplified version:

defineType({
  name: "event",
  type: "document",
  fields: [
    defineField({
      name: "title",
      type: "string",
      validation: Rule => Rule.required()
    }),

    defineField({
      name: "startAt",
      type: "datetime",
      validation: Rule => Rule.required()
    }),

    defineField({
      name: "organizer",
      type: "reference",
      to: [{ type: "club" }]
    }),

    defineField({
      name: "venue",
      type: "reference",
      to: [{ type: "venue" }]
    }),

    defineField({
      name: "skills",
      type: "array",
      of: [{ type: "string" }]
    }),

    defineField({
      name: "eligibility",
      type: "array",
      of: [{ type: "string" }]
    }),

    defineField({
      name: "beginnerFriendly",
      type: "boolean"
    })
  ]
})

The exact production schema is available in the repository linked below.

🔗 Why References Matter

Consider these two representations.

Flat content

HackQuest is hosted by ACM in Main Auditorium.
ACM is a technical club.
Main Auditorium is on Central Campus.

Structured content

HackQuest
 ├── organizer → ACM
 └── venue → Main Auditorium

ACM
 └── category → Technical

Main Auditorium
 └── campusArea → Central Campus

Now a question like:

"Which technical events are happening in Central Campus?"

can be answered from relationships rather than semantic coincidence.

That is the difference between searching text and querying a content model.

🤖 Agent Loop

The agent roughly follows this pattern:

1. Understand the question
2. Identify constraints
3. Retrieve relevant entities
4. Traverse relationships
5. Filter candidates
6. Resolve conflicts
7. Generate an answer
8. Cite the supporting content

Pseudo-code:

def answer(question):
    intent = parse_question(question)

    candidates = sanity_context.retrieve(
        entities=intent.entities,
        constraints=intent.constraints
    )

    filtered = apply_constraints(
        candidates,
        intent.constraints
    )

    conflicts = detect_conflicts(filtered)

    return synthesize(
        question=question,
        results=filtered,
        conflicts=conflicts,
        sources=get_sources(filtered)
    )

The key point is that Sanity is the source of truth for the campus knowledge used by the agent.

🚦 Guardrails

I don't want a campus assistant that confidently fabricates event information.

So Atlas follows a few rules:

NO SOURCE
   ↓
Do not present the claim as campus fact.

CONFLICTING SOURCES
   ↓
Surface the conflict.

MISSING CONSTRAINT
   ↓
Ask a follow-up question.

STALE / PAST EVENT
   ↓
Label it clearly instead of presenting it as upcoming.

NO MATCH
   ↓
Say no matching opportunity was found.

This is especially important because Sanity Context itself is a read-only content interface; it exposes the content configured for the agent rather than letting the agent silently mutate the dataset. citeturn545668search1turn545668search10

🧪 How I Tested It

I created test questions in increasing levels of difficulty.

Level 1 — Direct lookup

"What is the next HackQuest event?"

Level 2 — Filtering

"Which events are happening after 6 PM?"

Level 3 — Multi-constraint

"Which AI events after 6 PM are beginner-friendly?"

Level 4 — Relationship reasoning

"Which beginner-friendly events are hosted by clubs
that teach web development?"

Level 5 — Real-world ambiguity

"Which event should I attend if I'm a first-year student,
want to learn frontend development, cannot attend before 6 PM,
and don't want competitive programming?"

Level 6 — Conflict handling

"Why does one source say 5 PM and another say 6 PM?"

The higher-level tests are the important ones.

A benchmark that only measures Level 1 is basically measuring search.

📈 What I Measure

I evaluate more than whether an answer "sounds right."

Metric	What I check
Grounding	Are important claims supported by Sanity content?
Constraint accuracy	Did the answer respect every user constraint?
Relationship accuracy	Did it follow the right references?
Freshness	Did it distinguish upcoming from past content?
Conflict awareness	Did it surface contradictions?
Abstention	Did it avoid inventing an answer when data was missing?
Source coverage	Can I trace recommendations back to content?

A useful agent should be correct because it found the right content, not merely because the language model produced a plausible sentence.

🔥 The coolest use case

The feature I ultimately want CampusLoop Atlas to become is a personal campus navigator.

Imagine opening the app at the beginning of a semester and asking:

"I have 6 hours free this week. I want to meet developers, learn React, attend one AI event, avoid anything before 5 PM, and I'd prefer events that are free."

Atlas could construct a schedule from structured campus content.

That is not a search result.

It is a plan built from a content graph.

And that is exactly why Sanity is useful here.

🎬 Demo

Live demo: [ADD YOUR DEPLOYED AGENT URL]

Recommended demo flow:

1. Ask a simple question.

2. Ask a multi-constraint question.

3. Open the "Why this answer?" evidence.

4. Ask a question whose answer depends on two or more linked documents.

5. Demonstrate a conflict or missing-data case.

6. Show the underlying Sanity content that produced the answer.

The sixth step is important.

I don't just want to show that the agent talks.

I want to show where the answer came from.

💻 Code

Repository: [ADD YOUR PUBLIC GITHUB REPOSITORY]

The repository contains:

/apps
  /web
  /agent

/sanity
  /schemas
  /seed

/lib
  /context
  /retrieval
  /evaluation

/README.md

The README includes setup instructions, environment variables, the Sanity schema, and the agent integration.

🧩 How I Used Sanity Context

The key integration is the Sanity Context MCP endpoint.

The agent is configured to access the Sanity knowledge surface rather than being given a giant prompt containing campus data.

Conceptually:

Agent
  │
  │ MCP
  ▼
Sanity Context
  │
  ├── initial context
  ├── schema / content understanding
  ├── retrieval
  └── source-linked knowledge
       │
       ▼
   Sanity Knowledge Base

Sanity documents the Context MCP as a hosted, structured, read-only interface for agents. GROQ mode exposes schema and query tools, while Knowledge Base mode exposes indexed entries. citeturn545668search0turn545668search1

For the challenge, I use the Knowledge Base path because I want the agent to work from a curated campus corpus.

🗂️ Sanity Project Details

Sanity Project ID: [ADD YOUR SANITY PROJECT ID]

Public dataset / project link: [ADD PUBLIC DATASET URL, IF USED]

The Sanity workspace contains the structured content models used by CampusLoop Atlas:

club
event
person
venue
category
announcement

The important part of the model is not the number of document types.

It is the relationships between them.

🧾 Agent Session

Agent Session: [ADD PUBLIC DEV AGENT SESSION URL]

The session should show:

prompt
  ↓
agent planning
  ↓
Sanity Context calls
  ↓
retrieved content
  ↓
reasoning
  ↓
final grounded answer

Agent Sessions on DEV are unlisted by default, so the session must be made public for judges to access it. The challenge also recommends curating the useful portions and checking the transcript for secrets before publishing. citeturn545668view0

🧠 What I Learned

The biggest lesson was surprisingly simple:

Retrieval quality is partly a schema-design problem.

I started from the agent.

I ended up thinking much more about the data.

Questions such as:

"What events should I attend?"

became schema questions:

What is an event?
Who organizes it?
Who can attend?
What skills does it teach?
Where is it?
When does it happen?
What club does it belong to?
What else is related to it?

Once those relationships existed as structured data, the agent had something much stronger than a pile of documents.

It had a model of the campus.

⚔️ Why this is more than RAG

A lot of AI applications can be described as:

chunk text
  ↓
embed
  ↓
vector search
  ↓
LLM

That pattern is powerful.

But it doesn't automatically understand:

event → organizer → club → skill
event → venue → campus area
event → eligibility → student year
event → time → availability

CampusLoop Atlas is intentionally built around structured relationships plus retrieval.

The content model is part of the agent's intelligence.

🌐 What I Want to Build Next

The next version could add:

calendar-aware planning
        +
personal preferences
        +
real-time event state
        +
notifications
        +
agent-generated weekly plans

For example:

"Build me a campus week."

The response could become:

MON
6:00 PM — React Workshop

WED
7:00 PM — AI Build Night

SAT
5:30 PM — Open Source Meetup

Each recommendation would remain connected to its underlying Sanity content.

🏁 Final Takeaway

I didn't build CampusLoop Atlas because campus information needs another chatbot.

I built it because campus information is structured.

Clubs have members.

Events have organizers.

Events have venues.

Venues belong to areas.

Events have dates.

Events have eligibility.

Clubs have skills.

And students have preferences.

Those relationships are exactly what makes the problem interesting.

Sanity gives me a place to model those relationships.

Sanity Context gives the agent a controlled way to access them.

The agent turns those facts into an answer.

STRUCTURED CONTENT
        ↓
   SANITY CONTEXT
        ↓
   AGENT RETRIEVAL
        ↓
RELATIONSHIP REASONING
        ↓
  GROUNDED ANSWER

The goal isn't to make an agent that knows everything.

It's to make an agent that knows where its answers came from.

🔗 Links

Live Demo: https://campusloop.space/
Repository: https://github.com/SH20RAJ/campusloop
Sanity Project ID: sekwib79
Agent Session: https://github.com/SH20RAJ/campusloop/blob/main/sanity/AGENT_SESSION.md
CampusLoop: https://campusloop.space/
Sanity Context Endpoint: https://sekwib79.api.sanity.io/v2024-03-01/context/mcp
Sanity Project ID: sekwib79 (Dataset: production)

📚 References

sanitychallenge #agents #ai #webdev

Jev Is Not Trying to Be Another Chatbot — It Is Trying to Become a Decision Layer for Software

Sh Raj — Thu, 24 Sep 2026 08:37:52 +0000

This is a submission for the Kaggle Benchmarking Challenge.

Jev Is Not Trying to Be Another Chatbot — It Is Trying to Become a Decision Layer for Software

AI has spent the last few years getting dramatically better at generating things.

Code. Emails. Images. Plans. Explanations. Entire applications.

But software does something else thousands—or millions—of times per day:

It makes tiny decisions.

Should this request go to billing or support?

Should this document be reviewed?

Should this agent retry?

Which tool should run next?

Is this input relevant enough to keep?

Should a human take over?

For many of those decisions, we have been using a very expensive tool: a general-purpose language model.

Jev takes the opposite approach.

Instead of asking an AI to write a paragraph that our software has to interpret, Jev is designed to return a structured decision that software can use directly.

That sounds like a small API design choice.

I think it is a much bigger architectural idea.

🧠 The core idea

The easiest way to understand Jev is:

        ┌──────────────────┐
        │      STATE       │
        │                  │
        │ text / JSON      │
        │ application data │
        └────────┬─────────┘
                 │
                 ▼
        ┌──────────────────┐
        │       JEV        │
        │                  │
        │  Choice / Score  │
        │      / Noul      │
        └────────┬─────────┘
                 │
                 ▼
        ┌──────────────────┐
        │ TYPED DECISION   │
        │ + probabilities  │
        │ + confidence     │
        └────────┬─────────┘
                 │
                 ▼
        ┌──────────────────┐
        │   YOUR PROGRAM   │
        │                  │
        │ route / filter   │
        │ rank / branch    │
        │ escalate / act   │
        └──────────────────┘

A normal LLM workflow often looks more like:

State
  ↓
LLM
  ↓
Generated text
  ↓
Parser
  ↓
Validation
  ↓
Retries / error handling
  ↓
Application logic

Jev is designed to remove the generated-text middleman for bounded decisions.

TypeSafe describes Jev as its first System One model: a model class intended for fast, structured decisions inside software rather than free-form text generation.

LLMs generate strings. Jev returns decisions.

That distinction is the entire story.

What is a "System One" model?

The name is inspired by the familiar distinction between fast, intuitive judgment and slower, deliberative reasoning.

But in software, the useful interpretation is simpler:

Use a fast intelligence primitive for the small judgments inside a larger software system.

The model is not supposed to replace your entire application.

It sits inside your application.

For example:

User message
     │
     ▼
┌───────────────┐
│     Jev       │
│ "What kind of │
│  request is   │
│  this?"       │
└───────┬───────┘
        │
   ┌────┴────┐
   ▼         ▼
Billing    Technical
   │         │
   ▼         ▼
Code       Tool

That is fundamentally different from:

"Hey AI, please think through this request and tell me what
my application should probably do next..."

The first interface is a decision API.

The second is a conversation with a language model.

The three primitives

Jev currently exposes three important question types.

Primitive	What it does	Typical use
`Choice`	Picks one option	Routing, classification, tool selection
`Score`	Scores something against a rubric	Quality, urgency, risk, relevance
`Noul`	Estimates whether a statement is true	Verification, gating, yes/no decisions

The interesting part is that these are not three ways of asking a chatbot a question.

They are three typed interfaces for software decisions.

1. `Choice` — "Which one?"

Imagine an incoming support ticket:

"My payment went through twice and I still cannot access my subscription."

Your application might need:

billing
technical
account

With an LLM, you might ask:

Classify this support ticket into one of:
billing, technical, account.

Return JSON.

Then your application has to trust the format, parse it, validate it, and handle whatever weird edge case the model produces.

With Jev, the question itself is structured:

from typesafe_sdk import Choice, TypeSafeClient

client = TypeSafeClient()

response = client.system_one(
    state="My payment went through twice and I still cannot access my subscription.",
    questions={
        "department": Choice(
            instructions="Which team should handle this request?",
            criteria={
                "billing": "Charges, refunds, invoices, payment problems",
                "technical": "Bugs, errors, broken integrations",
                "account": "Login, permissions, account access",
            },
        ),
    },
)

print(response.answers["department"].choice)

The important output is not a paragraph.

It is a value your code can branch on.

if response.answers["department"].choice == "billing":
    route_to_billing()

That is much closer to calling a function than chatting with an AI.

2. `Score` — "How much?"

Some decisions are not categories.

They are measurements.

For example:

How urgent is this support message?

You might define:

0 → Not urgent
1 → Somewhat urgent
2 → Critical

or:

0 → Low quality
1 → Acceptable
2 → Excellent

The important thing is that your code defines the rubric.

That makes the model a judgment component rather than the owner of the final policy.

from typesafe_sdk import Score

quality = Score(
    instructions="How useful is this answer to a developer?",
    criteria=[
        "Incorrect or unusable",
        "Partially useful",
        "Correct and useful",
    ],
)

Now the model estimates where the state falls on your predefined scale.

Your application decides what to do with the result.

3. `Noul` — "Is this true?"

This is the simplest primitive.

You give Jev a statement such as:

"This ticket contains a request for a refund."

and ask:

from typesafe_sdk import Noul

refund_request = Noul(
    instructions="Does this message contain a request for a refund?"
)

The result is a probability-like value from 0 to 1.

That opens up an interesting class of software:

if refund_request.noul > 0.9:
    start_refund_review()

or:

if spam_score > 0.8 and refund_request.noul < 0.1:
    auto_route()

Suddenly, AI becomes part of ordinary application logic.

🤯 Why this is interesting

Here's the mental shift I find most important.

We normally think about AI as a thing that produces content.

Jev suggests thinking about AI as a thing that produces uncertainty-aware decisions.

That is a much smaller interface.

And smaller interfaces are powerful.

Compare:

Generate a response explaining which tool should be called.

with:

Choose:
[search_docs, execute_sql, browse_web, ask_human]

The second one gives the model much less freedom.

But that constraint is the feature.

The application remains in control.

"But can't normal LLMs already return JSON?"

Yes.

And this is where the distinction becomes important.

A modern LLM can be instructed to produce:

{
  "action": "search_docs",
  "confidence": 0.91
}

That is useful.

But the model is fundamentally still a text-generation system whose output has been constrained or structured for a downstream consumer.

Jev is designed around the decision interface from the beginning.

The conceptual difference is:

LLM:

question
   ↓
tokens
   ↓
structured text
   ↓
parser
   ↓
application

versus:

Jev:

state + typed question
          ↓
     typed decision
          ↓
      application

That sounds subtle.

Inside a production system, it can be a very important distinction.

⚡ Why the speed matters

The other reason Jev is interesting is not just its output format.

It is the economics of putting intelligence inside loops.

TypeSafe currently publishes Jev at $0.042 per million input tokens and describes typical end-to-end response times of roughly 70–500 ms for its System One workloads.

That creates an interesting possibility:

What if AI decisions became cheap enough to use like infrastructure?

Imagine an agent processing:

10 documents
×
8 classification checks
×
5 routing decisions

The AI layer quickly becomes a large number of tiny calls.

With a conventional generative model, you are paying for text generation at each stage.

With a decision model, the target workload is much narrower.

🏗️ The architecture I find most interesting

I don't think Jev should replace LLMs.

I think it makes more sense as a second layer.

Something like this:

                 ┌──────────────────────┐
                 │     APPLICATION      │
                 └──────────┬───────────┘
                            │
                            ▼
                 ┌──────────────────────┐
                 │         JEV          │
                 │                      │
                 │ classify             │
                 │ score                │
                 │ verify               │
                 │ route                │
                 │ gate                 │
                 └───────┬───────┬──────┘
                         │       │
                  confident      uncertain
                         │       │
                         ▼       ▼
                    execute     ┌───────────┐
                                │ LLM /     │
                                │ human     │
                                └───────────┘

This is where the idea gets really powerful.

Cheap decisions first.

Expensive reasoning only when necessary.

🔀 A hybrid AI agent

Suppose an autonomous coding agent receives an issue.

It could work like this:

Issue arrives
     │
     ▼
Jev: Is this actionable?
     │
 ┌───┴────┐
 │        │
No       Yes
 │        │
 ▼        ▼
Ask     Jev: What type?
          │
      ┌───┼─────────┐
      ▼   ▼         ▼
     bug feature  question
      │     │         │
      └─────┴─────────┘
                │
                ▼
        Use appropriate tool
                │
                ▼
        LLM for deep work
                │
                ▼
            Jev: verify
                │
          ┌─────┴─────┐
          ▼           ▼
        pass        uncertain
          │           │
          ▼           ▼
        ship       human review

Notice what happened.

The LLM did not disappear.

It became one component instead of the entire control plane.

🧪 A real benchmark question

This is the part I wanted to explore for the Kaggle Benchmarking Challenge.

Instead of asking:

"Which model writes the best answer?"

I want to ask:

"Which model makes the best decision when the correct action is not always to act?"

That produces a very different benchmark.

For example, give every model the same software scenario:

A pull request changes authentication middleware.

The tests pass.

The PR description says the change is required for a new API.

However, the repository contains an older mobile client
that still uses the previous authentication flow.

The possible decisions could be:

Decision	Meaning
`SHIP`	Safe to merge
`CHANGE`	Modify before merging
`ASK`	More information is required
`STOP`	Known unacceptable risk

Now we can test something that matters in real automation:

Can the model distinguish "I can answer this" from "I should act on this"?

That's a much more interesting failure mode than whether an LLM can produce valid JSON.

📊 What I would measure

A useful benchmark should not collapse everything into one accuracy number.

I would measure at least:

Metric	Question
Decision accuracy	Was the selected action correct?
Calibration	Does confidence track correctness?
Abstention quality	Does the model ask when it should?
False-action rate	How often does it act when it should not?
False-stop rate	How often does it block something safe?
Latency	How quickly can the decision be made?
Cost	How much does each decision cost?
Consistency	Does rephrasing change the result unnecessarily?

That creates a much more useful picture of an AI system.

🔬 There is already evidence worth looking at

Independent public benchmark work is already starting to test Jev in this direction.

For example, a published JevBench run evaluated 242 typed decisions per system. In that run, Jev 1.13.0 reported:

Metric	Jev 1.13.0
Accuracy	96.3%
Cost / 1K decisions	$0.027
p50 latency	0.65 s
p95 latency	0.72 s
ECE	0.027
Valid answers	100%
Exact-sum answers	100%

These are measurements from the benchmark authors' published run—not numbers I independently reproduced.

The interesting part is not "Jev won."

The interesting part is that the benchmark is measuring different axes at the same time.

For decision systems, accuracy without calibration is incomplete.

Speed without correctness is useless.

Cheap but unreliable automation can be expensive in disguise.

🧩 The hidden superpower: probabilities

This may be the most important architectural idea.

Suppose your system needs to choose between:

A = 0.51
B = 0.49

A naive application sees:

A probability-aware application sees:

A, but barely.

That is a huge difference.

Your code can define:

if confidence >= 0.90:
    automate()
else:
    escalate()

Or:

if confidence >= 0.95:
    action = "automatic"
elif confidence >= 0.70:
    action = "review_queue"
else:
    action = "human"

The model produces the uncertainty.

The application owns the policy.

That separation is healthy software architecture.

🧠 And this changes how prompts should be written

Traditional prompting often looks like:

Analyze this problem deeply and provide the best answer.

A System One-style question should look more like:

Choose the deployment state.

Options:
- safe
- needs_review
- unsafe

Or:

Score the relevance of this document from 0 to 3.

Or:

Does this message contain a security incident?

The question is:

small

atomic

specific

machine-actionable

TypeSafe's documentation explicitly recommends decomposing complex judgments into smaller questions and combining those results in code.

That is a very software-engineering-heavy way of using AI.

🔥 This is where Jev gets weirdly interesting

Imagine processing one document.

Instead of asking one giant prompt:

Analyze this document and give me a complete structured report.

you ask:

Is it relevant?
↓
How urgent is it?
↓
Which department owns it?
↓
Does it contain sensitive information?
↓
Does it require human review?

Those are separate questions.

And they can be combined into an ordinary program:

if sensitive and urgency >= 2:
    escalate()

elif relevance < 0.2:
    discard()

elif department == "billing":
    route("billing")

This is almost like adding a fuzzy intelligence layer to if statements.

🧱 The big limitation

There is an important catch.

Jev is not a replacement for a generative model.

It is not designed to:

write an article
implement a feature
generate a long explanation
produce arbitrary source code
replace a reasoning-heavy agent

That's not a bug.

It is the boundary of the product.

A useful architecture therefore looks like:

Code
 │
 ├── deterministic rules
 │
 ├── Jev
 │    ├── classify
 │    ├── score
 │    ├── verify
 │    └── route
 │
 └── LLM
      ├── reason
      ├── generate
      ├── code
      └── explain

Use each tool for what it is good at.

⚠️ "Zero hallucinations" needs a careful interpretation

TypeSafe talks about Jev being unable to hallucinate in the traditional text-generation sense.

That's understandable because Jev does not generate arbitrary prose.

But this should not be interpreted as:

"Jev cannot be wrong."

Those are different things.

A model can return:

{
  "choice": "billing",
  "confidence": 0.98
}

and still be incorrect.

Type-safe output guarantees the shape of the answer.

It does not magically guarantee the truth of the decision.

That distinction matters enormously when putting AI inside production systems.

🧪 My benchmark idea: "Should the Agent Act?"

For the Kaggle challenge, I would turn this into a benchmark around actionability under uncertainty.

Each task would contain:

State — the information currently available to the agent.
Decision — the action the system could take.
Hidden risk — a detail that makes some actions unsafe.
Ground truth — what a careful engineer should do.
Confidence — how strongly the model believes the decision.
Counterfactual — a minimally changed version of the same scenario.

The benchmark could deliberately contain tasks like:

Case A
Everything is clear.
→ ACT

Case B
The requirement is ambiguous.
→ ASK

Case C
The change violates a constraint.
→ STOP

Case D
The implementation is almost correct.
→ CHANGE

Then flip one sentence:

- The old client has already been migrated.
+ The old client is still deployed.

and see whether the model updates its decision.

That gives us something closer to decision robustness.

🧪 The counterfactual test

This could become my favorite metric.

Take:

Scenario A

and create:

Scenario B = Scenario A + one important fact

Then measure:

Did the model change its decision?

Example:

A:
The database migration has been tested on staging.

B:
The database migration has NOT been tested on staging.

A good decision system should respond differently.

If the model confidently returns the same action in both cases, the failure is extremely informative.

🛠️ Building a Jev benchmark on Kaggle

The benchmark itself can stay simple.

Conceptually:

for scenario in dataset:
    result = run_model(
        state=scenario["state"],
        questions=scenario["questions"],
    )

    evaluate(
        predicted=result,
        expected=scenario["expected"],
    )

Then calculate:

accuracy
calibration
false-action rate
abstention rate
latency
cost
counterfactual consistency

The leaderboard becomes more than:

Model A: 91%
Model B: 89%

Instead:

                    Accuracy   Calibration   Cost   Latency
Model A              91.0%       0.07        ...
Model B              89.0%       0.04        ...
Model C              90.4%       0.03        ...

Now engineers can actually decide which model fits a workload.

💻 A tiny Jev API example

The official quick-start API is deliberately simple:

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "A user reported that their payment succeeded twice.",
    "model": "jev-latest",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this?",
        "criteria": {
          "billing": "Payment, invoice, refund, or charge issue",
          "technical": "Bug or integration problem",
          "account": "Login or account access issue"
        }
      },
      "needs_review": {
        "type": "noul",
        "instructions": "Does this request require manual review?"
      }
    }
  }'

The response contains typed answers rather than a generated essay.

That means your application can immediately do something like:

department = result["department"]["choice"]
needs_review = result["needs_review"]["noul"]

if needs_review > 0.8:
    send_to_human_review()
else:
    route_to(department)

That's a very different abstraction from a chatbot.

🚀 Where I think this could matter

The most interesting workloads are the ones where your application repeatedly asks tiny questions.

🤖 AI agents

Should I call this tool?
Should I retry?
Should I ask the user?
Which tool should I call?
Is the task complete?

📬 Email

Is this urgent?
Is this a sales lead?
Is this an invoice?
Does it require a reply?

🧑‍💻 Developer tooling

Is this PR risky?
Which reviewer should receive it?
Does this issue need reproduction?
Is this error related to the current deployment?

🛡️ Safety & guardrails

Does the input violate a policy?
Does an output require review?
Is the request suspicious?
Should the next step be blocked?

🔎 Retrieval systems

Is this document relevant?
Which documents deserve deeper analysis?
Which result should be escalated to an expensive reasoning model?

⚡ Real-time applications

When a decision has to happen hundreds or thousands of times, latency and cost stop being minor implementation details.

They become product features.

The bigger idea

The most interesting part of Jev isn't that it is "another AI model."

It is that it challenges the assumption that every AI task should look like chat.

Maybe the future stack is not:

Everything → LLM

Maybe it becomes:

                 ┌─────────────┐
                 │    CODE     │
                 └──────┬──────┘
                        │
              ┌─────────┴─────────┐
              │                   │
              ▼                   ▼
          ┌───────┐          ┌────────┐
          │  Jev  │          │  LLM   │
          │ decide│          │ create │
          └───┬───┘          └───┬────┘
              │                  │
              └────────┬─────────┘
                       ▼
                    SYSTEM

Code controls the system.

Jev makes small probabilistic judgments.

LLMs handle open-ended generation and reasoning.

That separation feels much more like software engineering than "put everything in a prompt."

🏁 Final takeaway

Jev is interesting because it asks a surprisingly simple question:

What if AI didn't always need to talk?

For many software systems, the answer to an AI question isn't a paragraph.

It is:

true
false
0.82
priority_high
use_tool_x
ask_human
ship
stop

And once you think about AI that way, a lot of application architecture starts to look different.

The model doesn't need to own the workflow.

It can simply provide judgment at the exact point where the code needs it.

That is the idea behind System One models.

And that is what I want to test.

🔬 Benchmark

Kaggle benchmark: [ADD YOUR PUBLIC KAGGLE BENCHMARK URL HERE]

The benchmark will test actionability, confidence, calibration, counterfactual consistency, latency, and cost across structured decision tasks.

The goal isn't to find a model with the biggest number.

The goal is to understand when an AI can safely become part of the software's decision loop.

📚 Further reading

✅ What I learned

AI does not always need to generate text.
Structured decisions can be a better abstraction for software.
Confidence is useful only when the application knows what to do with uncertainty.
Small AI decisions can be composed into larger deterministic workflows.
Benchmarks should measure when a model should act, not just whether it can answer.
The most useful AI architecture may be LLM + decision model + ordinary code, not LLM everywhere.

One final thought

The next big improvement in AI may not come from making models talk better.

It may come from making them fit inside software better.

Submission for the Kaggle Benchmarking Challenge

Sh Raj — Thu, 24 Sep 2026 08:32:39 +0000

This is a submission for the Kaggle Benchmarking Challenge

Stop or Ship: Can AI Make Safe Software Decisions?

Modern AI models are getting remarkably good at writing code.

But writing code is only one part of software engineering.

A much less discussed question is:

Can an AI correctly decide when it should change code, when it should stop, and when it should ask a human?

That question motivated my benchmark.

Instead of measuring whether a model can produce a syntactically correct solution, I wanted to measure something closer to what happens in a real software repository: incomplete requirements, ambiguous bug reports, risky changes, missing context, and situations where confidently doing the wrong thing is worse than doing nothing.

What I Benchmarked

I built Stop-or-Ship, a benchmark for AI decision-making in realistic software-maintenance scenarios.

Each task gives a model a small software-engineering situation, such as:

a bug report with incomplete information
a proposed code change
a pull request with a subtle regression
a feature request whose requirements are ambiguous
a dependency update with a potential compatibility problem
a change that looks correct locally but violates an existing constraint

The model must choose what should happen next.

The core actions are:

SHIP — the change is sufficiently safe and should proceed.

CHANGE — the proposed implementation should be modified before proceeding.

ASK — there is not enough information to safely make the decision.

STOP — the change introduces a meaningful risk or violates an important constraint.

This is intentionally different from a normal coding benchmark.

A model can write beautiful code and still make a terrible engineering decision.

What I wanted to measure

I focused on four dimensions:

Decision accuracy

Did the model choose the correct action?

Risk sensitivity

Could it identify changes where a seemingly reasonable implementation introduces a hidden problem?

Abstention quality

Did it know when it should ask for more information instead of pretending to know?

Calibration

When the model was uncertain, did its confidence match reality?

That last dimension is especially important for agentic systems. A wrong answer with low confidence can trigger a human review. A wrong answer delivered with extreme confidence can silently become production code.

Models Tested

I selected a mix of general-purpose frontier models and decision-oriented models so that the benchmark would not simply become a comparison between models from the same family.

The initial lineup includes:

Jev — included because it is specifically designed around decision-making rather than long-form text generation.
OpenAI GPT-family model — a strong general-purpose reasoning baseline.
Anthropic Claude-family model — included to test another strong reasoning-oriented approach.
Google Gemini-family model — included as a different model family with strong coding and multimodal capabilities.
[Additional model]
[Additional model]

The exact versions and inference configuration are recorded in the Kaggle benchmark so that the comparison remains reproducible.

I deliberately did not want to answer "which AI writes the best code?"

I wanted to answer a narrower question:

Which models are better at making the decision that should happen before code gets merged or deployed?

Findings

The most interesting part of this benchmark is not a single leaderboard number.

It is the difference between being capable of solving a problem and being capable of deciding whether a problem is safe to act on.

1. Getting the answer right is not enough

[INSERT ACTUAL RESULT]

The benchmark showed that raw decision accuracy does not tell the entire story.

Two models can achieve similar accuracy while behaving very differently:

One may confidently choose an action on almost every task.

Another may recognize uncertainty and ask for additional information.

For software agents, those behaviours have very different consequences.

2. Ambiguity is its own failure mode

[INSERT ACTUAL RESULT]

The "ASK" category produced some of the most interesting examples.

Traditional benchmarks often reward a model for producing an answer.

Real software engineering sometimes rewards the opposite behaviour.

When requirements are contradictory, tests are missing, or repository context is incomplete, not acting can be the correct action.

This benchmark makes that behaviour measurable instead of treating it as a failure to answer.

3. Confidence matters as much as correctness

[INSERT ACTUAL CALIBRATION RESULT]

I also tracked whether confidence was aligned with correctness.

That creates a more useful distinction:

Correct + confident → ideal
Correct + uncertain → potentially acceptable
Wrong + uncertain → human review can still catch it
Wrong + confident → dangerous automation failure

This is one reason I think benchmark design should move beyond a single accuracy number.

4. Decision models vs. language models is an interesting boundary

The benchmark also let me explore a broader question:

Does a model optimized for making decisions behave differently from a model optimized primarily for generating language?

Jev was particularly interesting to include because its design targets calibrated decisions rather than conventional chat completion.

[INSERT ACTUAL COMPARISON FROM KAGGLE RESULTS]

I don't think this benchmark proves that one model architecture is universally better.

Instead, it suggests that model choice should depend on the role an AI is playing.

An AI that writes documentation has different requirements from an AI deciding whether an automated deployment should continue.

What surprised me

The biggest surprise was how often the difficult cases were not about coding at all.

They were about knowing what the model did not know.

A task could contain a perfectly plausible implementation while still being impossible to approve safely because one critical piece of context was missing.

That made "ASK" one of the most important actions in the benchmark.

It also changed how I think about AI evaluation.

A model should not only be rewarded for:

"Can you solve this?"

It should also be evaluated on:

"Should you act on this?"

What I Would Measure Next

The next version of Stop-or-Ship could go beyond static prompts.

I would like to test:

Multi-turn repository context

Give the model the ability to inspect files, tests, commit history, and previous discussions before making its decision.

Tool-use decisions

Measure whether the model requests the right tool before making a high-risk decision.

Cost-aware decisions

Test whether a model can balance correctness against API calls, latency, and engineering cost.

Long-horizon agent behaviour

Instead of one decision, evaluate an entire sequence of actions and measure whether the model eventually recovers from a bad assumption.

Adversarial tasks

Introduce realistic distractions such as misleading comments, plausible-but-wrong tests, stale documentation, and incomplete bug reports.

That would turn Stop-or-Ship from a simple classification benchmark into a more realistic evaluation of autonomous software agents.

My Benchmark

Kaggle Benchmark: [INSERT YOUR KAGGLE BENCHMARK LINK]

The benchmark contains the task definitions, evaluation methodology, model runs, and leaderboard.

All model comparisons should be interpreted within the exact dataset, prompts, and configurations used in the benchmark rather than as a universal ranking of AI systems.

Why I Built This

AI coding benchmarks usually ask whether a model can produce the right code.

I think the next generation of benchmarks should also ask whether the model knows when it should be allowed to act.

That's the difference between an AI that can generate code and an AI that can safely participate in software engineering.

Stop or Ship is my attempt to measure that gap.

kagglechallenge #kagglebenchmarkchallenge #machinelearning #ai #devchallenge

What REALLY Happens When You Type a URL?

Sh Raj — Thu, 17 Sep 2026 08:36:00 +0000

🌐 What REALLY Happens When You Type a URL?

You type: https://example.com
You press: Enter
And somehow: a complete webpage appears in milliseconds.

But what actually happened between those two events?

This article follows the journey of a URL from your keyboard → browser → DNS → network → server → browser → pixels on your screen.

🧠 The Big Picture

At a very high level:

You type a URL
      ↓
Browser parses the URL
      ↓
Check browser cache
      ↓
DNS: "What IP belongs to this domain?"
      ↓
Get IP address
      ↓
Establish connection
      ↓
TLS handshake (HTTPS)
      ↓
HTTP request
      ↓
Server processes request
      ↓
HTTP response
      ↓
Browser receives HTML
      ↓
Download CSS / JavaScript / Images
      ↓
Build DOM + CSSOM
      ↓
Layout + Paint + Composite
      ↓
🎨 Webpage appears

And this can happen incredibly quickly.

1. 🔗 First: What Exactly Is a URL?

A URL (Uniform Resource Locator) tells your browser where a resource is and how to access it.

Consider:

https://www.example.com:443/products?id=42#reviews

Let's break it apart.

Component	Value	Purpose
Scheme	`https`	Protocol
Host	`www.example.com`	Website/domain
Port	`443`	Network port
Path	`/products`	Resource location
Query	`?id=42`	Additional parameters
Fragment	`#reviews`	Position inside page

🧩 URL Anatomy

              https://www.example.com:443/products?id=42#reviews
              └─┬─┘   └────┬──────┘ └┬┘ └────┬────┘ └──┬───┘
             scheme       host       port   query    fragment

💡 Important

The browser does not immediately connect to:

www.example.com

Computers communicate using IP addresses.

So eventually we need something like:

www.example.com
       ↓
93.184.216.34

And that's where DNS enters the story.

2. 🧭 The Browser First Parses the URL

When you press Enter, the browser first determines what you've entered.

For example:

https://example.com/products

The browser understands:

Protocol → HTTPS
Host     → example.com
Path     → /products
Port     → 443

The browser now knows:

“I need to retrieve /products from example.com using HTTPS.”

But it still doesn't know where example.com actually lives.

3. ⚡ Before DNS: Check the Cache

Your browser may already know the answer.

Modern browsers and operating systems maintain several caches.

A simplified hierarchy looks like:

Browser DNS Cache
       ↓
Operating System Cache
       ↓
Hosts File
       ↓
Configured DNS Resolver
       ↓
Root DNS
       ↓
TLD DNS
       ↓
Authoritative DNS

If the IP is already cached and hasn't expired:

example.com
     ↓
Cached IP
     ↓
Skip DNS lookup

This is one reason why repeatedly visiting a website can feel faster.

4. 📖 DNS — The Internet's Phone Book

What is DNS?

DNS = Domain Name System

Humans prefer:

google.com

Computers ultimately need:

142.250.x.x

DNS translates the domain name into an IP address.

          DNS
           │
           ▼
"Where is example.com?"
           │
           ▼
    93.184.216.34

5. 🌳 How DNS Actually Finds the IP

Here's where things get interesting.

Suppose your DNS resolver doesn't already know the answer.

It can walk through the DNS hierarchy.

flowchart TD
    A["Browser"] --> B["DNS Resolver"]
    B --> C["Root DNS Server"]
    C --> D[".com TLD Server"]
    D --> E["Authoritative DNS Server"]
    E --> F["IP Address"]
    F --> B
    B --> A

Step 1 — Ask the Resolver

Your computer asks its configured DNS resolver:

What is the IP address of example.com?

The resolver might be operated by:

your ISP
your organization
a public DNS service
another DNS provider

Step 2 — Root DNS

If the resolver doesn't know, it can ask a root DNS server.

The root doesn't usually know the final IP.

Instead, it says approximately:

“I don't know example.com, but I know who handles .com.”

Root
 ↓
.com TLD

Step 3 — TLD Server

The resolver asks the .com TLD server:

Who is authoritative for example.com?

The TLD server points toward the domain's authoritative DNS servers.

.com
 ↓
Authoritative DNS

Step 4 — Authoritative DNS

Finally:

Authoritative DNS
       ↓
example.com
       ↓
93.184.216.34

The resolver returns the answer to your computer.

6. 🧠 DNS Records

DNS isn't just about IP addresses.

A domain can have different record types.

Record	Purpose
`A`	IPv4 address
`AAAA`	IPv6 address
`CNAME`	Alias to another hostname
`MX`	Mail server
`TXT`	Text / verification / policy data
`NS`	Authoritative nameserver
`CAA`	Certificate authority authorization

For example:

example.com
     │
     ├── A     → IPv4
     ├── AAAA  → IPv6
     ├── MX    → Mail server
     └── TXT   → Verification / policy

7. 🕒 TTL — Why DNS Doesn't Happen Every Time

DNS records have a TTL (Time To Live).

Example:

example.com
A → 93.184.216.34
TTL → 300 seconds

A resolver can cache the answer for that period.

So the next request may become:

Browser
  ↓
Cached DNS result
  ↓
IP

instead of:

Browser
 ↓
Resolver
 ↓
Root
 ↓
TLD
 ↓
Authoritative DNS
 ↓
IP

8. 📍 We Now Have an IP Address

Great!

Suppose DNS returned:

93.184.216.34

Now the browser knows:

“That's the machine I need to communicate with.”

But there's another question:

How do we establish the connection?

For HTTPS, traditionally this involves TCP + TLS.

For HTTP/3, it can instead use QUIC over UDP.

Let's first understand the classic TCP path.

9. 🤝 TCP — Establishing a Connection

TCP provides a reliable connection between two endpoints.

Before sending application data, TCP traditionally performs the famous:

Three-Way Handshake

Client                         Server
  │                               │
  │ -------- SYN ---------------> │
  │                               │
  │ <------- SYN + ACK ---------- │
  │                               │
  │ -------- ACK ---------------> │
  │                               │
  │        Connection ready       │

What do these mean?

SYN

“I want to start a TCP connection.”

SYN-ACK

“I received your request and I'm willing to connect.”

ACK

“Got it.”

Now the TCP connection is established.

10. 🔐 HTTPS Changes the Story

If the URL is:

https://example.com

we need encryption.

That's what TLS provides.

Without HTTPS:

Browser ────────────────> Server
          HTTP

With HTTPS:

Browser ════════════════> Server
          Encrypted

11. 🔐 TLS Handshake

TLS allows the browser and server to establish cryptographic parameters and authenticate the server.

A simplified TLS 1.3 flow:

sequenceDiagram
    participant B as Browser
    participant S as Server

    B->>S: ClientHello
    S->>B: ServerHello
    S->>B: Certificate
    S->>B: Handshake messages
    B->>S: Finished
    S->>B: Finished
    Note over B,S: Encrypted application data

The exact wire exchange is more detailed, but conceptually:

Browser
   │
   │ "Here are the cryptographic options I support."
   ▼
Server
   │
   │ "Let's use these."
   │
   │ "Here's my certificate."
   ▼
Browser
   │
   │ Verify certificate
   ▼
Secure session established

12. 🪪 What's the Certificate For?

When you visit:

https://example.com

your browser wants to know:

“Am I really talking to example.com?”

The server presents a digital certificate.

The certificate contains information such as the domain names it covers and cryptographic identity information.

It is signed through a chain involving trusted Certificate Authorities (CAs).

Simplified:

Certificate
     │
     ▼
Trusted CA
     │
     ▼
Browser's trust store
     │
     ▼
"Can I trust this identity?"

If certificate validation fails, the browser may show a security warning.

13. 🔒 Is the Data Now Encrypted?

After the TLS handshake:

Browser
   ║
   ║ 🔐 Encrypted
   ║
   ▼
Server

Someone observing the network generally cannot simply read the HTTPS request contents.

However, HTTPS does not make you invisible.

Depending on the circumstances, information such as destination IP addresses and some connection metadata can still be observable.

14. 📦 Now Comes HTTP

Finally, we can send the actual web request.

For example:

GET /products HTTP/1.1
Host: example.com
Accept: text/html
Accept-Language: en-US

Conceptually:

GET
 ↓
/products
 ↓
example.com
 ↓
"Please give me this resource."

With HTTP/2 or HTTP/3, the wire representation is different from this textual HTTP/1.1 example, but the application-level idea remains similar.

15. 📬 What Is an HTTP Request?

An HTTP request contains several important pieces.

┌─────────────────────────────┐
│ Method                      │
│ URL / Path                  │
│ Headers                     │
│ Body (optional)             │
└─────────────────────────────┘

Common HTTP methods:

Method	Typical purpose
`GET`	Retrieve data
`POST`	Submit/create data
`PUT`	Replace data
`PATCH`	Partially update data
`DELETE`	Delete data

When loading a webpage, the initial navigation is commonly a GET.

16. 📨 HTTP Request Example

GET / HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Accept-Language: en-US

Think of it as:

“Server, give me the homepage.”

17. 🏢 But Where Did Our Request Actually Go?

This is an important part people often skip.

The IP address may not represent the actual application server.

Modern websites can sit behind infrastructure such as:

                Internet
                   │
                   ▼
              CDN / Edge
                   │
            Load Balancer
                   │
          ┌────────┼────────┐
          ▼        ▼        ▼
       Server A Server B Server C
          │        │        │
          └────────┼────────┘
                   ▼
                Database

Your request may pass through several layers.

18. 🌍 CDN — The Website May Be Closer Than You Think

A CDN (Content Delivery Network) places cached content at locations around the world.

Instead of:

India
  │
  └──────────────> US Server

you might get:

India
  │
  ▼
Nearby CDN Edge
  │
  ▼
Cached Content

This reduces latency for cacheable resources.

19. ⚖️ Load Balancer

Suppose millions of users visit a website.

One server may not be enough.

A load balancer can distribute requests:

flowchart LR
    U["Users"] --> L["Load Balancer"]
    L --> A["Server A"]
    L --> B["Server B"]
    L --> C["Server C"]
    A --> D["Database"]
    B --> D
    C --> D

The browser doesn't necessarily know which backend server handled the request.

20. 🧠 The Server Starts Working

The server receives:

GET /

Now application code may execute.

For example:

Request
   ↓
Web server
   ↓
Application
   ↓
Authentication
   ↓
Business logic
   ↓
Database
   ↓
Response

Imagine an e-commerce website.

Your request:

GET /products/42

could cause the application to:

1. Authenticate session
2. Validate product ID
3. Query database
4. Fetch product information
5. Render HTML
6. Return response

21. 🗄️ Database

The server may need information from a database.

For example:

SELECT *
FROM products
WHERE id = 42;

The database returns something like:

Product
──────────────
id: 42
name: Laptop
price: ₹79,999
stock: 12

The application uses this information to generate the response.

22. 📨 The Server Sends an HTTP Response

The server might respond:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: ...

followed by the HTML document.

Conceptually:

Browser
   │
   │ GET /
   ▼
Server
   │
   │ 200 OK + HTML
   ▼
Browser

23. 🚦 HTTP Status Codes

The response has a status code.

Code	Meaning
`200`	OK
`201`	Created
`301`	Permanent redirect
`302`	Temporary redirect
`304`	Not modified
`400`	Bad request
`401`	Authentication required
`403`	Forbidden
`404`	Not found
`500`	Server error
`502`	Bad gateway
`503`	Service unavailable

So when you see:

the browser did communicate with a server.

The server is essentially saying:

“I don't have the resource you requested.”

24. 📄 The Browser Receives HTML

Now the browser finally has something to work with.

Example:

<!DOCTYPE html>
<html>
<head>
    <title>Hello</title>
</head>

<body>
    <h1>Hello World</h1>
    <p>Welcome!</p>
</body>
</html>

But the page isn't finished yet.

The HTML may reference:

style.css
app.js
logo.png
font.woff2

So the browser starts requesting those resources too.

25. 🕸️ One Page Can Trigger Many Requests

This is something you can demonstrate beautifully in your video.

You type:

example.com

But the browser may request:

GET /
GET /style.css
GET /app.js
GET /logo.svg
GET /font.woff2
GET /api/user
GET /products
...

One URL can therefore trigger dozens or hundreds of network requests on a modern site.

26. 🔄 The Browser Builds the DOM

The browser parses HTML and constructs the:

DOM — Document Object Model

HTML:

<body>
    <h1>Hello</h1>
    <p>World</p>
</body>

Becomes conceptually:

flowchart TD
    A["Document"] --> B["html"]
    B --> C["body"]
    C --> D["h1"]
    C --> E["p"]
    D --> F["Hello"]
    E --> G["World"]

The DOM represents the document as a tree.

27. 🎨 CSSOM

CSS is parsed separately.

Example:

h1 {
    color: blue;
    font-size: 40px;
}

The browser builds a structure called the:

CSSOM — CSS Object Model

Conceptually:

HTML
 ↓
DOM

CSS
 ↓
CSSOM

Then the browser combines the information to determine what should be rendered.

28. 🧱 Render Tree

The browser uses the DOM and CSS information to determine what is rendered.

A simplified pipeline:

HTML
 ↓
DOM
 ↓
      ┌──────────────┐
CSS → │ CSSOM        │
      └──────┬───────┘
             ↓
       Render Tree
             ↓
          Layout
             ↓
           Paint
             ↓
        Composite
             ↓
          🖥️ Screen

29. 📐 Layout

The browser calculates where everything should appear.

For example:

Viewport
┌──────────────────────────────┐
│ Header                       │
├──────────────────────────────┤
│                              │
│       Hello World             │
│                              │
│       [ Button ]              │
│                              │
└──────────────────────────────┘

It calculates:

width
height
position
margins
padding
font metrics
line wrapping

This stage is commonly called layout.

30. 🎨 Paint

Now the browser needs to draw things.

It determines:

Text
Backgrounds
Borders
Shadows
Images
Gradients

and produces drawing operations for the rendering system.

31. 🧩 Composite

Modern browsers can use multiple rendering layers.

Those layers can then be composited together to produce the final frame.

Simplified:

Layer 1 → Header
Layer 2 → Content
Layer 3 → Image
Layer 4 → Animation
          ↓
       Composite
          ↓
       🖥️ Frame

And finally...

🎉 You See The Website

Keyboard
   ↓
URL
   ↓
Browser
   ↓
DNS
   ↓
IP
   ↓
TCP / QUIC
   ↓
TLS
   ↓
HTTP
   ↓
Server
   ↓
Database / APIs
   ↓
HTML / CSS / JS
   ↓
DOM / CSSOM
   ↓
Layout
   ↓
Paint
   ↓
Composite
   ↓
👀 Website

32. 🚀 But What About JavaScript?

We're not done.

Modern websites aren't just HTML.

JavaScript can execute after the page starts loading.

For example:

fetch("/api/user")

might trigger:

Browser
   ↓
HTTP request
   ↓
API server
   ↓
Database
   ↓
JSON response
   ↓
JavaScript
   ↓
Update DOM
   ↓
Browser renders again

This is why modern web applications can feel more like applications than documents.

33. 🍪 What About Cookies?

Cookies can also be involved.

A server may send:

Set-Cookie: session=abc123

The browser stores the cookie according to its rules.

Later requests may include it:

Cookie: session=abc123

This helps websites maintain things such as:

sessions
preferences
authentication state
certain tracking mechanisms

34. 🔑 What About Login?

Suppose you're already logged into a website.

The browser might send authentication information through a cookie or another mechanism.

Simplified:

Login
  ↓
Server authenticates user
  ↓
Session established
  ↓
Browser stores credential/session state
  ↓
Future requests identify the session

So when you visit:

/dashboard

the server can determine which account the request belongs to.

35. 📱 What If You're Using Your Phone?

The overall architecture remains similar.

But the network path may be different.

For example:

Phone
  ↓
Wi-Fi
  ↓
Router
  ↓
ISP
  ↓
Internet
  ↓
Server

Or:

Phone
  ↓
Cellular Network
  ↓
Carrier Network
  ↓
Internet
  ↓
Server

36. 🌐 What Happens to the Packet?

At the network level, your data is broken into packets and transported across networks.

A simplified view:

Your Computer
      ↓
Router
      ↓
ISP
      ↓
Internet Routers
      ↓
Destination Network
      ↓
Server

The actual route can vary.

You can inspect routing information with:

traceroute example.com

On Windows:

tracert example.com

37. 🧪 Try It Yourself

Open DevTools.

Chrome / Edge

Right Click
    ↓
Inspect
    ↓
Network

Then visit a website.

You'll see requests such as:

Document
CSS
JS
Images
Fonts
XHR / Fetch

38. 🔍 Inspect a Request

Click a request in the Network tab.

You'll usually find information such as:

Headers

Request URL
Request Method
Status Code
Remote Address
Content-Type

Response

The data returned by the server.

Timing

You can often see timing phases related to:

Queueing
DNS
Connection
TLS
Request
Waiting
Download

This is one of the best ways to show the concepts in the video instead of only talking about them.

39. 🛠️ Useful Commands

DNS lookup

nslookup example.com

or:

dig example.com

Trace network path

traceroute example.com

Test HTTP headers

curl -I https://example.com

Make an HTTP request

curl https://example.com

Verbose HTTPS connection

curl -v https://example.com

The verbose output can expose useful connection details such as DNS resolution, connection establishment, TLS negotiation, and HTTP exchange.

40. ⚡ Where Does Latency Come From?

The browser isn't necessarily spending all its time downloading data.

A simplified timeline:

DNS
 │
 ├── DNS lookup
 │
 ▼
Connection
 │
 ├── TCP / QUIC
 │
 ▼
TLS
 │
 ├── Secure handshake
 │
 ▼
Request
 │
 ├── HTTP request
 │
 ▼
TTFB
 │
 ├── Server processing
 │
 ▼
Download
 │
 ├── HTML / CSS / JS
 │
 ▼
Rendering
 │
 ├── Parse
 ├── Layout
 ├── Paint
 └── Composite

41. 🏎️ Why Websites Use Caching

Without caching:

Every request
      ↓
Server
      ↓
Generate response

With caching:

Request
   ↓
Cache
   ↓
Found?
 ┌─┴─┐
Yes  No
 ↓    ↓
Return Server

Caching can happen at multiple layers:

Browser Cache
      ↓
CDN Cache
      ↓
Reverse Proxy Cache
      ↓
Application Cache
      ↓
Database

42. 🌍 HTTP/2 and HTTP/3

The web has evolved.

HTTP/1.1

Traditionally represents requests as individual HTTP messages over a TCP connection.

HTTP/2

Introduces features such as:

multiplexed streams
binary framing
header compression

Multiple HTTP streams can share a connection.

             TCP Connection
                  │
       ┌──────────┼──────────┐
       ↓          ↓          ↓
    HTML         CSS        JS
   Stream 1    Stream 2   Stream 3

HTTP/3

HTTP/3 uses:

HTTP/3
  ↓
QUIC
  ↓
UDP
  ↓
IP

QUIC integrates transport and TLS functionality into its protocol design and provides features such as stream multiplexing and connection migration.

So the simplified modern stack can look like:

HTTP/3
  ↓
QUIC
  ↓
UDP
  ↓
IP

instead of:

HTTP/2
  ↓
TLS
  ↓
TCP
  ↓
IP

43. 🧠 The Entire Journey

Let's put everything together.

flowchart TD
    A["⌨️ Type URL"] --> B["Browser parses URL"]
    B --> C["Cache checks"]
    C --> D["DNS resolution"]
    D --> E["IP address"]
    E --> F["TCP or QUIC connection"]
    F --> G["TLS / HTTPS"]
    G --> H["HTTP request"]
    H --> I["CDN / Load Balancer"]
    I --> J["Web Server"]
    J --> K["Application"]
    K --> L["Database / APIs"]
    L --> M["HTTP Response"]
    M --> N["HTML"]
    N --> O["DOM"]
    N --> P["CSS"]
    P --> Q["CSSOM"]
    O --> R["Render Tree"]
    Q --> R
    R --> S["Layout"]
    S --> T["Paint"]
    T --> U["Composite"]
    U --> V["🖥️ Pixels on Screen"]

44. 🎯 The 10-Second Explanation

If someone asks you:

“What happens when I type a URL?”

You can answer:

The browser parses the URL, resolves the domain through DNS, establishes a network connection, negotiates HTTPS when applicable, sends an HTTP request to the server, receives the response, downloads additional resources like CSS and JavaScript, builds the DOM and rendering structures, calculates layout, paints the page, and finally displays the result on your screen.

45. 🧩 The Mental Model

Remember these layers:

                    🌐 WEBPAGE
                       ▲
                       │
                 Rendering
                       ▲
                       │
                HTML / CSS / JS
                       ▲
                       │
                    HTTP
                       ▲
                       │
                 TLS / HTTPS
                       ▲
                       │
               TCP / QUIC / UDP
                       ▲
                       │
                       IP
                       ▲
                       │
                    DNS
                       ▲
                       │
                     URL

Or even simpler:

URL
 ↓
WHERE?
 ↓
DNS

HOW DO I CONNECT?
 ↓
TCP / QUIC

HOW DO I SECURE IT?
 ↓
TLS

WHAT DO I WANT?
 ↓
HTTP

WHERE DOES IT GO?
 ↓
CDN / Server / Application

WHAT DID I GET?
 ↓
HTML / CSS / JS

HOW DO I SHOW IT?
 ↓
DOM → Layout → Paint → Composite

🎨 SCREEN

🧪 Mini Experiment

Open your browser and try this:

1. Open DevTools

F12 / Right Click → Inspect

2. Open Network

Network → Reload

3. Click the first document request

Look for:

Request URL
Status Code
Remote Address
Response Headers
Timing

4. Run DNS

dig example.com

5. Inspect HTTP

curl -I https://example.com

6. Trace the route

traceroute example.com

Now you're no longer just learning the theory.

You're watching the process happen.

🎬 Suggested Video Flow

For teaching this on YouTube, don't present it like a textbook.

Use the browser as the protagonist.

Start with:

https://example.com

Then say:

“I'm going to press Enter. Your browser is about to do way more work than you think.”

Then reveal the journey one step at a time:

YOU
 ↓
URL
 ↓
DNS
 ↓
IP
 ↓
TCP / QUIC
 ↓
TLS
 ↓
HTTP
 ↓
SERVER
 ↓
HTML
 ↓
CSS + JS
 ↓
RENDERING
 ↓
SCREEN

At each stage, show the relevant DevTools panel or a simple animation.

🏁 Final Takeaway

The next time you type:

https://youtube.com

don't think:

“A website opened.”

Think:

I entered a URL
      ↓
The browser interpreted it
      ↓
DNS found the destination
      ↓
A network path was established
      ↓
HTTPS secured the communication
      ↓
HTTP requested the resource
      ↓
Servers processed my request
      ↓
HTML/CSS/JS came back
      ↓
The browser parsed everything
      ↓
Layout was calculated
      ↓
Pixels were painted
      ↓
🎨 I see a webpage

That tiny moment between pressing Enter and seeing a webpage is an entire distributed-system story happening in milliseconds.

📚 Concepts Covered

Networking

DNS · IP · TCP · UDP · QUIC · Routing · Packets

Security

HTTPS · TLS · Certificates · Encryption · Certificate Authorities

Web

HTTP · Headers · Cookies · Status Codes · CDN · Load Balancers · APIs

Backend

Servers · Application Logic · Databases · Caching

Browser

HTML · DOM · CSSOM · Render Tree · Layout · Paint · Composite · JavaScript

💭 One Last Question

The next time a website takes 5 seconds to load, ask:

Where exactly did those 5 seconds go?

Maybe it was DNS.

Maybe the network.

Maybe TLS.

Maybe the server.

Maybe the database.

Maybe JavaScript.

Maybe rendering.

And that's exactly what browser DevTools lets you investigate. 🔍

Vibe Coding Isn't the Problem. Calling It Engineering Is.

Sh Raj — Sun, 13 Sep 2026 18:15:49 +0000

Vibe Coding Isn't the Problem. Calling It Engineering Is.

Vibe coding can help you build software faster.
The problem starts when “it works” becomes the definition of engineering.

There is a lot of debate around vibe coding.

Some developers think it is the future.

Others think it is destroying software engineering.

I think both sides are missing the real problem.

Vibe coding isn't inherently bad.

Using AI to generate code, prototype an idea, explore an unfamiliar API, or get from zero to something working can be incredibly useful.

The dangerous part is something else:

Confusing generated software with engineered software.

Those are not the same thing.

What Is Vibe Coding?

At its simplest:

Idea
  ↓
Prompt AI
  ↓
Generate code
  ↓
Run it
  ↓
"It works!"
  ↓
Ship it

This can be surprisingly effective.

You describe what you want.

An AI generates an implementation.

You run it.

It works.

You move on.

For a weekend project?

Great.

For a prototype?

Often great.

For testing an idea?

Fantastic.

But now imagine applying the exact same workflow to:

authentication
payments
medical software
financial systems
distributed infrastructure
security-sensitive applications
systems expected to run for years

The standard changes completely.

Working ≠ Engineered

This is the distinction that gets lost.

A program that works for the happy path is not automatically good software.

Consider:

def login(username, password):
    if username == "admin" and password == "1234":
        return True
    return False

It works.

You can log in.

The feature is technically functional.

But would you call this production authentication?

Obviously not.

Engineering asks questions that "does it work?" doesn't answer.

Does it work?
     ↓
Is it correct?
     ↓
Is it secure?
     ↓
Is it maintainable?
     ↓
Is it observable?
     ↓
Does it fail safely?
     ↓
Can someone else understand it?
     ↓
Can we change it six months from now?

That's engineering.

AI Is Extremely Good at Producing Code

And that's exactly why this conversation matters.

Modern coding models can generate surprisingly large amounts of software.

They can:

create components
write APIs
generate tests
refactor code
explain unfamiliar code
create database queries
scaffold projects
fix obvious bugs
connect services
generate documentation

The productivity gain is real.

But there is an important asymmetry:

Generating code is becoming cheap. Understanding code is still expensive.

That's the part people underestimate.

The Real Bottleneck Is Understanding

Imagine an AI generates 15,000 lines of code for your project.

You didn't manually write those lines.

But now you own them.

You need to understand:

Architecture
     │
     ├── Data flow
     ├── Dependencies
     ├── Security assumptions
     ├── Failure modes
     ├── Performance
     ├── State management
     └── Deployment

The code may have been generated in minutes.

Understanding it may take days.

That's why AI doesn't eliminate engineering.

It can actually increase the amount of software you need to reason about.

The "It Works" Trap

One of the easiest mistakes in AI-assisted development is this:

Prompt
  ↓
Code
  ↓
Run
  ↓
Works
  ↓
Ship

But professional engineering looks more like:

Problem
   ↓
Requirements
   ↓
Constraints
   ↓
Design
   ↓
Implementation
   ↓
Tests
   ↓
Review
   ↓
Observability
   ↓
Security
   ↓
Deployment
   ↓
Maintenance

Notice something?

Coding is only one part of the process.

Vibe Coding Is Great at the Beginning

There is a reason people love it.

The feedback loop is ridiculously fast.

You can go from:

"I have an idea"

to:

"I have a working prototype"

in an afternoon.

That's powerful.

For example:

Day 0

Idea
 │
 ▼
AI
 │
 ▼
Prototype
 │
 ▼
Demo
 │
 ▼
Feedback

Without AI, this might have taken considerably longer.

That's not a problem.

That's leverage.

The mistake is assuming the prototype has automatically become a production system.

Prototype ≠ Product

This is perhaps the most important distinction.

A prototype optimizes for:

Speed of learning.

Production software optimizes for:

Reliability over time.

Those goals are different.

Prototype

Speed
  ████████████████████
Reliability
  ███████


Production

Speed
  ███████████
Reliability
  ████████████████████

A prototype asks:

"Can this work?"

Engineering asks:

"Can this continue working when reality happens?"

Reality includes:

unexpected users
malicious input
network failures
corrupted data
traffic spikes
dependency failures
partial deployments
changing requirements
future developers

The AI Doesn't Own the Consequences

This is another uncomfortable truth.

When an AI generates bad code, the AI isn't on call at 3 AM.

You are.

When the database gets corrupted:

you own it.

When a security vulnerability is discovered:

you own it.

When the deployment breaks production:

you own it.

When a future developer asks:

"Why the hell does this work like this?"

Guess who's responsible?

The engineer.

Engineering Is About Managing Uncertainty

This is why software engineering is more than programming.

Programming is largely about telling a computer what to do.

Engineering is about making decisions under constraints.

        ENGINEERING
             │
    ┌────────┼────────┐
    ▼        ▼        ▼
 Correctness Security Reliability
    │        │        │
    └────────┼────────┘
             ▼
        Maintainability
             │
             ▼
          Longevity

You are constantly balancing:

cost
complexity
performance
security
reliability
developer experience
deadlines
business requirements

AI can help with those decisions.

But someone still has to make them.

The Best Developers Will Probably Vibe Code

Ironically, I don't think the future is:

"Real engineers don't use AI."

Quite the opposite.

The strongest developers will probably use AI aggressively.

But they won't surrender the engineering process to it.

They'll use AI for:

Exploration
Scaffolding
Boilerplate
Refactoring
Testing
Research
Documentation
Debugging

And they'll keep humans in the loop for:

Architecture
Tradeoffs
Security
Requirements
System boundaries
Risk
Correctness
Ownership

That is a much more powerful model.

Think of AI as a Very Fast Junior Engineer

A useful mental model is:

AI is a ridiculously fast junior engineer who has read an absurd amount of code but can confidently make mistakes.

That means you don't ask:

"Can AI write this?"

You ask:

"How should I use AI here?"

For example:

Good use

"Generate three approaches for this API and explain the tradeoffs."

Better use

"Implement option two and write tests for the edge cases."

Engineering use

"Implement option two, identify security risks, explain assumptions, and give me a test strategy."

The difference isn't the model.

It's the human using it.

The New Skill Isn't Prompting

Prompting matters.

But I think a more important skill is emerging:

Judgment.

When AI produces code, can you tell whether it is:

correct?
overcomplicated?
insecure?
inefficient?
unnecessary?
inconsistent with the rest of the system?

That requires fundamentals.

You still need to understand:

Data structures
Algorithms
Networking
Databases
Operating systems
Security
Distributed systems
Architecture
Testing

AI changes how you use those fundamentals.

It doesn't make them irrelevant.

From "Code Writer" to "System Designer"

There is a bigger shift happening.

Historically:

Engineer
   ↓
Write code

Increasingly:

Engineer
   ↓
Understand problem
   ↓
Design system
   ↓
Use AI to implement
   ↓
Verify
   ↓
Operate
   ↓
Improve

The value moves upward.

You don't necessarily become less important because AI writes more code.

You become responsible for more of the system around the code.

The Architecture Problem

This is where AI-generated applications can become especially dangerous.

You can ask AI to build:

Frontend
   ↓
API
   ↓
Database

And it will happily produce something.

But real systems quickly become:

                 ┌─────────────┐
                 │   Clients   │
                 └──────┬──────┘
                        │
                        ▼
                 ┌─────────────┐
                 │ API Gateway │
                 └──────┬──────┘
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
       Auth          Service A     Service B
          │             │             │
          ▼             ▼             ▼
       Database       Queue         Cache
                        │
                        ▼
                     Workers
                        │
                        ▼
                    Storage

At that point, generating code is only a small part of the job.

The difficult questions become:

Where should state live?
What happens when the queue fails?
What happens when a request is retried?
How do services authenticate?
Which operations are idempotent?
Where are transactions required?
How do you observe failures?
What happens during partial outages?

No amount of "make me a full-stack app" changes those questions.

Documentation Becomes More Important

There's another interesting consequence.

When AI makes code generation faster, understanding the system becomes harder.

That makes good documentation more valuable, not less.

And not just README files.

Teams need:

architecture diagrams
dependency maps
data-flow diagrams
API documentation
decisions
assumptions
operational runbooks

A visual representation can sometimes explain what hundreds of lines of code cannot.

For example:

Request
  │
  ▼
Gateway
  │
  ├──── Auth ──────► User DB
  │
  ▼
Order Service
  │
  ├────► PostgreSQL
  │
  └────► Queue
             │
             ▼
          Worker
             │
             ▼
        Notifications

The more software we generate, the more important it becomes to understand how the pieces fit together.

So, Should We Stop Vibe Coding?

No.

We should stop pretending it is the entire engineering process.

Vibe code.

Prototype.

Experiment.

Generate.

Throw things away.

Use AI to move ridiculously fast.

But when something matters?

Slow down.

Understand it.

Test it.

Review it.

Document it.

Design it.

Own it.

The New Rule

I would describe the distinction like this:

Vibe Coding

"Make it work."


Engineering

"Make it work,
make it understandable,
make it safe,
make it maintainable,
and make sure we know why."

Neither approach is inherently wrong.

They're optimized for different things.

The problem happens when we use the first definition while claiming we're doing the second.

AI Didn't Kill Engineering

It exposed what engineering actually is.

If your definition of engineering was:

"I personally typed every line."

Then AI absolutely threatens your definition.

But if engineering means:

understanding a problem, making sound technical decisions, managing complexity, validating assumptions, and building systems that survive reality

then AI doesn't eliminate engineering.

It makes those skills more valuable.

Because when anyone can generate 10,000 lines of code...

the scarce resource isn't code anymore.

It's judgment.

Final Thought

The future probably won't belong to developers who refuse to use AI.

And it probably won't belong to people who blindly let AI build everything either.

It will belong to people who can do both:

Move incredibly fast when speed matters.

and

Think incredibly deeply when correctness matters.

That's the difference between generating software and engineering software.

Vibe coding isn't the problem.

Calling the vibe the engineering is.

Sketchflow: A Visual Workspace for Developers Who Think Beyond Code

Sh Raj — Sun, 13 Sep 2026 18:09:15 +0000

Sketchflow: A Visual Workspace for Developers Who Think Beyond Code

Code tells computers what to do. Diagrams help humans understand why.

Software development is full of things that are difficult to express in code alone.

Architecture.

System design.

Data flow.

API relationships.

Database schemas.

Feature planning.

Debugging.

Project structure.

And when a project gets large enough, explaining these things often becomes harder than building them.

That's where Sketchflow comes in.

It is a visual workspace built around the idea that developers shouldn't have to jump between code, diagrams, documentation, and project context just to understand what they're building.

The Problem With Modern Development Workflows

A typical development workflow might look something like this:

GitHub
  ↓
Code
  ↓
Documentation
  ↓
Figma / Excalidraw
  ↓
Architecture diagram
  ↓
Chat
  ↓
Back to GitHub
  ↓
"What were we working on again?"

Every tool solves a specific problem.

But the context is fragmented.

You might have:

source code in GitHub
architecture diagrams somewhere else
documentation in Notion
ideas in a whiteboard
tasks in an issue tracker
API information in another document

The result?

Your project has plenty of information, but that information isn't necessarily connected.

Enter Sketchflow

Sketchflow is a GitHub-native visual workspace designed to bring visual thinking closer to your development workflow.

Instead of treating diagrams and visual documentation as completely separate artifacts, the goal is to make the visual layer part of how developers understand and communicate their projects.

Think of it as a bridge:

                 ┌───────────────────┐
                 │      GitHub       │
                 │  Code • Issues    │
                 │  Repositories     │
                 └─────────┬─────────┘
                           │
                           ▼
                 ┌───────────────────┐
                 │    SKETCHFLOW     │
                 │                   │
                 │  Visual Workspace │
                 │  Architecture     │
                 │  Ideas            │
                 │  Documentation    │
                 └─────────┬─────────┘
                           │
                           ▼
                 ┌───────────────────┐
                 │     Your Team     │
                 │ Understand • Plan │
                 │ Build • Explain   │
                 └───────────────────┘

The important idea isn't simply "make diagrams."

It's:

Make the visual representation of a software project part of the project itself.

Why Visual Thinking Matters in Software

Consider a simple application.

You might have:

                    ┌─────────────┐
                    │   Client    │
                    │  Web / App  │
                    └──────┬──────┘
                           │
                           ▼
                    ┌─────────────┐
                    │ API Server  │
                    └──────┬──────┘
                           │
                ┌──────────┴──────────┐
                ▼                     ▼
        ┌─────────────┐       ┌─────────────┐
        │ PostgreSQL  │       │    Redis    │
        └─────────────┘       └─────────────┘

You can explain this architecture in 500 words.

Or you can show it in five seconds.

That's the power of visual communication.

A good diagram can make complicated systems immediately understandable.

From Repository to Visual Understanding

One of the interesting things about a GitHub-native workflow is that the repository becomes the natural center of gravity.

Instead of:

Repository → Separate diagram → Separate documentation

you can think about your project as:

                 PROJECT
                    │
       ┌────────────┼────────────┐
       │            │            │
       ▼            ▼            ▼
     Code       Visuals     Documentation
       │            │            │
       └────────────┼────────────┘
                    │
                    ▼
               Team Context

That makes visual artifacts more useful because they aren't just pretty pictures.

They become part of the project's understanding.

Great for System Design

If you're preparing for technical interviews, working on a startup, building open-source software, or simply trying to understand a large codebase, system design is unavoidable.

You might need to visualize:

microservices
databases
queues
caches
authentication
APIs
event-driven systems
cloud infrastructure
frontend/backend relationships

For example:

                         ┌──────────────┐
                         │    Users     │
                         └───────┬──────┘
                                 │
                                 ▼
                         ┌──────────────┐
                         │ Load Balancer│
                         └───────┬──────┘
                                 │
                    ┌────────────┼────────────┐
                    ▼            ▼            ▼
                 API #1       API #2       API #3
                    │            │            │
                    └────────────┼────────────┘
                                 │
                 ┌───────────────┴──────────────┐
                 ▼                              ▼
           ┌───────────┐                  ┌───────────┐
           │ PostgreSQL│                  │   Redis   │
           └───────────┘                  └───────────┘

A visual workspace makes this kind of thinking much easier to communicate.

Perfect for Open Source Projects

Open-source projects have a communication problem.

A contributor may understand the code.

Another contributor may understand the architecture.

A new developer may understand neither.

Good visual documentation can dramatically reduce that learning curve.

Imagine opening a repository and seeing:

                 ┌───────────────────┐
                 │     Project       │
                 └─────────┬─────────┘
                           │
          ┌────────────────┼────────────────┐
          │                │                │
          ▼                ▼                ▼
      Frontend          Backend          Workers
          │                │                │
          ▼                ▼                ▼
       React            FastAPI          Celery
                           │
                           ▼
                       Database

Before reading hundreds of files, you already have a mental model.

That's incredibly valuable.

Visual Documentation ≠ Decoration

There's an important distinction here.

A diagram shouldn't exist simply because it looks nice.

A useful diagram answers a question.

For example:

"How does authentication work?"

User
 │
 ▼
Login
 │
 ▼
Auth Service
 │
 ├──────► PostgreSQL
 │
 ▼
JWT
 │
 ▼
API Requests
 │
 ▼
Authorization Middleware

Or:

"What happens when a user uploads a file?"

Upload
  │
  ▼
API
  │
  ▼
Validation
  │
  ▼
Object Storage
  │
  ▼
Queue
  │
  ▼
Worker
  │
  ▼
Processing
  │
  ▼
Database

The visual representation becomes a form of documentation.

Sketchflow Fits the Developer Mindset

The interesting part about a developer-focused visual workspace is that developers don't only think in documents.

We think in:

nodes
    ↓
relationships
    ↓
dependencies
    ↓
flows
    ↓
systems

That's exactly what diagrams are good at representing.

Instead of writing:

"The API communicates with the authentication service, which validates the user's credentials before generating a token..."

you can show the relationship:

Client
  │
  │ login()
  ▼
Auth API
  │
  │ validate()
  ▼
Database
  │
  │ success
  ▼
JWT
  │
  ▼
Client

The second representation is often much faster to understand.

Use Cases

Sketchflow can be useful across different stages of development.

🧠 Brainstorming

Turn an idea into a visual structure before writing code.

IDEA
 │
 ├── Users
 ├── Features
 ├── Data
 ├── APIs
 └── Infrastructure

🏗️ Architecture

Map out how your components communicate.

Frontend
   │
   ▼
API Gateway
   │
   ├── Auth
   ├── Users
   ├── Payments
   └── Notifications

🐛 Debugging

Visualize where a request or event is failing.

Client
  ↓
Gateway ✓
  ↓
API ✓
  ↓
Queue ✓
  ↓
Worker ✗

📚 Documentation

Give contributors a mental model of your system before they dive into the code.

👥 Collaboration

Discuss architecture visually instead of trying to explain everything through paragraphs of text.

A Better Development Loop

A powerful workflow could look like this:

        IDEA
         │
         ▼
     VISUALIZE
         │
         ▼
      DESIGN
         │
         ▼
       CODE
         │
         ▼
       TEST
         │
         ▼
     DOCUMENT
         │
         ▼
      SHARE
         │
         └──────────► Iterate

The visual layer isn't necessarily something you use once.

It can evolve with the project.

Why GitHub-Native Matters

Developers already live in GitHub.

That's where repositories, pull requests, issues, commits, and collaboration happen.

So putting visual project context closer to that ecosystem makes sense.

Instead of asking:

"Where is the latest architecture diagram?"

you want the answer to be much closer to:

"It's part of the project."

That is the direction Sketchflow is taking with its GitHub-native visual workspace.

Built for More Than Developers

Although the developer workflow is an obvious use case, visual workspaces can also be useful for:

product teams
technical writers
startup founders
designers
students
engineering teams
open-source maintainers
educators

Anything that involves explaining relationships between things can benefit from visualization.

The Bigger Idea

Tools often force us to choose between different representations of knowledge.

Text.

Code.

Diagrams.

Tables.

Tasks.

But real-world projects don't fit neatly into one format.

A software project is simultaneously:

                 PROJECT
                    │
       ┌────────────┼────────────┐
       ▼            ▼            ▼
      CODE       CONCEPTS     PEOPLE
       │            │            │
       ▼            ▼            ▼
    SYSTEMS      DIAGRAMS      TEAM
       │            │            │
       └────────────┼────────────┘
                    ▼
                KNOWLEDGE

The future of developer tooling isn't necessarily about creating yet another place to store information.

It's about connecting the different ways we think about information.

And that's what makes the idea behind Sketchflow interesting.

Try Sketchflow

If you've ever opened a large repository and thought:

"I wish I could just see how all of this fits together."

That's exactly the kind of problem worth solving visually.

Sketchflow is building toward a GitHub-native visual workspace where developers can think, explain, design, and understand their projects visually.

👉 Try it: sketchflow.space

Don't just read your codebase.

See it. Understand it. Explain it.

Final Thought

Software is becoming more complex.

Teams are becoming more distributed.

Codebases are becoming larger.

And documentation isn't getting any easier.

Maybe the answer isn't writing more documentation.

Maybe it's giving developers better ways to visualize the systems they're already building.

That's the idea behind Sketchflow.

Your code tells the computer what to do.

Your visual workspace helps humans understand it.

Harness Engineering Isn't Dead — It Just Moved

Sh Raj — Sun, 13 Sep 2026 18:05:42 +0000

Harness Engineering Isn't Dead — It Just Moved

AI agents are getting easier to build. But the interesting part isn't that the harness disappeared — it's that more of the harness is becoming infrastructure.

For a long time, building an AI agent meant building much more than an LLM call.

You needed:

Tool calling
Agent loops
Retries
Context management
File handling
Code execution
Sandboxing
State management
Observability
Multi-agent orchestration
Error recovery

In other words, you needed a harness.

Now, things are changing.

On September 10, 2026, OpenAI introduced the Agents API, a public-beta API that provides a managed Codex harness and infrastructure for running cloud agents. OpenAI says the harness manages things such as orchestration, long-running sessions, context management, and recovery, while developers can focus on their agent's tools, knowledge, and workflows.

So is harness engineering dead?

No.

But something important is happening:

Generic harness infrastructure is becoming a managed platform capability.

And that changes what AI developers should spend their time building.

🧠 The simplest explanation

Imagine an LLM is a very intelligent person.

You give it a task:

"Investigate why our API has a high error rate and create a report."

The model can reason.

But reasoning alone isn't enough.

It needs to:

Inspect logs
Search files
Run commands
Call APIs
Save intermediate results
Retry failed operations
Maintain context
Possibly delegate work
Produce the final report

The model is only one component.

Something has to coordinate all of this.

That surrounding system is what we commonly call an agent harness.

A simplified view:

flowchart TD
    U[User] --> A[Agent Application]
    A --> H[Agent Harness]
    H --> M[LLM]
    H --> T[Tools]
    H --> S[State & Context]
    H --> X[Execution Environment]
    H --> O[Observability]

The important idea is:

An LLM generates decisions. The harness turns those decisions into a reliable workflow.

1. What Exactly Is an Agent Harness?

The term "harness" isn't a single universally standardized component.

Different platforms may use the term differently.

But conceptually, an agent harness is the system around the model that enables an agent to act repeatedly and reliably.

For example:

Model
  ↓
"I need to inspect app.py"
  ↓
Harness
  ↓
File tool
  ↓
app.py
  ↓
Harness
  ↓
Model
  ↓
"I found the bug"
  ↓
Harness
  ↓
Edit file
  ↓
Run tests
  ↓
Model
  ↓
Final response

Without something coordinating those steps, you're mostly dealing with a model that produces outputs.

With a harness, you're building an agentic system.

2. LLM vs Agent

This distinction is extremely important.

An LLM call

A basic application might look like:

response = model.generate(
    "Explain this Python function"
)

The flow is basically:

flowchart LR
    A[Application] --> B[LLM]
    B --> C[Response]

Simple.

But now imagine:

"Fix the bug in this repository."

The agent might need to:

Read repository
     ↓
Find relevant files
     ↓
Understand code
     ↓
Edit code
     ↓
Run tests
     ↓
Read failures
     ↓
Modify code again
     ↓
Run tests again
     ↓
Produce result

That's no longer one model call.

It's a loop.

3. The Agent Loop

A simplified agent loop looks like this:

flowchart TD
    A[Start Task] --> B[Send Context to Model]
    B --> C{Model Decision}
    C -->|Final Answer| D[Return Result]
    C -->|Tool Call| E[Execute Tool]
    E --> F[Return Tool Result]
    F --> B

The important part is the loop:

Model
 ↓
Tool
 ↓
Result
 ↓
Model
 ↓
Tool
 ↓
Result
 ↓
Model

This is where a lot of the engineering happens.

You have to decide:

What tools exist?
Which tools can the model use?
What arguments are valid?
How are failures handled?
How long can execution continue?
How is context maintained?
When should the agent stop?
When should it retry?
When should a human approve an action?

That's harness engineering.

4. The Old Way: Build Everything Yourself

Imagine you want to build a coding agent.

A simplified architecture could look like this:

flowchart TD
    U[User] --> A[Your Application]

    A --> H[Your Agent Harness]

    H --> M[LLM]
    H --> F[File System]
    H --> T[Tools]
    H --> C[Code Execution]
    H --> DB[Database]
    H --> L[Logs]

    C --> SB[Sandbox]

You own almost everything.

You might have to implement:

Agent loop
Retry logic
Tool execution
Tool permissions
Context handling
State
File management
Code execution
Sandbox
Logging
Tracing
Error recovery

At first, this can feel manageable.

Then your agent becomes more capable.

And suddenly your "small AI project" has turned into an infrastructure project.

5. Why Sandboxing Is Hard

This is one of the most important parts.

Suppose your agent can execute code.

The model generates:

import os

os.system("rm -rf important-data")

You obviously don't want arbitrary model-generated code running directly on your production machine.

So you need an isolated environment.

Something like:

flowchart TD
    A[Agent] --> B[Sandbox]

    B --> C[Files]
    B --> D[Processes]
    B --> E[Python]
    B --> F[Shell]
    B --> G[Packages]

    B -. Restricted .-> H[Production Systems]

Now you need to think about:

Filesystem isolation
Network access
Secrets
CPU limits
Memory limits
Process isolation
Timeouts
Cleanup
Persistence
Authentication
Permissions

This is a serious engineering problem.

OpenAI has explicitly described the need for computer environments where agents can work with files, execute code, and persist intermediate results, and has also discussed the security controls required when agents act autonomously.

6. Then Came Agent SDKs

The next abstraction was the Agent SDK.

Instead of manually implementing every part of the agent loop, an SDK could provide abstractions for things like:

Agents
Tools
Handoffs
Tracing
Approvals
Context
Execution

The architecture becomes:

flowchart TD
    U[User] --> A[Your Application]
    A --> SDK[Agent SDK]

    SDK --> M[Model]
    SDK --> T[Tools]
    SDK --> O[Observability]
    SDK --> W[Workflow]

This is much better.

But there is still a distinction between:

Using an SDK

and

Using a fully managed agent runtime.

The SDK can simplify your application code while you may still be responsible for running and operating the environment.

OpenAI's April 2026 update to the Agents SDK explicitly described a more capable harness with tools, approvals, tracing, handoffs, resume bookkeeping, and sandbox environments.

7. The Next Step: Managed Agent Infrastructure

Now we reach the interesting part.

Instead of you operating the entire agent runtime, the platform can provide more of it.

The conceptual shift looks like this:

Before

flowchart TD
    A[Your App] --> B[Your Harness]
    B --> C[Your Sandbox]
    B --> D[Your State]
    B --> E[Your Observability]
    B --> F[Model Provider]

With managed agent infrastructure

flowchart TD
    A[Your App] --> B[Managed Agent Platform]

    B --> C[Agent Harness]
    B --> D[Session Management]
    B --> E[Context Management]
    B --> F[Tool Orchestration]
    B --> G[Observability]
    B --> H[Recovery]

    B --> I[Sandbox]
    B --> J[Model]

Now you can send a high-level task to the platform.

The platform handles much more of the execution machinery.

8. OpenAI's Agents API

On September 10, 2026, OpenAI announced the Agents API in public beta.

Its core idea is straightforward:

Build and run cloud agents using a managed Codex harness.

OpenAI says it hosts and maintains the harness while developers choose the agent's compute environment.

Those environments can include:

OpenAI-hosted sandboxes
Your own infrastructure
Supported sandbox providers

The API is designed around long-running agent sessions, tool use, context management, recovery, and multi-agent workflows.

This is a significant architectural shift.

9. What OpenAI Is Actually Managing

It's important not to misunderstand this.

The Agents API doesn't mean:

"OpenAI builds your entire application."

Instead, the platform provides infrastructure around the agent.

According to OpenAI, the managed harness includes capabilities around:

Context management
Tool orchestration
Long-running sessions
Recovery
Subagents
Agent coordination

OpenAI also provides hosted sandbox infrastructure where agents can:

Run code
Work with files
Produce artifacts
Install packages
Use configured capabilities

Think of it like this:

flowchart TD
    A[Your Product] --> B[Agents API]

    B --> C[Managed Harness]
    B --> D[Model]
    B --> E[Session]
    B --> F[Context]
    B --> G[Tool Orchestration]
    B --> H[Sandbox]

    A --> I[Your Business Logic]
    A --> J[Your Tools]
    A --> K[Your Data]
    A --> L[Your UX]

The platform handles generic agent infrastructure.

You build the thing that makes your agent useful.

10. So... Is Harness Engineering Dead?

No.

This is the biggest misconception.

A better statement is:

Generic harness infrastructure is becoming commoditized and managed.

The harness hasn't disappeared.

It has moved.

Compare this to databases.

You could run PostgreSQL yourself.

Or you could use a managed database service.

The database didn't disappear.

The operational responsibility moved to another layer.

The same idea applies here.

flowchart LR
    A[Build Everything Yourself] --> B[Use SDK]
    B --> C[Use Managed Agent Runtime]

    A --> D[Maximum Control]
    C --> E[Maximum Abstraction]

11. The Harness Is Moving Up the Stack

Think about the evolution:

                    ABSTRACTION
                         ↑

       Managed Agent Infrastructure
                    │
              Agent SDKs
                    │
              Raw Model APIs
                    │
                HTTP APIs

                         ↓
                    MORE WORK

Or:

flowchart BT
    A[Raw Model API]
    B[Agent SDK]
    C[Managed Agent Runtime]
    D[Your Application]

    A --> B
    B --> C
    C --> D

Every step upward removes some infrastructure work.

But it also introduces trade-offs.

12. What Developers Still Need to Build

This is where things get interesting.

Imagine you're building an AI customer-support agent.

The platform may provide:

Agent runtime
Tool execution
Context management
Sandbox
Tracing
Sessions
Recovery

But it doesn't automatically know your business rules.

For example:

Should this customer receive a $500 refund?

That's your application.

Or:

Is this agent allowed to access the financial database?

That's your authorization system.

Or:

Should an email require human approval?

That's your workflow.

Or:

What information should the agent never reveal?

That's your policy and security layer.

So the architecture becomes:

flowchart TD
    U[User] --> A[Your Application]

    A --> BL[Business Logic]
    A --> AUTH[Authorization]
    A --> POL[Policies]
    A --> TOOLS[Your Tools]

    A --> AG[Managed Agent Runtime]

    AG --> H[Harness]
    AG --> S[Sandbox]
    AG --> CTX[Context]
    AG --> OBS[Observability]
    AG --> M[Model]

The infrastructure is managed.

The product intelligence is still yours.

13. The 80/20 Shift

A useful way to think about this is:

BEFORE

80% infrastructure
20% application


AFTER

20% infrastructure
80% application

These percentages aren't literal benchmarks.

They're a mental model.

The point is that developers can spend less time rebuilding generic agent infrastructure.

Instead, they can focus on:

Domain-specific tools
Business workflows
Data
User experience
Permissions
Evaluations
Reliability
Product design

14. But There Is a Trade-Off

Managed infrastructure sounds perfect.

It isn't.

The more you outsource, the less control you have over certain layers.

For example:

Managed Platform
       │
       ├── Convenience
       ├── Faster development
       ├── Less infrastructure
       └── Less control

You may have questions around:

Data residency
Privacy
Network access
Vendor lock-in
Cost
Custom runtimes
Debugging
Performance
Compliance
Security boundaries

This is why the ability to choose your execution environment matters.

OpenAI's Agents API allows developers to choose between OpenAI-hosted sandboxes, their own infrastructure, or supported sandbox providers.

So the future isn't necessarily:

"Everyone runs everything on OpenAI."

It can also be:

"The harness and execution environment become separate layers."

15. Harness vs Sandbox

This distinction is extremely important.

They're not the same thing.

Harness

The harness coordinates the agent.

Model
 ↓
Tool decision
 ↓
Tool execution
 ↓
Result
 ↓
Model

Sandbox

The sandbox provides an environment where the agent can safely execute things.

Files
Processes
Commands
Packages
Runtime

You can therefore have:

flowchart LR
    A[Agent Harness] --> B[Sandbox]
    A --> C[Model]
    A --> D[Tools]
    B --> E[Files]
    B --> F[Code]

And importantly, they don't have to live on the same machine.

OpenAI's Agents SDK documentation describes this separation as useful for isolation, durability, and security.

16. Why This Matters for Security

An agent that can execute code is fundamentally different from a chatbot.

A chatbot might generate:

"Here is a Python script."

An agent might actually execute:

subprocess.run(...)

That changes the threat model.

Now you need to think about:

        Agent
          │
          ▼
       Tools
          │
          ▼
      Permissions
          │
          ▼
       Sandbox
          │
          ▼
     External Systems

Every arrow is a potential security boundary.

This is why "just give the agent tools" is not a sufficient production architecture.

OpenAI has described the need for explicit boundaries, approval controls, and telemetry when deploying coding agents into real workflows.

17. What Happens to Agent Engineers?

This is perhaps the most interesting career question.

If platforms handle more of the generic harness, does that mean agent engineers become less important?

I don't think so.

Their responsibilities change.

Instead of spending most of their time implementing:

retry()
tool_loop()
context_manager()
sandbox_manager()

they may spend more time on:

agent architecture
tool design
permissions
evaluation
workflow design
memory
reliability
cost optimization
security
domain logic

The abstraction level rises.

18. The New Agent Engineering Stack

A useful model is:

flowchart BT
    A[Foundation Models]
    B[Agent Runtime]
    C[Tools + Sandbox]
    D[Application Logic]
    E[Product]

    A --> B
    B --> C
    C --> D
    D --> E

Each layer solves a different problem.

Layer 1 — Models

Reasoning and generation.

Layer 2 — Agent Runtime

Loops, context, orchestration, sessions, recovery.

Layer 3 — Tools & Execution

Files, code execution, APIs, databases, browsers, etc.

Layer 4 — Application Logic

Your business rules and workflows.

Layer 5 — Product

What users actually experience.

The more infrastructure providers manage, the more developers can concentrate on layers 3–5.

19. What About Custom Harnesses?

They aren't going away.

There will always be situations where you need more control.

For example:

Custom planning
Custom memory
Custom routing
Custom model selection
Custom evaluation
Custom security policies
Custom scheduling
Custom orchestration

A managed platform might give you the generic 80%.

Your custom system may implement the remaining 20%.

And sometimes that 20% is the actual competitive advantage.

20. Generic Harness vs Custom Harness

Problem	Managed Harness	Custom Harness
Basic agent loop	✅	✅
Tool orchestration	✅	✅
Context management	✅	✅
Long-running sessions	✅	✅
Sandbox infrastructure	Often	✅
Custom execution	Limited by platform	✅
Business logic	You build it	You build it
Maximum control	❌	✅
Development speed	✅	❌
Infrastructure burden	Lower	Higher
Vendor dependency	Higher	Lower

There isn't a universally correct choice.

It depends on what you're building.

21. Why Codex Is Important to This Story

The Agents API didn't appear out of nowhere.

OpenAI has been building agent infrastructure through Codex.

OpenAI describes the Codex harness as the system responsible for orchestrating interaction between the user, model, and tools.

OpenAI also published its experience with harness engineering after building a software product where Codex generated the code and the team focused heavily on environments, intent, feedback loops, tests, and agent-friendly infrastructure.

This is important because it demonstrates something:

The harness itself can become an engineering product.

And now OpenAI is exposing more of that infrastructure through an API.

22. Harness Engineering Is Actually Becoming MORE Important

Here's the paradox.

We're saying:

"The harness is becoming managed."

But at the same time:

"The harness is becoming more important."

Both can be true.

Why?

Because as agents become more capable, the difference between:

Model alone

and

Model + system

becomes enormous.

OpenAI's own engineering work describes the harness as a critical layer for making agents dependable in production. Its current Codex agent engineering roles explicitly cover harness behavior, sandboxing, orchestration, evaluation, observability, and reliability.

So the harness isn't becoming irrelevant.

It's becoming infrastructure.

23. The Bigger Pattern in Software

This isn't actually new.

Look at the history of software.

Servers

Physical server
      ↓
Virtual machines
      ↓
Cloud
      ↓
Serverless

Databases

Manage database yourself
      ↓
Managed database
      ↓
Serverless database

Infrastructure

Hardware
      ↓
Cloud infrastructure
      ↓
Managed services

And now:

AI agents

Raw model
      ↓
Agent SDK
      ↓
Managed agent runtime

The pattern is:

Infrastructure becomes abstraction.

24. What Developers Should Learn Now

If you're learning AI engineering today, don't focus only on API syntax.

Learn these concepts:

1. Agent loops

Understand:

Model → Tool → Result → Model

2. Tool design

Learn how to give agents reliable tools.

3. Context management

Understand what information the model receives and when.

4. Sandboxing

Understand how code execution should be isolated.

5. Permissions

Never assume the agent should have unlimited access.

6. Observability

You need to know what your agent actually did.

7. Evaluation

A working demo isn't necessarily a reliable agent.

8. Workflow design

Understand when agents should act autonomously and when humans should approve actions.

9. Cost and latency

More reasoning and more tool calls aren't free.

10. System architecture

Most importantly:

Know which layer should own which responsibility.

25. A Practical Mental Model

Whenever you're building an AI agent, ask these questions:

┌────────────────────────────────────┐
│ What does the model decide?        │
├────────────────────────────────────┤
│ What does the harness coordinate?  │
├────────────────────────────────────┤
│ What does the sandbox execute?     │
├────────────────────────────────────┤
│ What do my tools control?          │
├────────────────────────────────────┤
│ What does my application own?      │
├────────────────────────────────────┤
│ Where are the security boundaries? │
├────────────────────────────────────┤
│ Where is state stored?             │
├────────────────────────────────────┤
│ How do I evaluate the agent?       │
└────────────────────────────────────┘

If you can answer all of these, you understand the architecture.

26. The Future

I think we're moving toward a world where you won't start every AI project by asking:

"How do I build an agent loop?"

You'll start with:

"What should this agent accomplish?"

Then you'll choose how much infrastructure you want to own.

Something like:

flowchart TD
    A[Problem] --> B{How much control?}

    B -->|Fastest| C[Managed Agent Runtime]
    B -->|More control| D[Agent SDK]
    B -->|Maximum control| E[Custom Harness]

    C --> F[Application]
    D --> F
    E --> F

That's much more interesting than simply saying:

"Harness engineering is dead."

Because it isn't.

27. The Final Takeaway

The biggest change isn't:

"Developers don't need harnesses anymore."

It's:

"Developers don't necessarily need to own the generic harness infrastructure anymore."

That's a huge difference.

The future probably looks like:

             YOUR PRODUCT
                  │
                  ▼
          YOUR APPLICATION
                  │
        ┌─────────┴─────────┐
        │                   │
 Business Logic       Custom Workflows
        │                   │
        └─────────┬─────────┘
                  │
                  ▼
          MANAGED AGENT
             RUNTIME
                  │
       ┌──────────┼──────────┐
       │          │          │
    Harness    Sandbox    Tools
       │          │          │
       └──────────┼──────────┘
                  │
                  ▼
                MODEL

So...

Harness engineering isn't dead.

It is being pushed down the stack.

The generic parts are becoming platforms.

The custom parts are becoming more valuable.

And the job of the AI engineer is slowly moving from:

"How do I make the agent run?"

to:

"How do I make the agent reliably solve the right problem?"

That is a much more interesting engineering problem.

🚀 If You're Building AI Agents

Don't start by writing a giant agent framework.

Start with three questions:

What should the agent do?

Define the actual job.

What does the agent need access to?

Define tools, data, files, and permissions.

What should I own vs. outsource?

Decide whether you need:

Custom harness
        ↓
Agent SDK
        ↓
Managed agent runtime

The best architecture is not necessarily the one with the most code.

It's the one where every layer has a clear responsibility.

📚 Further Reading & Sources

OpenAI — Introducing the Agents API

The primary announcement for the managed Codex harness, cloud agents, hosted sandboxes, long-running sessions, and execution environments.

Read the Agents API announcement

OpenAI — Harness Engineering

A detailed look at how OpenAI approached software development around Codex agents and why agent-friendly environments and feedback loops matter.

Read Harness Engineering

OpenAI — Unrolling the Codex Agent Loop

A deeper explanation of the agent loop and the role of the Codex harness.

Read Unrolling the Codex Agent Loop

OpenAI — The Next Evolution of the Agents SDK

Useful background on sandbox environments, tools, approvals, tracing, handoffs, and agent execution.

Read the Agents SDK article

OpenAI — Running Codex Safely

A useful introduction to the security boundaries, approvals, controls, and telemetry required for autonomous agents.

Read Running Codex Safely

OpenAI — From Model to Agent

Explains why agents need computer environments, execution, intermediate files, and reliable workflow infrastructure.

Read From Model to Agent

💬 What do you think?

Do you think managed agent APIs will make custom harnesses obsolete?

Or will the best AI products still require their own orchestration layer?

I'd love to hear your take in the comments.

Demystifying Compiler Design: From Source Code to Executable (Course Overview)

Sh Raj — Sat, 29 Aug 2026 16:35:18 +0000

Why Care About Compiler Design?

Most developers treat compilers like a black box: write high-level code, hit build, and machine instructions come out. Understanding what happens inside that black box fundamentally changes how you write code, debug runtime failures, optimize performance, and design custom domain-specific languages (DSLs) or developer tools.

This course breaks down the end-to-end architecture of modern compilers into practical, digestible concepts—spanning lexical analysis, parsing, semantic verification, intermediate code generation, runtime environments, and low-level code optimization.

What We Will Build & Learn

The series is structured across five core milestones:

[ Source Code ] 
       │
       ▼
 [ Lexical Analysis (Tokens) ] ─────────► (DFA & Regex)
       │
       ▼
 [ Syntax Analysis (AST/CST) ] ─────────► (LL & LR Parsers)
       │
       ▼
 [ Semantic Analysis & SDTS ]  ─────────► (Type Checking & TAC)
       │
       ▼
 [ Intermediate Code & Runtime ] ───────► (Control Flow & Activation Records)
       │
       ▼
 [ Optimization & Assembly ]   ─────────► (CFG, Dead Code, Constant Folding)

Course Roadmap

1. Lexical Analysis (Scanning)

Anatomy of compilers and compilation phases.
Tokenization, lexemes, and input buffering techniques.
Direct conversion of Regular Expressions to Deterministic Finite Automata (DFA).

2. Syntax Analysis (Parsing)

Context-Free Grammars (CFG) and ambiguity elimination.
Top-down parsing strategies: Recursive Descent and predictive $LL(1)$ tables.
Bottom-up parsing: Shift-reduce mechanisms, $LR(0)$, $SLR(1)$, $LALR(1)$, and canonical $LR(1)$.
Practical error detection and recovery routines.

3. Semantic Analysis & Intermediate Code Generation

Syntax-Directed Definitions (SDD) and Syntax-Directed Translation Schemes (SDTS).
Synthesized vs. Inherited attribute evaluation.
Static type checking and symbol table operations.
Generating Three-Address Code (TAC) and translating complex array references.

4. Control Flow & Runtime Environments

Evaluating boolean logic (short-circuit vs. complete evaluation).
Resolving forward and backward branching in intermediate code.
Runtime stack organization, activation records, and function calls/returns.

5. Optimization & Code Generation

Constructing Basic Blocks and Control Flow Graphs (CFGs).
Machine-independent local and global optimizations.
Implementing Constant Folding, Dead Code Elimination, Common Subexpression Elimination, and Loop-Invariant Code Motion.
Emitting targeted machine instructions.

Who This Series Is For

CS Students: Preparing for core systems courses and technical interviews.
Software Engineers: Wanting to build custom linters, transpilers, AST analyzers, or programming languages.
Curious Builders: Wanting to demystify low-level systems and execution runtimes.

Follow along for **Part 1: The Anatomy of a Compiler & Building a Fast Lexical Scanner.

🔐 How Does a VPN Work?

Sh Raj — Fri, 28 Aug 2026 15:20:06 +0000

🔐 How Does a VPN Work?

The Complete Visual Guide

A VPN (Virtual Private Network) creates an encrypted connection between your device and a VPN server. It changes the path your internet traffic takes and makes websites see the VPN server's public IP address instead of your own.

But there is an important distinction:

A VPN improves privacy and security. It does not make you completely anonymous.

1. What Happens Without a VPN?

Normally, when you access a website, your traffic follows roughly this path:

flowchart LR
    A["💻 Your Device"] --> B["📡 Router"]
    B --> C["🌐 ISP"]
    C --> D["🌍 Internet"]
    D --> E["🖥️ Website"]

For example, when you open:

https://example.com

your request travels through your network and ISP before reaching the destination.

Who can see what?

Your ISP can generally see information such as:

That you're communicating over the internet
Which IP addresses you're connecting to
Timing and amount of traffic
Depending on the protocol and encryption, potentially more information

The website can see:

Your public IP address
Approximate geographic location derived from that IP
Your requests and account activity

2. What Changes When You Turn On a VPN?

Now imagine switching on a VPN:

flowchart LR
    A["💻 Your Device"] --> B["🔒 VPN Tunnel"]
    B --> C["🖥️ VPN Server"]
    C --> D["🌍 Internet"]
    D --> E["🖥️ Website"]

Instead of:

You → ISP → Website

the important part becomes:

You → ISP → 🔒 VPN Server → Website

The connection between your device and the VPN server is encrypted.

This is commonly described as an encrypted tunnel.

3. What Is the VPN Tunnel?

Think of your internet traffic as letters.

Without additional encryption, someone along the route may be able to inspect the contents if the traffic isn't otherwise protected.

A VPN puts that traffic inside an encrypted connection.

flowchart LR
    A["📄 Original Data"] --> B["🔐 Encryption"]
    B --> C["📦 Encrypted Data"]
    C --> D["🚇 Secure VPN Tunnel"]
    D --> E["🖥️ VPN Server"]
    E --> F["🌐 Destination"]

Conceptually:

BEFORE

GET /profile
User-Agent: Chrome
Cookie: ...


        ↓ VPN encryption


AFTER

8F 91 A2 7C 4B 19 0D
A8 31 F2 91 72 44 ...

The actual cryptographic protocols are considerably more sophisticated than simply converting readable text into random characters, but this gives you the right intuition.

4. What Actually Happens to a Packet?

Let's simplify the process.

Suppose you want to access:

example.com

Your device creates network traffic containing information needed to deliver the request.

The VPN client encrypts the appropriate traffic and sends it through the VPN connection.

sequenceDiagram
    participant U as 💻 You
    participant V as 🔒 VPN Server
    participant W as 🌐 Website

    U->>V: Encrypted VPN traffic
    V->>W: Request from VPN server
    W->>V: Response
    V->>U: Encrypted response

The VPN server acts as the middle point between you and the public internet.

5. Your IP Address Changes

This is one of the most noticeable effects of a VPN.

Without VPN

flowchart LR
    A["💻 You"] --> B["🌐 Website"]
    B --> C["Website sees:<br/>Your Public IP"]

With VPN

flowchart LR
    A["💻 You"] --> B["🔒 VPN Server"]
    B --> C["🌐 Website"]
    C --> D["Website sees:<br/>VPN Server IP"]

So if your actual public IP were:

203.0.113.10

the website might instead see something like:

198.51.100.25

—the public IP of the VPN server.

6. So Does the VPN Hide You From Your ISP?

Not completely.

This is one of the biggest misconceptions about VPNs.

Your ISP can still observe that your device is communicating with a VPN server.

flowchart LR
    A["💻 You"] --> B["ISP"]
    B --> C["🔒 VPN Server"]
    C --> D["🌐 Website"]

    B -. "Can see VPN connection" .-> C
    B -. "Cannot normally see inside VPN tunnel" .-> C

The ISP generally doesn't get to see the contents of the traffic protected by the VPN tunnel.

However, it can still observe metadata, such as traffic timing, volume, and the VPN server you're connecting to.

7. What Does the VPN Provider See?

This is extremely important.

When you use a VPN, you're shifting trust.

Without a VPN:

You → ISP → Internet

With a VPN:

You → ISP → VPN Provider → Internet

The VPN provider operates the server through which your traffic exits.

Therefore, your VPN provider may be able to observe significant information about your connection, depending on its infrastructure, logging practices, configuration, and the protocols/services involved.

The key idea:

A VPN doesn't eliminate trust. It moves part of that trust from your ISP to the VPN provider.

That's why choosing a trustworthy VPN provider matters.

8. What Does the Website See?

From the website's perspective:

flowchart LR
    A["💻 Your Device<br/>203.0.113.10"]
    B["🔒 VPN Server<br/>198.51.100.25"]
    C["🌐 Website"]

    A --> B
    B --> C

The website generally sees:

Source IP:
198.51.100.25

rather than:

203.0.113.10

This is why VPNs can also make it appear as though you're connecting from another region when the VPN server is located there.

9. But What About HTTPS?

Here's an important layer that many basic VPN explanations skip.

A VPN isn't the only thing protecting your data.

When you visit:

https://example.com

HTTPS typically provides encryption between your browser and the website.

So you can think of the connection as having multiple security layers.

flowchart LR
    A["💻 Your Device"]
    B["🔒 VPN Encryption"]
    C["🌐 Internet"]
    D["🔐 HTTPS"]
    E["🖥️ Website"]

    A --> B --> C --> D --> E

A simplified mental model is:

Your Device
     │
     │ VPN encryption
     ▼
VPN Server
     │
     │ HTTPS encryption
     ▼
Website

This is why saying:

"Without a VPN, your ISP can read all your passwords"

is generally wrong for HTTPS websites.

Modern HTTPS already protects the contents of your web traffic from ordinary network observers.

10. VPN vs HTTPS

Feature	VPN	HTTPS
Encrypts connection between you and VPN server	✅	❌
Encrypts browser ↔ website traffic	Not necessarily by itself	✅
Hides your public IP from website	✅	❌
Hides VPN use from ISP	❌	❌
Protects against some hostile local networks	✅	✅ for HTTPS traffic
Makes you anonymous	❌	❌

Best mental model

VPN = protects the path to the VPN server
HTTPS = protects the connection to the website

Using both can provide complementary protections.

11. The Complete Journey of a Request

Let's put everything together.

Suppose you type:

youtube.com

Step 1 — Your device creates traffic

💻 Browser
   ↓
Request for youtube.com

Step 2 — VPN encrypts the VPN connection

💻 Device
   ↓
🔐 Encrypted VPN traffic

Step 3 — Traffic travels to the VPN server

💻 You
   ↓
🔒 VPN Tunnel
   ↓
🖥️ VPN Server

Step 4 — VPN server sends the request onward

VPN Server
    ↓
🌐 Internet
    ↓
YouTube

Step 5 — Website responds

YouTube
   ↓
VPN Server
   ↓
🔒 VPN Tunnel
   ↓
💻 You

12. The Complete VPN Flow

flowchart LR
    A["💻 YOU<br/>Real IP"] 
    B["🔐 Encrypt"]
    C["🚇 VPN Tunnel"]
    D["🖥️ VPN SERVER<br/>VPN IP"]
    E["🌍 INTERNET"]
    F["🌐 WEBSITE"]

    A --> B --> C --> D --> E --> F

    F --> E --> D --> C --> B --> A

Or remember it as:

YOU
 │
 │  🔐 encrypted
 ▼
╔══════════════════════╗
║    VPN TUNNEL        ║
╚══════════════════════╝
 │
 ▼
VPN SERVER
 │
 │
 ▼
INTERNET
 │
 ▼
WEBSITE

13. Why Use a VPN?

VPNs can be useful for several legitimate reasons.

☕ Public Wi-Fi

On an untrusted network, a VPN can provide an additional encrypted layer between your device and the VPN server.

Laptop
   │
   │ 🔒
   ▼
Public Wi-Fi
   │
   ▼
VPN Server

🌍 Change apparent IP location

The website sees the VPN server's IP rather than your own public IP.

🛡️ Additional privacy

It prevents your ISP from directly seeing the contents of traffic protected by the VPN tunnel.

🏢 Remote work

Organizations commonly use VPN technologies to provide secure access to internal resources.

14. What a VPN Does NOT Do

A VPN is not an invisibility cloak.

❌ It doesn't make you completely anonymous

If you log into:

Google
Instagram
GitHub
YouTube

those services can still associate activity with your account.

❌ It doesn't make malware harmless

If you download malware while connected to a VPN:

VPN + Malware = Still Malware

❌ It doesn't stop phishing

A VPN won't prevent you from entering your password into a fake website.

❌ It doesn't automatically stop tracking

Websites can use:

Cookies
Browser fingerprinting
Logged-in accounts
Tracking technologies
Other identifiers

A VPN mainly changes the network-level source IP and protects the VPN leg of the connection.

15. VPN ≠ Tor

Another common misconception is that a VPN and Tor are the same thing.

They're not.

VPN

flowchart LR
    A["You"] --> B["VPN Server"] --> C["Website"]

Tor

Simplified:

flowchart LR
    A["You"] --> B["Entry Node"] --> C["Middle Node"] --> D["Exit Node"] --> E["Website"]

Tor routes traffic through multiple relays rather than relying on one VPN server.

Each technology has different goals, trade-offs, and threat models.

16. A VPN in One Diagram

The simplest way to remember it:

             WITHOUT VPN

YOU ──────── ISP ───────── WEBSITE
 │                           │
 └────── Your IP ────────────┘


              WITH VPN

YOU ───🔐 ENCRYPTED─── VPN SERVER ─── WEBSITE
                         │
                         └── Website sees VPN IP

17. The Most Important Concept

Don't think:

"A VPN makes me invisible."

Think:

"A VPN changes the path my traffic takes and encrypts the connection between my device and the VPN server."

That's a much more accurate mental model.

🧠 Final Takeaway

A VPN essentially works like this:

1. You connect to a VPN server
             ↓
2. A secure encrypted VPN connection is established
             ↓
3. Your traffic travels through that connection
             ↓
4. The VPN server sends traffic to the internet
             ↓
5. Websites see the VPN server's IP
             ↓
6. Responses return through the VPN connection

In one sentence:

A VPN creates an encrypted tunnel between your device and a VPN server, routing your internet traffic through that server so your public IP is masked from the destinations you connect to.

And the most important caveat:

VPN ≠ anonymity.

It is a privacy and security tool, not magic.

🎬 If you're turning this into your short

The article gives you the complete technical foundation. For the Reel, I'd reduce it to one story:

Normal internet → VPN tunnel appears → packet gets encrypted → VPN server forwards it → website sees VPN IP → “But VPN ≠ anonymity.”

That gives you a much stronger visual narrative than trying to explain every VPN protocol in 60 seconds.

Why Are We Still Running AI on Computers That Were Never Built for AI?

Sh Raj — Wed, 29 Jul 2026 18:06:31 +0000

Why Are We Still Running AI on Computers That Were Never Built for AI?

The next trillion-dollar breakthrough may not be a bigger language model—it may be an entirely new way of computing.

The Question Nobody Seems to Be Asking

Every few months, a new AI model is released.

It has more parameters.

Requires more GPUs.

Consumes more electricity.

Costs more money to train.

And everyone celebrates because it's "more powerful."

But what if we're solving the wrong problem?

What if the real bottleneck isn't the AI model at all?

What if it's the computer?

Imagine Teaching a Fish to Climb a Tree

Today's computers were never designed for Artificial Intelligence.

The CPU in your laptop was designed to run operating systems, browsers, spreadsheets, games, compilers, and thousands of other applications.

GPUs were originally built to render graphics for video games.

Then one day researchers discovered that GPUs happened to be incredibly good at matrix multiplication, the mathematical operation behind deep learning.

That accidental discovery changed AI forever.

But here's the question:

Why are we still relying on hardware that wasn't originally built for AI?

Every Generation Keeps Upgrading the Wrong Thing

Every year, researchers make AI models bigger.

More parameters
More data
More GPUs
More memory
More electricity

It's like trying to make a car faster by adding bigger engines every year while keeping the same inefficient roads.

Maybe the road is the real problem.

We've Been Thinking Inside the Same Box for Decades

Modern computers still follow principles developed many decades ago.

Information moves between memory and processors.

The processor performs calculations.

The result goes back into memory.

This happens billions of times every second.

Ironically, much of the energy isn't spent calculating.

It's spent moving data around.

Imagine walking across your house every single time you wanted to use a pencil.

Eventually, walking becomes more exhausting than writing.

Modern AI systems face a similar inefficiency.

What If We Started From Zero?

Forget CPUs.

Forget GPUs.

Forget operating systems.

Forget even the assumption that computers must be general-purpose machines.

Instead, ask a completely different question:

"If Artificial Intelligence were invented before the modern computer, what kind of hardware would we build?"

That question changes everything.

A Computer That Knows Only AI

Imagine buying a computer that cannot:

Open Chrome
Run Windows
Play games
Compile code
Browse files

It has only one purpose.

Running AI.

Nothing else.

Every transistor.

Every circuit.

Every electrical pathway.

Every memory cell.

Optimised for neural computation.

Would it outperform today's hardware?

Possibly by a huge margin.

Maybe We Should Redesign the Flow of Electricity

Here's an even more radical thought.

Instead of asking,

"How can we make AI software faster?"

Ask,

"How should electricity flow if its only job is intelligence?"

That sounds strange.

But remember...

Every computer is ultimately just controlled movement of electrons.

Voltage changes.

Current flows.

Tiny switches turning on and off.

We've accepted one particular way of organising those switches because history led us there.

But history isn't the same as perfection.

Perhaps there are entirely different electrical architectures that make AI dramatically more efficient.

Bigger Isn't Always Smarter

Today's AI race often looks like this:

More GPUs.

More memory.

More power.

More cost.

But biology tells a different story.

The human brain runs on roughly the power of a small light bulb.

Yet it performs extraordinary feats of perception, reasoning and learning.

Clearly, intelligence does not necessarily require enormous energy.

Maybe our approach does.

The Real Revolution May Not Be Another AI Model

The next breakthrough might not be:

A better Transformer
A larger language model
A trillion parameters

It might be a completely different computing architecture.

One where:

Memory and computation become the same thing.
Information doesn't constantly travel back and forth.
Hardware itself represents knowledge.
Physics performs part of the computation naturally.

Instead of forcing AI to adapt to computers...

...we finally build computers that adapt to AI.

Why Isn't Everyone Doing This?

Some researchers are.

Work is already underway in areas like:

Neuromorphic computing
Optical computing
Analogue AI chips
Compute-in-memory
Memristor-based hardware
New semiconductor materials

But replacing an entire computing ecosystem isn't easy.

The world has spent more than half a century refining today's hardware and software stack.

Creating a fundamentally new one requires breakthroughs in physics, materials science, computer architecture, manufacturing, algorithms and software—all at the same time.

The Next Computing Revolution

History shows that every major leap in computing came from changing the hardware.

Vacuum tubes became transistors.

Transistors became integrated circuits.

CPUs were joined by GPUs.

GPUs were joined by AI accelerators.

Perhaps the next step is even more radical.

A machine that isn't a "computer" in the traditional sense.

A machine whose sole purpose is intelligence.

Final Thought

For decades we've been asking:

"How do we make AI fit our computers?"

Maybe it's finally time to ask:

"How do we build computers that fit AI?"

The next trillion-dollar company may not build the smartest AI model.

It may build the first computer that truly understands what AI needs from the very first electron.

DEV Community: Sh Raj

MCP vs API: What's the Difference? A Visual Guide for Developers

MCP vs API: What's the Difference? A Visual Guide for Developers

1. First, what is an API?

How does a typical API request work?

2. The problem: APIs weren't designed specifically for AI tool interoperability

3. What is MCP?

The MCP architecture

MCP's three core primitives

4. MCP vs API: the fundamental difference

Side-by-side comparison

An analogy

5. A real example: building a GitHub issue assistant

Option A: Direct GitHub API integration

Option B: Expose the capability through MCP

The complete flow

6. Build a simple MCP server with TypeScript

Step 1: Install the SDK

Step 2: Create the server

What happens when the AI calls get_task?

7. When should you use MCP instead of a direct API integration?

Use a direct API integration when:

Consider MCP when:

The best production architecture may use both

8. Advanced considerations

8.1 Integration complexity

8.2 Latency and performance

8.3 Security is still your responsibility

9. Common misconceptions

10. Frequently asked questions

Is MCP an API?

Can I use MCP with a REST API?

Can I use APIs without MCP?

Is MCP the same as function calling?

Does MCP work with any AI model?

Is MCP useful for agentic AI?

11. Further reading

12. The final mental model

How Hackers Mod APKs: Android Reverse Engineering Explained

How Hackers Mod APKs: Inside Android Reverse Engineering, Runtime Analysis, and App Integrity

1. Introduction: The Endless Battle Over Modified APKs

The central security principle

2. Understanding the Android APK

2.1 From Java or Kotlin to executable Android code

2.2 DEX versus Smali

3. Static Analysis: Understanding an Application Without Running It

3.1 Why static analysis works

3.2 The danger of trusting local feature flags

3.3 Obfuscation is not encryption

4. Dynamic Analysis: Observing What Happens at Runtime

4.1 What runtime analysis can reveal

4.2 Ghidra, IDA Pro, and runtime instrumentation

4.3 Why runtime observation defeats some obfuscation strategies

5. Server-Side Validation: Moving Trust Away from the Device

5.1 The difference between authentication and authorization

5.2 Backend authority and entitlement checks

5.3 What server-side validation does not solve

6. Network Interception and Response Tampering

6.1 HTTPS changes the situation

6.2 Certificate validation and pinning

6.3 A safer mental model

7. Google Play Integrity: What It Does and Does Not Do

7.1 What the Play Integrity API actually provides

7.2 The backend is part of the design

7.3 Why a client-side integrity check is not enough

7.4 Can integrity checks be bypassed?

8. Why the Cycle Continues: A Layered Security Model

8.1 The economics of reverse engineering

9. A Defensive Architecture for Android Developers

Layer 1: Harden the application build

Layer 2: Keep authoritative state on the backend

Layer 3: Secure network communication

Layer 4: Integrate integrity signals

Layer 5: Detect and constrain abuse

Layer 6: Test the system, not only the APK

10. A Safe Reverse-Engineering Lab for Learners

Lab A: Inspect your own APK

Lab B: Observe runtime behavior

Lab C: Compare client-side and server-side authorization

Lab D: Evaluate integrity decisions

What happens when the AI calls `get_task`?

1. `Choice` — "Which one?"

2. `Score` — "How much?"

3. `Noul` — "Is this true?"