DEV Community: Sh Raj

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.

System Design Concepts Explained Simply: The Complete Beginner-to-Advanced Guide

Sh Raj — Sat, 18 Jul 2026 11:27:38 +0000

Absolutely. A single, polished Dev.to article like that is feasible.

I would structure it as a complete beginner-to-advanced handbook rather than just notes from the video.

Proposed Structure

Title

System Design Concepts Explained Simply: The Complete Beginner-to-Advanced Guide

Length

~15,000–20,000 words
35–45 sections
40+ Mermaid diagrams
Dev.to compatible Markdown
SEO optimized
Course-style explanations
Based on the video but significantly expanded with interview insights

Every topic would include

## What is it?

Simple explanation

Why do we need it?

Real-world example

How it works

Mermaid diagram

Advantages

Disadvantages

Interview questions

When to use it

Production examples

Topics

Introduction

What is System Design?
Why Software Engineers need it
Functional vs Non-functional requirements

Computer Fundamentals

CPU
RAM
Cache
SSD
HDD
Memory Hierarchy

Mermaid diagrams

Client-Server Architecture

graph LR
User --> Browser
Browser --> Internet
Internet --> Server
Server --> Database

DNS

sequenceDiagram
Browser->>DNS Resolver: example.com
Resolver->>Root Server: Query
Root->>TLD Server: .com
TLD->>Authoritative DNS
Authoritative DNS-->>Resolver
Resolver-->>Browser

TCP Handshake

sequenceDiagram
Client->>Server:SYN
Server->>Client:SYN ACK
Client->>Server:ACK

HTTP Request Lifecycle

flowchart LR
Browser
DNS
LoadBalancer
API
Database

Browser-->DNS
DNS-->LoadBalancer
LoadBalancer-->API
API-->Database
Database-->API
API-->Browser

REST APIs

GET
POST
PUT
DELETE

Mermaid request flow

GraphQL

Comparison with REST

Diagram

gRPC

Protocol Buffers

Architecture

WebSockets

Real-time communication

Sequence diagram

Reverse Proxy

NGINX

Cloudflare

Diagram

Load Balancer

Round Robin

Least Connections

IP Hash

Architecture

CDN

Cloudflare

Fastly

Akamai

Diagram

Caching

Browser Cache

Redis

Memory Cache

Database Cache

Cache Aside

Write Through

Write Back

Read Through

Each with Mermaid flowcharts.

SQL Databases

ACID

Normalization

Indexes

Transactions

Architecture

NoSQL

MongoDB

Redis

Cassandra

Document databases

Diagram

SQL vs NoSQL

Comparison table

Decision tree

Database Replication

Master

Replica

Failover

Diagram

Database Sharding

Horizontal partitioning

Diagram

CAP Theorem

Consistency

Availability

Partition Tolerance

Triangle illustration in Mermaid

Vertical Scaling

Diagram

Horizontal Scaling

Diagram

Message Queue

Kafka

RabbitMQ

SQS

Producer Consumer

Diagram

Event Driven Architecture

Diagram

CI/CD

GitHub

Tests

Docker

Deploy

Production

Pipeline diagram

Monitoring

Prometheus

Grafana

Sentry

Logs

Metrics

Tracing

Diagram

Complete Production Architecture

Browser
↓

Cloudflare
↓

Load Balancer
↓

NGINX
↓

API Servers
↓

Redis
↓

Kafka
↓

Database
↓

Replica

↓

S3

Converted into Mermaid.

TinyURL Design

Architecture

Database

Cache

Load Balancer

Diagram

Instagram Design

Diagram

WhatsApp Design

Diagram

YouTube Design

Diagram

Netflix Design

Diagram

Interview Cheat Sheet

Common questions

Tradeoffs

Red flags

Decision trees

Conclusion

Learning roadmap

Books

Free resources

Practice questions

Mermaid Diagrams Included

The article would contain approximately:

10 Flowcharts
8 Sequence diagrams
6 Architecture diagrams
5 State diagrams
4 Entity Relationship diagrams
5 GitGraph diagrams
3 Journey diagrams
3 Class diagrams
2 Mind maps

Total: around 45–50 Mermaid diagrams, all supported by Dev.to.

This would read like a free course, starting with computer fundamentals and progressing to real-world architectures, with each concept explained in simple language, accompanied by diagrams, production examples, and interview-focused insights rather than being just a transcript of the referenced video.

Best React UI Libraries Listed

Sh Raj — Tue, 30 Jun 2026 17:25:26 +0000

If you're using Next.js + Tailwind + shadcn/ui, here's what I'd consider the ultimate collection of UI resources in 2026.

🏆 S-Tier (Must Know)

Library	Best For
shadcn/ui	Foundation for almost every modern React app
ReUI	Dashboards, CRUD, Admin Panels
Magic UI	Animations, effects, hero sections
Aceternity UI	Landing pages & premium interactions
Cult UI	Apple-inspired components & AI apps
Kokonut UI	SaaS sections and polished blocks

⭐ A-Tier

Origin UI

https://originui.com

One of the cleanest shadcn-based libraries.

Contains

Forms
Authentication
Pricing
Tables
Dashboard components
Navigation
Empty states

Very underrated.

React Bits

