DEV Community: Sh Raj

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)

Why Hand-Drawn Portfolios Are Making a Comeback in 2026 ✏️

Sh Raj — Tue, 23 Jun 2026 19:25:09 +0000

Why Hand-Drawn Portfolios Are Making a Comeback in 2026 ✏️

For years, the web has been obsessed with the same design trends:

Glassmorphism
Dark mode
SaaS-style landing pages
Minimal portfolios

The result?

Most portfolios look nearly identical.

That's why hand-drawn and illustrated websites are becoming increasingly popular again.

They feel personal.

They feel memorable.

And most importantly—they don't look like everyone else's website.

The Problem With Modern Portfolios

Recruiters, clients, and visitors browse hundreds of portfolios every month.

Most are forgotten within seconds.

Not because the work is bad.

Because nothing stands out.

A portfolio should communicate personality before visitors even start reading.

That's exactly where illustrated designs shine.

Meet Kraft — Premium 3D Hand Drawn Portfolio Theme

Kraft combines modern web design with handcrafted illustrations and 3D elements to create a portfolio that instantly feels unique.

Instead of another generic template, visitors experience a creative environment that feels designed specifically for a human, not generated from a design trend.

Why Hand-Drawn Design Works

Hand-drawn interfaces create something most websites lack:

Personality

People remember things that feel human.

Illustrations naturally create emotional connection and curiosity.

Memorability

A unique visual style helps visitors remember your portfolio long after they leave.

Better Branding

Your portfolio becomes more than a project showcase.

It becomes part of your personal brand.

// Detect dark theme var iframe = document.getElementById('tweet-2069502994731995442-310'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2069502994731995442&theme=dark" }

Perfect For

This theme works exceptionally well for:

🎨 Designers

💻 Developers

🚀 Startup Founders

✍️ Creators

🎬 Content Creators

📸 Freelancers

🎓 Students Building Their First Portfolio

If your goal is standing out rather than blending in, this style can make a huge difference.

Features

✅ Premium hand-drawn design

✅ Modern 3D visual elements

✅ Smooth animations

✅ Mobile responsive

✅ Fast loading

✅ Professional layout

✅ Easy customization

✅ Unique visual identity

First Impressions Matter

Most visitors decide whether to continue exploring a website within a few seconds.

A memorable design buys attention.

Attention creates engagement.

Engagement creates opportunities.

Whether you're looking for clients, internships, freelance work, or a full-time role, your portfolio is often your first impression.

Make it count.

Live Preview

🎥 Full Website Walkthrough - https://kraft-portfolio-theme.surge.sh/

📸 Additional Screenshots

Get Kraft

If you're tired of generic portfolio templates and want something that actually feels creative, check out Kraft Premium 3D Hand Drawn Portfolio Theme.

👉 https://scriptly.store/products/kraft-premium-3d-hand-drawn-portfolio-theme

The best portfolio isn't always the most complex.

It's the one people remember.

Stop Building Boring Portfolios: This Scroll-Driven Travel Portfolio Changes Everything 🌍

Sh Raj — Tue, 23 Jun 2026 19:19:17 +0000

Stop Building Boring Portfolios: This Scroll-Driven Travel Portfolio Changes Everything 🌍

// Detect dark theme var iframe = document.getElementById('tweet-2069503536296296815-946'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2069503536296296815&theme=dark" }

Most portfolios look identical.

A hero section.
A projects section.
A contact form.

And that's it.

In a world where everyone is competing for attention, a portfolio should be more than a collection of links—it should be an experience.

What Makes This Portfolio Different?

The Panda Scroll Travel Animation Portfolio transforms a simple portfolio into an interactive journey.

As visitors scroll, the website comes alive with immersive animations, smooth transitions, and storytelling-inspired effects that keep users engaged from start to finish.

Instead of simply showing your work, it helps you present it in a way people actually remember.

Why Scroll-Based Storytelling Works

Modern websites from top brands often use scroll-driven storytelling because it naturally captures attention.

Benefits include:

Higher visitor engagement
Longer session duration
Better first impressions
More memorable personal branding
Premium visual appeal

When content unfolds as users scroll, curiosity keeps them moving forward.

Perfect For

This template is ideal for:

Developers
Designers
Freelancers
Creative agencies
Travel creators
Students building a personal brand
Anyone wanting a premium portfolio

Whether you're applying for internships, freelancing clients, or showcasing personal projects, a unique portfolio can help you stand out.

Features

✅ Stunning scroll animations

✅ Smooth storytelling experience

✅ Modern premium design

✅ Mobile responsive

✅ Fast loading

✅ Easy customization

✅ Clean code structure

![Feature Showcase Screenshot Here]

Why Buy Instead of Building?

Creating a polished scroll-animation website from scratch requires:

Animation expertise
Design skills
Hours of tweaking
Performance optimization

This template lets you skip weeks of work and launch much faster.

Simply customize the content, add your projects, and make it your own.

Live Demo

🎥 GIF Preview

📸 Screenshots

Get The Template

If you're looking for a portfolio that actually leaves an impression, check out the Panda Scroll Travel Animation Portfolio.

👉 https://scriptly.store/products/panda-scroll-travel-animation-portfolio

A portfolio isn't just where you display your work.

It's often the first impression people have of you.

Make it memorable.

Can You Beat Alan Turing? A Solstice-Themed Psychological Deduction Game

Sh Raj — Fri, 19 Jun 2026 20:02:18 +0000

Can You Beat Alan Turing? A Solstice-Themed Psychological Deduction Game

Submission for the June Solstice Game Jam
Categories: Best Google AI Usage, Best Ode to Alan Turing

Have you ever wondered if the person you're talking to on the internet is real? In 1950, Alan Turing asked the same question.

For this Game Jam, I wanted to build something that wasn't just a traditional 2D platformer, but a psychological thriller disguised as a chat interface.

Welcome to "Can You Beat Alan Turing?" — a modern, browser-based reimagining of the Turing Test wrapped in the atmospheric metaphors of the June Solstice.

Play the Game

Play it Live Here
(Note: Headphones recommended for focus. The clock is ticking!)

🌓 The Concept: Turing Meets the Solstice

In this game, you are placed in a verification terminal. The Solstice Dial sits at the top of your screen, representing 10 available transmissions (questions). You must interrogate three distinct "character nodes" and guess which ones are human, and which are highly advanced AI.

I wove the themes of the June Solstice and Alan Turing directly into the game mechanics and UI:

The Metaphor of Light: Sunlight represents logical certainty; shadows represent doubt. The game's UI uses Framer Motion to slowly fade from a bright, golden amber (Zenith) into a deep twilight indigo as you use up your transmissions.
The Solstice Dial: The countdown isn't a timer, it's a sun cycle. You only have 10 transmissions before the sun sets and you must submit your final verdict.
The Bletchley Park Tribute: One of the characters you can interrogate, Arthur Pendelton, is a retired cryptanalyst—a direct nod to Turing's monumental work at Bletchley Park. The other characters also reference Turing's philosophies on logic vs. emotion in their hidden dialogue.

🤖 Best Google AI Usage: "Cognitive Signature Analysis"

This game isn't just a static chat app. It uses the Gemini 1.5 Flash API to drive the core gameplay loop.

Instead of just hooking up an LLM to a chat box, I used Gemini to create strict behavioral profiles. I prompt Gemini to act either as a human with specific flaws (complaining about heat, making typos) or an AI trying too hard to sound human (using overly precise mathematical syntax, avoiding contractions).

The Signature Analysis Tool
If you get stuck, you can spend 2 of your precious 10 transmissions to use the Cognitive Signature Analysis tool. This sends the entire chat history back to Gemini with a highly specific meta-prompt: "Analyze this transcript and give a cryptic, poetic hint about whether the entity shows signs of a beating heart or silicon perfection."

It's a "hint" system powered entirely by real-time LLM analysis of your own unique conversation!

(Note: If the API goes offline, I built a custom local "Simulator Mode" fallback that uses regex-based keyword parsing so the game is always 100% playable for the judges).

🛠️ The Tech Stack

I built this over the weekend using a modern web stack aimed at maximum visual polish and edge performance:

Next.js 14 (App Router) & React: For the core state machine and UI rendering.
Tailwind CSS v4: Extensive use of custom glassmorphism, glowing amber/indigo borders, and CRT scanline overlays to create a "retro-futuristic terminal" vibe.
Framer Motion: Smooth page transitions and UI micro-interactions.
Cloudflare Pages: The entire app, including the Gemini AI edge routes (/api/chat and /api/analyze), is deployed on Cloudflare Pages for instant global response times.
Canvas Confetti: Because every game needs a reward for winning!