https://reactbits.dev

Amazing animations.

Includes

Text Effects
Cursor Effects
Mouse Trails
Magnetic Buttons
Scroll Animations
Loading Animations
Interactive Cards

Perfect companion to Magic UI.

Motion Primitives

https://motion-primitives.com

Very underrated.

Beautiful components built with Motion.

Examples

Floating Dock
Spotlight
Cursor
Hero Sections
Reveal Animations

Animate UI

https://animate-ui.com

Focuses on animation-first components.

Great replacement for writing custom Motion code.

21st.dev

https://21st.dev

Probably one of the coolest discoveries.

Think of it as

GitHub for UI Components

Features

Thousands of community components
AI search
Copy/Paste
shadcn compatible
React compatible

Tailark

https://tailark.com

Premium-looking Tailwind landing page blocks.

Very underrated.

Preline UI

https://preline.co

Excellent for

Dashboards
Tables
Forms
Enterprise Apps

Lots of production-ready components.

HyperUI

https://www.hyperui.dev

Huge collection of

Tailwind Components
Marketing Pages
Ecommerce
Dashboards

Pure Tailwind.

Very lightweight.

Sailboat UI

https://sailboatui.com

Lots of beautiful Tailwind components.

Very clean styling.

Underrated. (GreatFrontEnd)

Flowbite

https://flowbite.com

Great for

Enterprise
Dashboards
Admin
Charts
Components
Templates

Huge ecosystem. (Flowbite)

🎨 Inspiration Libraries

Components.work

Directory of UI libraries.

UI Layouts

https://uilayouts.dev

Landing page inspiration.

Landbook

https://land-book.com

Best landing page inspiration.

Lapa Ninja

https://www.lapa.ninja

Thousands of startup websites.

Godly

https://godly.website

Award-winning websites.

Mobbin

https://mobbin.com

Mobile UI inspiration.

Refero

https://refero.design

Web UI inspiration.

SaaSFrame

https://www.saasframe.io

SaaS landing pages.

🎭 Background / Effects

Magic UI
Aceternity UI
Ali Imam Components
React Bits
Motion Primitives

These together cover almost every modern visual effect.

🧩 Icons

Lucide
Tabler Icons
Heroicons
Phosphor Icons
Remix Icons

📊 Charts

Tremor
Recharts
Nivo
Visx

🎯 If I could only bookmark 20 websites

shadcn/ui
ReUI
Magic UI
Aceternity UI
Cult UI
Kokonut UI
Origin UI
React Bits
Motion Primitives
Animate UI
21st.dev
Tailark
Preline UI
HyperUI
Flowbite
Components.work
Mobbin
Landbook
Refero
SaaSFrame

This collection covers virtually everything needed for modern React/Next.js development: production-ready components, dashboards, marketing blocks, advanced animations, design inspiration, icons, and data visualization. Many of these libraries are widely used alongside shadcn/ui, while tools like Magic UI, Aceternity UI, ReUI, and 21st.dev have become especially popular in the current React ecosystem. (adminlte.io)

DEV Community: Sh Raj

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

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

What I Built

Example

The Problem With Normal Search

Why Sanity?

How I Used Sanity

1. I modeled the campus as connected content

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

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

A Question That Breaks Keyword Search

The Agent's Answer

🔍 The "Why?" Button

🧠 Handling Conflicting Information

🛠️ Architecture

💻 The Data Model

🔗 Why References Matter

Flat content

Structured content

🤖 Agent Loop

🚦 Guardrails

🧪 How I Tested It

Level 1 — Direct lookup

Level 2 — Filtering

Level 3 — Multi-constraint

Level 4 — Relationship reasoning

Level 5 — Real-world ambiguity

Level 6 — Conflict handling

📈 What I Measure

🔥 The coolest use case

🎬 Demo

💻 Code

🧩 How I Used Sanity Context

🗂️ Sanity Project Details

🧾 Agent Session

🧠 What I Learned

⚔️ Why this is more than RAG

🌐 What I Want to Build Next

🏁 Final Takeaway

🔗 Links

📚 References

sanitychallenge #agents #ai #webdev

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

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

🧠 The core idea

What is a "System One" model?

The three primitives

1. Choice — "Which one?"

2. Score — "How much?"

3. Noul — "Is this true?"

🤯 Why this is interesting

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

⚡ Why the speed matters

🏗️ The architecture I find most interesting

🔀 A hybrid AI agent

🧪 A real benchmark question

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

📊 What I would measure

🔬 There is already evidence worth looking at

🧩 The hidden superpower: probabilities

🧠 And this changes how prompts should be written

🔥 This is where Jev gets weirdly interesting

🧱 The big limitation

⚠️ "Zero hallucinations" needs a careful interpretation

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

🧪 The counterfactual test

🛠️ Building a Jev benchmark on Kaggle

💻 A tiny Jev API example

🚀 Where I think this could matter

🤖 AI agents

📬 Email

🧑‍💻 Developer tooling

🛡️ Safety & guardrails

🔎 Retrieval systems

⚡ Real-time applications

The bigger idea

🏁 Final takeaway

🔬 Benchmark

📚 Further reading

1. `Choice` — "Which one?"

2. `Score` — "How much?"

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