🐛 Challenges Faced

The biggest challenge was "taming" the LLM. Gemini is so smart that it's actually hard to make it sound like a flawed, tired human barista (one of the characters). I spent hours tuning the system prompts. For example, to make the AI character have a "tell", I specifically instructed Gemini: "You are an AI pretending to be a human. Your tell is that you NEVER use contractions and you accidentally use structural parallelism in your sentences."

Getting the UI to feel "alive" was also tricky. Implementing the custom text-scramble decryption effect for incoming AI messages really added that final layer of polish that makes it feel like a premium game rather than a web app.

🏁 Final Thoughts

Building this was an incredible experience. It really made me think about Turing's original 1950 paper. If we can build an AI that can convincingly complain about the summer heat and a sore back... have they passed the test?

I hope you enjoy interrogating these characters as much as I enjoyed building them!

GitHub Repo:

SH20RAJ / beat-alan-turing

A polished, atmospheric browser-based deduction game built for the June Solstice Game Jam 2026. This project serves as a double submission for the Best Google AI Usage and Best Ode to Alan Turing prize categories.

Can You Beat Alan Turing?

A polished, atmospheric browser-based deduction game built for the June Solstice Game Jam. This project serves as a double submission for the Best Google AI Usage and Best Ode to Alan Turing prize categories.

The core gameplay centers around a modern reimagining of the classic Turing Test, framed through the visual and narrative metaphors of the June Solstice (light vs. shadow, certainty vs. doubt, cycles).

🌓 The Concept & Jam Themes

1. Best Ode to Alan Turing

In 1950, Alan Turing famously proposed the "Imitation Game" (now known as the Turing Test) as a practical answer to the question "Can machines think?".

The Gameplay: You enter a verification chamber where you must communicate with three different mind nodes. Your task is to interrogate them, search for cognitive flaws, and guess who is human and who is AI.
The Tribute: The game features…

View on GitHub

My Failed Attempt

/You must play it with sound on./

Happy Solstice, and happy interrogating!

How I Freed 50GB of Disk Space Using a Git Trick You’ve Never Heard Of

Sh Raj — Fri, 19 Jun 2026 11:23:25 +0000

How I Freed 50GB of Disk Space Using a Git Trick You’ve Never Heard Of

Are your local ~/Downloads, ~/Desktop, or ~/Documents folders slowly drowning under a mountain of screenshots, screen recordings, zoom logs, and random design mockups?

If you are like most developers, designers, or technical writers, you probably have gigabytes of screen recordings and screenshots cluttering your local disk. You need to keep them for future reference, but they are eating away at your SSD, slowing down your system, and making backups a nightmare.

You could buy iCloud or Google Drive storage. Or you could use this insane Git workflow that stores your files permanently on GitHub, keeps them fully browsable on the web, but consumes exactly 0 bytes of your local storage.

In this deep-dive article, we will show you how to set up a permanent, automated media vault on GitHub using Git Sparse-Checkout and Git LFS (Large File Storage)—and provide a complete automation script and "Skill" file so your AI coding assistants can run it for you!

The Problem: The Standard Backup Trap

Usually, backing up files to GitHub means:

Pushing the files.
Keeping them locally.

If you delete them locally and commit the deletion, they disappear from GitHub's main directory browser. If you don't commit the deletion, your local working tree is dirty forever, and git status screams at you with hundreds of red lines:

Changes not staged for commit:
  deleted:    Screenshot 2026-04-12 at 5.32.00 PM.png
  deleted:    Screen Recording 2026-04-13 at 10.00.04 PM.mov
  ...

Is there a way to keep them on GitHub but free up local space while keeping your git status clean?

Yes. It's called Git Sparse-Checkout.

🚀 The Secret Weapon: Git Sparse-Checkout

Sparse-checkout is a native Git feature designed for giant monorepos. It allows you to tell Git: "Keep these files committed in the remote repository history, but do not physically download or extract them to my local machine."

Combine this with Git LFS for large video files, and you have a free, infinite, automated cloud storage locker.

🛠️ Step-by-Step Implementation Guide

Let's walk through how to build this system from scratch.

Step 1: Initialize Git and Setup LFS (Large File Storage)

If you have large recordings (over 100MB), standard GitHub commits will reject them due to GitHub's file size limits. We'll set up Git LFS first.

Open your terminal in your media folder (e.g. ~/Documents) and run:

# 1. Install Git LFS (on macOS)
brew install git-lfs

# 2. Initialize LFS in your folder
git lfs install

# 3. Track heavy video formats with LFS
git lfs track "*.mov"
git lfs track "*.mp4"

# 4. Commit LFS configurations
git add .gitattributes
git commit -m "setup: track video formats via LFS"

Step 2: Configure Sparse-Checkout (Exclusion Patterns)

Now, we set up the exclusion rules. We want to tell Git to exclude the folders where we store our images and videos locally, but keep the index, readme, and scripts checked out.

# 1. Enable sparse-checkout in non-cone (custom pattern) mode
git sparse-checkout init --no-cone

# 2. Set the exclusion rules in Git's sparse config
echo '/*
!/images/
!/videos/' > .git/info/sparse-checkout

# 3. Apply the rules
git sparse-checkout reapply

What does this pattern mean?

/* checks out all files at the root level (like README.md, INDEX.md, backup.sh).
!/images/ and !/videos/ tells Git never to check out or keep the images or videos directories on your local drive.

Any existing files matching these directories will be deleted instantly from your local disk, but remain safe on GitHub!

🤖 Step 3: Automate It (The One-Click Script)

To make this effortless, here is a bash script (backup.sh) that automates the entire flow:

Scans the root directory for new screenshots or videos.
Moves them automatically into folders organized by date and type (images/YYYY-MM/ and videos/YYYY-MM/).
Commits and pushes them to GitHub.
Grabs the full 40-character commit SHA (important to avoid raw usercontent 404s).
Rebuilds a markdown catalog (INDEX.md) listing download URLs.
Reapplies the sparse-checkout rules to wipe the local files and reclaim your disk space!

Here is the script backup.sh:

#!/usr/bin/env bash
# backup.sh - Automatically organize, backup new screenshots/videos to subfolders, update INDEX.md, push to GitHub, and clean up local space.

set -e

REPO_URL="https://raw.githubusercontent.com/YOUR_USERNAME/YOUR_REPO"
INDEX_FILE="INDEX.md"
BRANCH="main"

echo "🔍 Scanning for new media files to back up..."

# Find new untracked/modified media files at root or inside subdirs
NEW_FILES=()
while IFS= read -r -d '' file; do
    relative="${file#./}"
    if [[ "$relative" =~ \.(png|jpg|jpeg|mov|mp4)$ ]]; then
        NEW_FILES+=("$relative")
    fi
done < <(git status --porcelain -z | grep -z -E '^\?\?|^ M' | cut -z -c4- | sort -z)

TOTAL=${#NEW_FILES[@]}

if [ "$TOTAL" -eq 0 ]; then
    echo "✅ No new media files found to back up."
    exit 0
fi

echo "📊 Found $TOTAL new files to process."

# Move files to date-based folders if they are at the root level
MOVED_FILES=()
for f in "${NEW_FILES[@]}"; do
    if [[ ! "$f" == *"/"* ]]; then
        # Parse date from name or default to current year-month
        if [[ "$f" =~ [0-9]{4}-[0-9]{2}-[0-9]{2} ]]; then
            DATE_STR="${BASH_REMATCH[0]}"
            YM="${DATE_STR:0:7}" # YYYY-MM
        else
            YM=$(date '+%Y-%m') # Fallback to current year-month
        fi

        if [[ "$f" =~ \.(png|jpg|jpeg)$ ]]; then
            dest_dir="images/$YM"
        else
            dest_dir="videos/$YM"
        fi

        mkdir -p "$dest_dir"
        dest_path="$dest_dir/$f"
        echo "📂 Moving root file: $f -> $dest_path"
        mv "$f" "$dest_path"
        git add "$dest_path"
        MOVED_FILES+=("$dest_path")
    else
        git add "$f"
        MOVED_FILES+=("$f")
    fi
done

# Commit and Push the files first to get the commit SHA
echo "💾 Committing new organized files..."
git commit -m "backup: add $TOTAL new files organized by date"
echo "🚀 Pushing files to GitHub..."
git push origin "$BRANCH"

# Get the full 40-character commit SHA
COMMIT_SHA=$(git rev-parse HEAD)
echo "✅ Pushed successfully! Commit: $COMMIT_SHA"

# Rebuild INDEX.md using Python to keep it clean and ordered
echo "📝 Rebuilding INDEX.md..."
python3 -c "
import os
import urllib.parse
from datetime import datetime

repo_url_base = '${REPO_URL}/${COMMIT_SHA}'
index_file_path = '${INDEX_FILE}'

def get_human_size(path):
    try:
        size = os.path.getsize(path)
        if size >= 1073741824:
            return f'{size / 1073741824:.1f} GB'
        elif size >= 1048576:
            return f'{size / 1048576:.1f} MB'
        elif size >= 1024:
            return f'{size / 1024:.1f} KB'
        else:
            return f'{size} B'
    except Exception:
        return 'Unknown'

# Collect images
images = []
for root, dirs, files in os.walk('images'):
    for f in files:
        if f.endswith('.png'):
            relative_path = os.path.join(root, f)
            images.append(relative_path)
images.sort()

# Collect videos
videos = []
for root, dirs, files in os.walk('videos'):
    for f in files:
        if f.endswith('.mov') or f.endswith('.mp4'):
            relative_path = os.path.join(root, f)
            videos.append(relative_path)
videos.sort()

# Read the first commit SHA for other files
first_sha = os.popen('git log --oneline | tail -1 | cut -d\" \" -f1').read().strip()

with open(index_file_path, 'w') as f_obj:
    f_obj.write('# 📁 Documents Index\n\n')
    f_obj.write('> Auto-generated index of all files backed up to this repository.\n')
    f_obj.write('> Use the Raw URL to download any file, even after local deletion.\n')
    f_obj.write(f'> Generated on: {datetime.now().strftime(\"%Y-%m-%d %H:%M:%S\")}\n\n')

    f_obj.write('## 🖼️ Images (PNG Screenshots)\n\n')
    f_obj.write('| # | File | Size | Commit | Raw URL |\n')
    f_obj.write('|---|------|------|--------|---------|\n')
    for idx, path in enumerate(images, 1):
        size = get_human_size(path)
        encoded = urllib.parse.quote(path, safe='/')
        f_obj.write(f'| {idx} | `{path}` | {size} | `{COMMIT_SHA[:7]}` | [Download]({repo_url_base}/{encoded}) |\n')

    f_obj.write('\n## 🎥 Videos (Screen Recordings)\n\n')
    f_obj.write('| # | File | Size | Commit | Raw URL |\n')
    f_obj.write('|---|------|------|--------|---------|\n')
    for idx, path in enumerate(videos, 1):
        size = get_human_size(path)
        encoded = urllib.parse.quote(path, safe='/')
        f_obj.write(f'| {idx} | `{path}` | {size} | `{COMMIT_SHA[:7]}` | [Download]({repo_url_base}/{encoded}) |\n')

    f_obj.write('\n## 📄 Other Files\n\n')
    f_obj.write('| # | File | Size | Commit | Raw URL |\n')
    f_obj.write('|---|------|------|--------|---------|\n')
    f_obj.write(f'| 1 | `hls-video.excalidraw` | {get_human_size(\"hls-video.excalidraw\")} | `{first_sha}` | [Download]({repo_url_base}/hls-video.excalidraw) |\n')
"

# Commit and Push INDEX.md
git add "$INDEX_FILE"
git commit -m "index: update INDEX.md with new backup file mappings"
git push origin "$BRANCH"

# Reapply sparse checkout to reclaim local disk space
echo "🧹 Reclaiming local disk space (running sparse-checkout)..."
git sparse-checkout reapply

echo "🎉 Backup complete! Local space is cleared, and files are safe on GitHub."

Make it executable:

chmod +x backup.sh

🤖 Step 4: The AI Assistant "Skill" File

If you are using AI agents (like Claude, Gemini, or Copilot) to help you develop, they can automate this backup system completely. By checking in a Skill Markdown file to your repository, future agents will immediately understand the repository rules and can safely execute the backups for you!

Here is the exact backup.skill.md file you should add to the repository:

# Skill: Organized Documents Backup and Space Reclaiming

This skill provides instructions for AI coding agents to back up new screenshots, screen recordings, and media files from the local computer to the GitHub repository using Git LFS and Git Sparse-Checkout, keeping files organized by date and type.

## 📁 Repository Directory Structure

Files are organized in folders automatically by date and type:
* `/images/YYYY-MM/` — Screenshot PNGs grouped by month
* `/videos/YYYY-MM/` — Screen Recording MOVs and MP4s grouped by month

---

## 🛠️ How to Back Up New Files (Agent Flow)

If the user drops new files into the folder, you should run the automated script.

### Option A: Automated (Recommended)
Run the backup script directly:

bash
./backup.sh

This script will:
1. Detect any untracked or modified images/videos.
2. Automatically parse dates from filenames (e.g. `2026-04-12`) and move them to their respective `images/YYYY-MM/` or `videos/YYYY-MM/` subdirectory.
3. Stage, commit, and push them to GitHub.
4. Fetch the **full 40-character commit SHA** (required for raw GitHub usercontent links to prevent 404s).
5. Rebuild `INDEX.md` using python to catalog all files with their paths, sizes, and direct raw download links.
6. Commit and push the updated `INDEX.md`.
7. Run `git sparse-checkout reapply` to clean up the local disk.

### Option B: Manual Execution
If the script needs debugging or you want to run it manually:

1. **Move files into directories**:

bash
mkdir -p images/YYYY-MM
git mv "Screenshot YYYY-MM-DD ...png" images/YYYY-MM/

2. **Stage and commit the new files**:

bash
git commit -m "backup: add new files"
git push origin main

3. **Retrieve the full commit SHA**:

bash
COMMIT_SHA=$(git rev-parse HEAD)

4. **Format entry for INDEX.md**:
   Add rows to `INDEX.md` under the appropriate table header:

markdown
| # | File | Size | Commit | Raw URL |
|---|------|------|--------|---------|
| [Index] | images/YYYY-MM/[Filename] | [Size MB] MB | [Commit SHA] | Download |

5. **Push INDEX.md**:

bash
git add INDEX.md
git commit -m "index: update entries"
git push origin main

6. **Reapply sparse checkout to delete local files**:

bash
git sparse-checkout reapply


---

## 📥 How to Restore a File for the User

If the user requests to restore one or more files to their computer:
1. Locate the file in `INDEX.md` to get its path.
2. Tell Git to stop skipping the file:

bash
git sparse-checkout add "images/YYYY-MM/filename.png"

   *Note: This will immediately download the file from GitHub to the local directory.*
3. To exclude it again after use:

bash
git sparse-checkout reapply

shell

💡 How This Helps You: 5 Real-World Benefits

1. Zero Disk Usage

The main benefit. Your local project folders stay incredibly clean and compact, preserving your SSD life and leaving space for active coding projects.

2. Fully Browsable on GitHub

Unlike standard backup archives (like .zip or .tar), your files aren't locked away in a compressed format. You can click through /images/2026-06/ on GitHub's website and browse them instantly.

3. Bulletproof, Unbreakable Links

By pointing the download URLs in INDEX.md to the full commit SHA (/Documents/a2b2ed5a43.../images/file.png) instead of /main/, these links will work forever. Even if you delete or modify the files on the main branch later to clean up remote storage, the historical commit raw URLs remain functional.

4. Zero Maintenance for Future Assistant Agents

If you use coding agents, you can check in the backup.skill.md file. Future agents entering your workspace will automatically understand how to restore files or perform backups without you having to guide them.

5. Restore Files Instantly

Need a file back? You don't have to download it from a web browser. Just tell Git to stop skipping it:

git sparse-checkout add "images/2026-04/screenshot.png"

Git will instantly fetch it from GitHub and drop it back into your local folder. Once you are done, run:

git sparse-checkout reapply

And it disappears from your disk again!

⚡ Conclusion

Stop letting screenshots and screen recordings choke your machine's performance. Git was built to track changes, but with Sparse-Checkout, it becomes a premium, automated, zero-local-footprint cloud drive.

Have you ever used sparse checkout? Let me know in the comments how you manage local file clutter!