DEV Community: Kumar Kislay

How JEV Works: The AI That Decides Instead of Chatting

Kumar Kislay — Sat, 26 Sep 2026 13:01:50 +0000

Introduction: Meet JEV, the Model That Stopped Talking

Picture this.

You walk into a restaurant, and instead of a chatty waiter who tells you the entire history of every dish, explains every ingredient, shares the chef's grandmother's recipe, and gives you their personal opinion about truffle oil, you get a silent maître d' who simply points to the best option and gives you a confidence score.

That, in a nutshell, is JEV.

JEV, sometimes stylized as "Jev," is not your typical AI model. It does not write essays. It does not compose poetry. It will not help you draft a breakup text, although that might honestly be for the best.

What JEV does is make decisions.

Fast, cheap, typed decisions with calibrated probabilities.

Think of it as an extremely opinionated spreadsheet that actually understands context.

Released in early access on September 15, 2026, by TypeSafe AI, JEV arrived with $40 million in seed funding and a notable AI research pedigree. Its founder, Diogo Almeida, is a former OpenAI researcher credited as a co-inventor of RLHF, or Reinforcement Learning from Human Feedback, the technique that helped turn raw language models into the helpful assistants we know today.

The name "JEV" comes from William Stanley Jevons, a 19th-century economist famous for the Jevons paradox. The paradox describes how making resource use more efficient can sometimes lead to greater overall consumption.

TypeSafe essentially made a similar bet with AI.

If AI decisions become radically cheaper and faster, people may start using AI for decisions they previously considered too expensive or impractical to automate.

It is a clever name. Although "William Stanley" would have been considerably funnier.

Within 24 hours of launch, JEV reportedly saw adoption from a significant percentage of paid Vercel AI Gateway teams. There were also reports of TypeSafe discussing a major funding round at a multibillion-dollar valuation shortly after launch.

The hype was real.

The memes were arguably better.

What JEV Actually Does

The "No-Text" Revolution

The Core Concept: System One Thinking

TypeSafe describes JEV as a "System One Model," borrowing terminology from psychologist Daniel Kahneman's framework in Thinking, Fast and Slow.

Kahneman describes two broad styles of thinking:

System 1 is fast, intuitive, automatic, and reactive.

System 2 is slower, deliberate, analytical, and reasoning-heavy.

Traditional LLMs such as GPT and Claude are fundamentally built around generating sequences of tokens. Even when the final answer is simply "yes" or "no," the model still operates through the machinery of language generation.

JEV takes a different approach.

It does not need to generate a paragraph explaining its reasoning before producing an answer.

Instead, it looks at a situation and produces a structured decision in a single forward pass.

A Simple Example

Imagine you are running a customer support system.

A traditional LLM workflow might look like this:

Receive a support ticket.
Send the ticket to the LLM.
Ask what should happen with the ticket.
The LLM generates a detailed explanation about the customer's tone, product category, severity, and possible solutions.
Your application then extracts the actual decision from that response.
The ticket gets routed to the appropriate department.

With JEV, the workflow can be much simpler:

Receive the support ticket.
Send JEV the ticket and one typed question: "Which department should handle this? Billing, sales, or technical?"
JEV returns a structured result such as:

{
  "choice": "billing",
  "confidence": 0.87,
  "probabilities": {
    "billing": 0.87,
    "sales": 0,
    "technical": 0.13
  }
}

Your application routes the ticket.

Done.

There is no generated essay to parse. There is no unexpected markdown. There is no need to extract a decision from a paragraph of text.

The Three Decision Types

JEV answers questions using three primary formats.

That constraint is the entire point.

1. Choice

Choice questions ask the model to select one option from a predefined list.

For example:

Is this ticket about billing, sales, or technical support?

JEV returns the selected option along with probabilities for the possible choices.

This is useful for:

Classification
Routing
Categorization
Tool selection
Model routing
Workflow decisions

2. Score

Score questions ask the model to evaluate something on an ordinal scale.

For example:

How frustrated is this customer on a scale from 0 to 2?

Where:

0 = Calm
1 = Frustrated
2 = Very angry

JEV returns a score along with confidence information.

This makes it useful for:

Severity assessment
Risk scoring
Priority assignment
Sentiment estimation
Quality evaluation

3. Noul

Noul is a calibrated yes or no probability.

For example:

Is this refund request eligible for automatic approval?

Instead of simply returning yes or no, JEV can return a probability between 0 and 1.

For example:

{
  "noul": 0.95
}

This means the model estimates a 95% probability for the requested outcome.

The important distinction is that JEV does not just give you a binary answer. It gives you a measurable degree of confidence.

Why Typed Outputs Matter

One of JEV's most important characteristics is that its outputs are typed.

Traditional LLM applications often have to deal with problems such as:

Invalid JSON
Missing fields
Unexpected keys
Markdown appearing where JSON was expected
Text appearing instead of a structured value
The model changing the requested format

JEV is designed around a constrained output system.

A Choice question produces a Choice.

A Score question produces a Score.

A Noul question produces a Noul probability.

The model cannot suddenly decide that a Choice question should return a poem.

This makes JEV particularly interesting for software systems where AI decisions need to feed directly into deterministic application logic.

The Input Format: State + Questions

Using JEV is conceptually simple.

You provide two main things:

State

The state contains the context the model should evaluate.

This could be:

A support ticket
A user profile
A log entry
A piece of code
A document
A medical record
A JSON object
Unstructured text

The state can contain up to 32,000 tokens.

Think of the state as the evidence.

Questions

Questions tell JEV what decisions you want it to make about that evidence.

Each question specifies:

The question type
The available choices or scale
The description of what should be evaluated

Multiple questions can be evaluated against the same state.

For example, suppose you have a customer support ticket:

{
  "ticket": {
    "subject": "Duplicate charge",
    "message": "I was charged twice for order A-104. Please help."
  }
}

You could ask three questions at once:

{
  "is_urgent": {
    "type": "noul",
    "description": "Does this require immediate attention?"
  },
  "department": {
    "type": "choice",
    "options": [
      "billing",
      "sales",
      "technical"
    ]
  },
  "frustration": {
    "type": "score",
    "scale": {
      "0": "Calm",
      "1": "Frustrated",
      "2": "Very angry"
    }
  }
}

JEV might return something like:

{
  "is_urgent": {
    "type": "noul",
    "noul": 0.95
  },
  "department": {
    "type": "choice",
    "choice": "billing",
    "confidence": 0.87,
    "probabilities": {
      "billing": 0.87,
      "sales": 0,
      "technical": 0.13
    }
  },
  "frustration": {
    "type": "score",
    "score": 1.04,
    "confidence": 0.94,
    "probabilities": {
      "0": 0,
      "1": 0.96,
      "2": 0.04
    }
  }
}

Notice what happened.

Three different decisions were evaluated in a single call.

This is important because JEV evaluates multiple questions in parallel rather than requiring separate model calls for each question.

That means you can build a complete decision profile around a piece of information without repeatedly sending the same state through the model.

How JEV Works Under the Hood

The Architecture: Skipping Autoregression

This is where things become technically interesting.

Traditional LLMs are autoregressive.

They generate text one token at a time.

For example:

"The cat sat on the..."

The model predicts:

"mat"

Then the sequence becomes:

"The cat sat on the mat..."

The model then predicts the next token.

This process continues until the response is complete.

That sequential generation is one of the reasons LLMs can be relatively slow for simple tasks.

Even if you only need the answer "yes," the underlying model is still designed around language generation.

JEV takes a different approach.

TypeSafe describes its architecture as using a parallel sampler.

The model reads the state and produces its decisions in a single forward pass.

There is no token-by-token generation of an explanation.

There is no need to produce a chain of text before arriving at the final decision.

The output is the decision itself.

What We Know About the Architecture

TypeSafe has not publicly released every detail of JEV's architecture, weights, or training process.

The company describes JEV as transformer-based and trained using synthetic data.

That means there is still a significant amount of uncertainty around the exact technical implementation.

This matters because many of JEV's strongest claims are difficult for outside researchers to independently reproduce without access to the underlying model and training details.

The lack of transparency has therefore attracted skepticism from parts of the AI research community.

At the same time, the model has attracted considerable developer interest.

Why JEV Can Be So Cheap

One of the biggest consequences of JEV's architecture is its output economics.

Traditional LLM APIs generally charge for both input and output tokens.

Output generation can be expensive because generating a response requires the model to repeatedly execute its generation process.

JEV does not generate a conventional text response.

Instead, the decision is produced as part of the model's forward pass.

As a result, TypeSafe charges primarily for input tokens, with output effectively free under its pricing model.

The reported price is approximately:

$0.042 per million input tokens.

That is extremely low compared with many frontier language models.

At high volumes, the difference becomes substantial.

For example, processing thousands of decisions every day can become dramatically cheaper when the decision layer is handled by a specialized model instead of a general-purpose reasoning model.

This is one of the core economic arguments behind JEV.

RLCD: Reinforcement Learning for Calibrated Decisions

JEV's training approach is called RLCD, or Reinforcement Learning for Calibrated Decisions.

The idea is fundamentally different from traditional RLHF.

RLHF generally optimizes models toward responses that human evaluators prefer.

RLCD focuses more directly on whether the model's probabilities correspond to actual outcomes.

The goal is calibration.

If JEV says that something has an 87% probability, the ideal behavior is for roughly 87% of similarly confident predictions to be correct.

That sounds simple.

It is not.

Why Calibration Matters

Many AI systems are overconfident.

A model may give an answer with very high confidence even when it is wrong.

JEV's value proposition depends heavily on avoiding this problem.

Imagine a production system where JEV evaluates a decision.

You could create a system like this:

95% confidence

Automatically execute the action.

60% confidence

Send the decision to a human reviewer.

30% confidence

Send the request to a more powerful LLM for deeper analysis.

Now confidence becomes an operational control mechanism.

It is no longer just a number displayed beside an answer.

It becomes part of the architecture.

The Important Caveat: Calibration Is Not Perfect

This is one of the areas where JEV deserves careful evaluation.

Independent testers have reported calibration problems on certain datasets.

Other tests have shown that the model can still make significant content-level mistakes even when it follows the requested output schema perfectly.

This highlights an important distinction:

Schema correctness does not equal factual correctness.

JEV can guarantee that the answer has the correct structure.

That does not mean the decision itself is always correct.

A model can perfectly follow the requested schema and still make the wrong judgment.

This distinction is critical when using JEV in production.

The Speed Factor

Speed is one of JEV's strongest selling points.

Reported response times range from approximately 70 milliseconds to 500 milliseconds, with many practical calls landing around the 150 millisecond range.

Traditional LLM calls involving structured output can take several seconds depending on the model, prompt, infrastructure, and workload.

The difference becomes especially significant when you are processing large volumes of decisions.

Consider email classification.

If you need to classify thousands of emails, a model that takes several seconds per decision can become a bottleneck.

A decision model operating in hundreds of milliseconds can instead become part of a real-time pipeline.

That opens up applications such as:

Content moderation
Fraud detection
Tool authorization
Customer support routing
Safety checks
Real-time classification
Model routing
Automated workflow decisions

JEV is not simply trying to be a slightly faster chatbot.

It is targeting a different workload.

What People Are Actually Building With JEV

The ecosystem around JEV expanded rapidly after launch.

Developers started experimenting with it across many different categories.

Some of the strongest use cases are the ones where decisions are:

Frequent
Structured
Repetitive
Time-sensitive
Easy to describe with a bounded set of outcomes

Here are some of the most interesting examples.

Content Moderation at Scale

This is one of the most obvious applications.

Large platforms receive enormous numbers of:

Posts
Comments
Images
Messages
Reviews
Uploads

Running every single piece of content through an expensive frontier LLM can become economically impractical.

JEV can act as a first-pass decision layer.

For example:

Clearly safe

Approve automatically.

Clearly unsafe

Block automatically.

Uncertain

Send to a human or a more powerful model.

This architecture allows expensive models to focus on ambiguous cases instead of processing everything.

Support Ticket Routing

Customer support is another natural fit.

A support ticket can be evaluated for:

Urgency
Department
Customer frustration
Product category
Escalation requirement

Instead of asking a general-purpose LLM to explain everything about the ticket, JEV can directly produce the decisions required by the support system.

That makes the integration much simpler.

Agent Tool Selection

AI agents constantly make decisions about what to do next.

For example:

Should I search the web?

Should I check the calendar?

Should I call the database?

Should I ask the user for clarification?

Should I execute this action?

These are bounded decisions.

The agent does not necessarily need a massive reasoning model for every one of them.

A specialized decision model can handle these smaller decisions quickly.

Model Routing

Another powerful use case is model routing.

Imagine you have three models:

Cheap model

Fast and inexpensive.

Mid-tier model

More capable but more expensive.

Frontier model

Extremely capable but expensive and slower.

You could use JEV as the routing layer.

For every incoming request, JEV determines which model should handle it.

Simple requests go to the cheap model.

Moderate requests go to the mid-tier model.

Complex requests go to the frontier model.

This means you do not have to use your most expensive model for every request.

Evaluations and LLM-as-a-Judge

Evaluating AI outputs can itself be expensive.

For example, you might ask an LLM:

Which of these two responses is better?

Doing that millions of times can become expensive.

JEV can instead act as a lightweight evaluation model.

The same principle applies to:

Preference evaluation
Quality scoring
Classification
Benchmarking
Response ranking
Automated testing

A fast decision model can potentially handle the majority of straightforward judgments while a more capable model handles uncertain cases.

Fraud and Risk Scoring

Financial systems constantly make probabilistic decisions.

Examples include:

Is this transaction suspicious?
Is this insurance claim likely fraudulent?
Should this application be escalated?
Is this payment high risk?
Does this transaction require additional verification?

These are naturally expressed as probabilities or classifications.

That makes them a strong conceptual fit for JEV.

However, high-stakes systems require much more than model confidence.

They also require:

Regulatory compliance
Bias testing
Auditing
Human oversight
Robust evaluation
Domain-specific validation

A fast model does not remove those requirements.

Code Review and Triage

JEV can also be used as a decision gate for software development.

For example:

Is this change a simple refactor or a complex architectural modification?

Simple changes could move through an automated workflow.

Complex changes could be escalated for human review or sent to a stronger reasoning model.

This creates another hybrid architecture:

JEV decides what kind of problem this is.

A stronger model solves the problem when necessary.

Creative Experiments

Developers have also experimented with JEV in more unusual environments.

Examples include:

Game AI
Minecraft bots
Browser automation
Poker decisions
Crisis simulations
Autonomous agents
Mechanical control systems

One interesting description from a Minecraft experiment compared JEV's behavior to an insect making extremely fast mechanical decisions.

That is actually a useful mental model.

JEV is not necessarily trying to understand everything.

It is trying to decide what to do next.

The Jevons Paradox in Action

TypeSafe named the model after William Stanley Jevons for a reason.

The underlying economic idea is simple:

When something becomes dramatically cheaper and more efficient, people may use much more of it.

The same principle could apply to AI decisions.

Before JEV, you might avoid running an LLM over every user interaction because the cost would be too high.

With a much cheaper decision model, you can potentially evaluate every interaction.

The cost barrier drops.

As a result, entirely new automation patterns become economically practical.

Imagine being able to make thousands or millions of tiny AI decisions without worrying about the cost of a general-purpose LLM.

The result is not necessarily less AI usage.

It could be much more AI usage.

That is the Jevons paradox applied to AI infrastructure.

The Social Media Circus

No major AI launch survives the internet without memes, hot takes, speculation, and controversy.

JEV was no exception.

The Memes

The X community quickly turned JEV into a meme.

The jokes revolved around:

How cheap it was
How quickly it made decisions
Its association with crypto
The model's name
The idea of an AI that "just decides"

A memecoin also appeared around the JEV name, creating another layer of internet speculation around an already heavily discussed AI launch.

This became an amusing example of the same economic phenomenon JEV was named after.

Make decisions cheaper, and people will apparently use those decisions for increasingly ridiculous things.

The Skepticism

The excitement was accompanied by skepticism.

Some developers argued that many of the ideas behind JEV resemble existing machine learning approaches.

Others pointed out that there is still limited public information about:

The internal architecture
Training methodology
Model size
Training data
Independent evaluations
Reproducibility

This creates an important distinction between the concept and the implementation.

The concept of a specialized decision model is straightforward and compelling.

The more difficult question is whether JEV's specific implementation actually delivers the performance, calibration, and economics being claimed.

That question requires independent testing.

The Genuine Enthusiasm

Despite the skepticism, many developers have reported impressive early results.

Some users have reported JEV making routing decisions in roughly one second, compared with several seconds for conventional LLM approaches.

Other developers working on high-scale AI systems have pointed out that many of their workloads do not actually require a full-scale reasoning model.

For these workloads, a model that is significantly cheaper and faster could be extremely useful if its accuracy is sufficient.

This is probably the most important argument in favor of the JEV approach.

It does not need to replace frontier models.

It simply needs to handle the decisions that frontier models are unnecessarily expensive for.

The Technical Difference

JEV vs. Traditional LLMs

The easiest way to understand the distinction is to look at what each system is optimized to do.

Traditional LLMs

Traditional LLMs are designed for open-ended language generation.

They can:

Write text
Explain concepts
Reason through problems
Generate code
Summarize documents
Follow complex instructions
Have conversations
Produce creative content

Their flexibility is their greatest strength.

It is also one reason they can be inefficient for simple decisions.

JEV

JEV is designed for bounded decisions.

It focuses on:

Choices
Scores
Probabilities
Classification
Routing
High-volume judgments

Instead of generating a paragraph, it produces a structured decision.

Instead of optimizing for expressive language, it optimizes for fast decision-making.

Instead of being a replacement for general-purpose LLMs, it is better understood as a specialized component that can sit alongside them.

The Critical Insight: They Are Complementary

The most interesting architecture is not necessarily:

JEV versus GPT.

It is:

JEV plus GPT.

A production system could use JEV for the simple, high-volume decisions and a frontier model for the difficult cases.

For example:

Receive a request.
JEV determines the request type.
Simple requests go to a cheap model.
Moderate requests go to a stronger model.
Complex or uncertain requests go to a frontier model.
High-risk actions require human approval.

This creates a layered AI architecture.

Each model does the job it is best suited for.

The Batching Superpower

One of JEV's most interesting features is its ability to evaluate multiple questions against the same state.

Imagine receiving a customer support message.

Instead of making separate calls for:

Spam detection
Urgency
Sentiment
Department
Product category
Escalation
Refund eligibility

You can potentially ask all of these questions in a single call.

Because the questions are evaluated against the same state, they can run in parallel.

This can dramatically reduce both latency and cost.

The architectural implications are significant.

Instead of building:

Check spam
    ↓
Check urgency
    ↓
Check sentiment
    ↓
Determine department
    ↓
Determine priority
    ↓
Decide whether to escalate

You can conceptually build:

              ┌─ Spam
              ├─ Urgency
              ├─ Sentiment
State ────────┼─ Department
              ├─ Priority
              └─ Escalation

Everything is evaluated against the same piece of information.

That can make AI pipelines much more efficient.

The Confidence Cascade Pattern

This is arguably one of the most practical patterns for using JEV in production.

The basic architecture is:

Step 1

Send a decision to JEV.

Step 2

Read the confidence score.

Step 3

If confidence is above 90%, automatically execute the decision.

Step 4

If confidence is between 50% and 90%, send the decision to a human.

Step 5

If confidence is below 50%, escalate to a more powerful LLM.

The exact thresholds should depend on the application.

A low-risk application might tolerate a lower threshold.

A high-risk application may require extremely high confidence and additional verification.

The important idea is that the model's confidence becomes part of the control flow.

Why This Architecture Is Powerful

Consider a system processing one million requests.

If you send every request to a frontier model, you pay the frontier model's cost for all one million requests.

If JEV can confidently resolve 90% of those requests, you only need the expensive model for the remaining 10%.

That changes the economics dramatically.

The architecture becomes:

                ┌── High confidence → Execute
Incoming ───── JEV
                ├── Medium confidence → Human review
                │
                └── Low confidence → Stronger LLM

The frontier model becomes the exception rather than the default.

Limitations and Honest Drawbacks

JEV is interesting, but it is not magic.

There are several important limitations.

1. JEV Does Not Calculate

JEV should not be treated as a traditional calculator.

Arithmetic, counting, and date comparisons should remain in deterministic code.

If your application needs to add numbers, use a calculator or regular code.

Do not ask the AI to perform a task that software can perform exactly.

2. It Is Text-Only

JEV is designed around text-based decisions.

It is not a multimodal model for directly processing:

Images
Video
Audio

If your decision depends on an image or video, another system must first convert that information into usable state.

3. Calibration Is Not Perfect

Confidence scores are useful only if they are actually calibrated.

Independent tests have reported calibration problems on certain datasets.

Therefore, production systems should validate calibration on their own data rather than blindly trusting the confidence value.

4. JEV Can Still Be Wrong

Typed output does not guarantee correct output.

A model can return perfectly valid JSON, select a valid option, and still make the wrong decision.

This is perhaps the most important thing to understand about JEV.

Format reliability is not the same as decision reliability.

5. Adversarial Inputs Still Matter

JEV can still be affected by malicious or carefully constructed inputs.

Prompt injection and adversarial examples remain relevant concerns.

Production systems therefore need:

Input validation
Edge-case testing
Security controls
Monitoring
Human escalation
Domain-specific evaluation

6. It Is Closed Source

JEV does not currently provide the same level of transparency as fully open models.

Developers cannot simply download the model, inspect the weights, self-host it, or fine-tune it in the same way they can with open-weight alternatives.

This may become important for companies with strict infrastructure, privacy, or compliance requirements.

The Future of Decision Models

The Rise of "System One" as a Model Category

The biggest idea behind JEV may not actually be JEV itself.

It may be the creation of a distinct category of AI models designed specifically for decision-making.

If this approach works, we could see specialized decision models emerge for many domains.

For example:

Healthcare

Models specialized in clinical classification and triage decisions.

Legal

Models specialized in contract classification, risk detection, and clause analysis.

Security

Models specialized in threat classification and incident prioritization.

Finance

Models specialized in fraud detection, risk scoring, and transaction classification.

Software

Models specialized in code triage, issue classification, and tool routing.

The broader pattern would be:

One model generates.

Another model reasons.

Another model decides.

Another model verifies.

Instead of one enormous model doing everything, AI systems could become collections of specialized components.

Decision Models at the Edge

Because decision models can be smaller and faster than general-purpose language models, they may also become useful on local devices.

Potential applications include:

Real-time safety systems
Autonomous devices
Voice assistant routing
On-device classification
Robotics
Smart cameras
Industrial monitoring

The key advantage would be latency.

If the decision only needs to happen in milliseconds, sending information to a remote frontier model may be unnecessary.

A specialized local model could potentially make the decision immediately.

The Open Source Response

No popular AI architecture remains uncontested for long.

Open-source projects have already begun experimenting with the concept of System One decision models.

Some aim to reproduce JEV's interface.

Others may attempt to build alternative architectures that are:

Cheaper
Faster
More transparent
Self-hostable
Fine-tunable

Whether open alternatives can match JEV's calibration and performance remains an open question.

But the underlying idea is now public.

Decision-only AI models are a concept developers can build independently.

Enterprise Adoption

JEV launched with an early-access model and a waitlist.

Demand reportedly became strong enough that new signups were temporarily paused.

However, early developer enthusiasm is not the same thing as enterprise adoption.

The real questions are much harder:

Can the system handle enormous production workloads?
Does calibration remain reliable at scale?
Does accuracy remain consistent across different domains?
Does pricing remain sustainable?
Can enterprises trust the system with high-impact decisions?
Can it meet compliance requirements?
Can organizations audit its behavior?

Those questions will determine whether JEV becomes an important piece of AI infrastructure or remains primarily an impressive new model.

The Regulatory and Trust Question

Decision models become much more complicated when they enter high-stakes systems.

Consider:

Credit approval
Medical triage
Hiring
Insurance
Financial fraud detection
Legal decisions

Suppose an AI model approves a loan with 95% confidence and the loan later defaults.

Who is responsible?

Now imagine the same system consistently produces different outcomes for different demographic groups.

That creates an entirely different problem.

Calibration does not automatically solve fairness.

A probability can be perfectly calibrated while the underlying decision process still produces unacceptable outcomes.

As a result, high-stakes AI systems will require:

Independent audits
Domain-specific testing
Bias evaluation
Human oversight
Clear accountability
Regulatory compliance

The confidence score is useful.

It is not a substitute for governance.

What JEV Gets Right

JEV is interesting because it attacks a very specific inefficiency in modern AI systems.

A huge number of AI tasks do not actually require an essay.

They require a decision.

For example:

Is this spam?

Should this request go to billing?

Is this transaction suspicious?

Should this agent call the search tool?

Is this request simple or complex?

Using a massive generative model for every one of these questions can be unnecessarily expensive.

The architectural insight is straightforward:

Not every AI problem needs a model that talks.

Sometimes you need a model that decides.

By removing unnecessary text generation, a specialized decision model can potentially achieve major improvements in speed and cost.

The Most Interesting Part: Confidence as a Control System

The confidence cascade may be the most practically important idea here.

Traditional AI applications often treat model output as a final answer.

JEV encourages a different pattern.

The model can instead become a control mechanism.

For example:

High confidence

Proceed automatically.

Medium confidence

Ask for human review.

Low confidence

Call a more powerful model.

This turns AI confidence into a programmable threshold.

You can tune the system according to the risk of the action.

For a harmless recommendation, 80% confidence might be enough.

For a financial transaction, it might not be.

For a medical decision, you may require substantially more safeguards.

The model becomes one component in a larger decision system.

What Makes JEV Uncertain

The biggest concern is not the concept.

The concept makes sense.

The uncertainty lies in the implementation.

JEV is a very new model.

Its internal architecture is not fully public.

Its long-term reliability has not been established.

Its independent benchmark coverage is still limited.

Its calibration claims require continued testing.

That means the right way to evaluate JEV is not to ask:

"Is JEV revolutionary?"

The better question is:

"Does JEV reliably solve this specific decision problem better than the alternatives?"

That is something developers can actually measure.

JEV Is Not a Replacement for GPT or Claude

This distinction is important.

JEV is not designed to replace general-purpose language models.

It does not aim to:

Write a novel
Build an entire application from scratch
Explain a complicated mathematical proof
Have a long conversation
Generate a marketing campaign
Produce a detailed technical tutorial

Those are generative or reasoning-heavy tasks.

JEV is designed for something narrower:

Make a decision.

That makes the most compelling architecture a hybrid one.

Use a specialized decision model for simple, repetitive, high-volume decisions.

Use a powerful reasoning model when the problem actually requires reasoning.

Use deterministic software whenever a task does not require AI at all.

That last point matters just as much.

If normal code can solve a problem perfectly, AI should not be used simply because it is available.

The Bigger Idea

For years, AI development has focused on building models that are:

Bigger
More general
More capable
Better at reasoning
Better at generating language

JEV represents a different direction.

Instead of asking:

How can we make the model do everything?

It asks:

What if we build a model that does one thing extremely efficiently?

That shift could become important.

The future may not consist of one enormous model responsible for every part of an AI system.

Instead, an AI stack could look more like a collection of specialized components:

User Input
    ↓
Decision Model
    ↓
Routing Layer
    ├── Simple task → Cheap model
    ├── Generation → Generative model
    ├── Complex reasoning → Frontier model
    └── High-risk action → Human

Each component performs a specific role.

This resembles how traditional software systems are built.

You do not use one piece of software for everything.

You use databases for storage, search engines for retrieval, queues for messaging, and application code for business logic.

AI may evolve in the same direction.

Conclusion: The Silent Revolution

JEV represents a subtle but potentially important shift in AI architecture.

For years, the industry has chased larger, more general, more conversational models.

JEV asks a different question:

What if the future of AI also includes models that are smaller, faster, quieter, and specialized?

What if the best AI system is not one enormous model that does everything?

What if it is an ecosystem of specialized components?

A fast decision layer.

A slow reasoning layer.

A creative generation layer.

A verification layer.

Each component doing the job it is best suited for.

JEV is still extremely young.

Its benchmarks are still developing.

Its long-term reliability remains unproven.

Its architecture is not fully transparent.

Its calibration needs continued independent evaluation.

But the underlying idea is difficult to ignore.

Most AI decisions do not need an essay.

They need a probability.

And if a specialized model can produce those probabilities at extremely low cost and very low latency, it could change how developers design AI systems.

The question is not whether JEV will replace every LLM.

It almost certainly does not need to.

The more interesting possibility is that decision models become another standard component of the AI stack.

Not every AI problem needs a model that talks.

Sometimes it needs a model that simply decides.

PS - Read more articles by me on forg.to/@kislay/articles <3
_

Best use cases for Jev

Kumar Kislay — Thu, 24 Sep 2026 06:44:55 +0000

AI Agents Don't Need a Genius for Every Decision

AI agents burn a shocking amount of intelligence on tiny decisions.

Should I retry?
Which tool fits here?
Did this task actually finish?
Is this action risky?
Which five of these hundred documents actually matter?

Right now, most teams call the same giant model that writes their code to answer questions like these too. That's expensive, and it's overkill.

Jev fixes this. It's a small, fast model built for one job: taking a state and answering structured questions about it. No chat. No code generation. No explanations. Just decisions.

At $0.042 per million input tokens with zero output-token cost, and response times in the 70 to 500ms range, TypeSafe (the team behind it) reports workflow gains up to 193.6x faster and 444.6x cheaper than calling a frontier model for the same job.

Three question types, one call

Choice: pick one option (retry, wait, escalate).
Score: rank something on a scale (low risk to critical).
Noul: give a probability that something is true.

You can mix all three in a single request, against the same state:

{
  "state": "The deploy failed twice and customers are seeing 500 errors.",
  "questions": {
    "urgent": { "type": "noul", "instructions": "Does this need attention immediately?" },
    "severity": { "type": "score", "instructions": "How severe is the impact?" }
  }
}

Your big model keeps reasoning, writing, and researching. Jev sits around it, making the small calls that repeat thousands of times a day.

Inside the agent loop

Self-healing tool calls. An API fails. Instead of paying for another reasoning call to decide whether to retry, Jev returns retry, wait, or switch_provider directly. Your code executes it.

Loop control. "Are we done yet?" is a question every long-running agent has to answer. Feed Jev the task, recent actions, and results. It scores whether the task finished, needs another step, or needs a human.

Model routing. A typo fix doesn't need the same model as a distributed systems design. Jev decides whether the task goes to a cheap model, a frontier model, or a human, before you spend anything.

Branch pruning. When a planning model generates twenty possible approaches, Jev scores each one on cost, risk, and reversibility first. The expensive reasoning only goes to the best few.

Freedom without blind trust

This is where Jev earns its keep beyond cheap classification.

Before an agent does anything irreversible, like sending an email or issuing a refund, Jev checks: can this be undone, does it touch money or private data, is it clearly authorized. High confidence and reversible actions execute. Irreversible ones get reviewed. Unauthorized ones get blocked.

The same logic extends to temporary, task-scoped permissions instead of permanent access, and a spend firewall that reviews purchases before they happen. Indie developers stitching agents together like this, instead of just plugging into one giant permissioned model, are exactly the kind of build worth documenting somewhere. That's the gap forg.to fills: a home for builders to show what they're actually shipping, not just talk about it.

Stop paying LLMs to judge other LLMs

Using a frontier model to check another frontier model's output is expensive and slow. Jev makes the check explicit instead: did it follow instructions, are the claims supported by evidence, does it need human review. Only the uncertain cases go to an expensive judge.

The same pattern works for trace observability (did the agent loop, repeat itself, or skip an approval) and semantic code linting, where plain-English rules like "does this endpoint check authorization before touching customer data" run in CI instead of a human reading every diff.

RAG, retrieval, and research

Search returns a hundred documents. Jev scores relevance and hands your frontier model the best five. It can also verify whether a cited passage actually supports a claim, and filter stale or duplicate context before it competes for the model's attention.

Business workflows, at scale

Support routing, refund triage, lead qualification, incident response, marketplace matching, sales policy exceptions: all of these are really just a handful of small decisions repeated across thousands of cases. Jev handles the obvious ones and routes the messy ones to a human.

How to start

pip install typesafe-sdk
export TYPESAFE_API_KEY=...

Then send a state and a question. That's the whole primitive: state in, probability out, code decides.

Test it before you trust it

Don't wire this into production and hope. Pull 100 to 500 historical decisions where you already know the right answer. Run Jev against them in shadow mode, without letting it act. Compare accuracy, false positives, latency, and cost. Then set thresholds: automate above 0.95 confidence, automate-if-reversible between 0.70 and 0.95, send anything below that to a human or a bigger model.

Where Jev doesn't belong

If the task needs something created, code, content, architecture, a novel solution, that's still frontier model territory. Jev can't invent a fourth option when you gave it three. Typed outputs solve reliability. They don't solve judgment.

The bigger shift

For years, one giant model did everything: write, search, judge, route, retry, approve. That's an expensive way to run things.

The next architecture looks more like a stack: a frontier model for hard reasoning, Jev for decisions, small rerankers for retrieval, small classifiers for routing, and plain code for hard rules.

Every time you look at an agent loop now, the real question is whether that step needed a frontier model at all. Most of the time, it didn't. And if you're one of the builders putting stacks like this together, that's the kind of shipping story worth putting on forg.

Forget LinkedIn. This Is Where Real Builders Talk Now

Kumar Kislay — Wed, 16 Sep 2026 10:45:19 +0000

Indie hackers don't really have one "home" on the internet.

Some communities are built around founder stories and advice. Others are better for blunt feedback, technical discussions, audience building, accountability, or meeting other founders.

That matters because the best community for you depends on what you're actually trying to get from it.

Here are some of the most useful communities and platforms for indie hackers in 2026, what makes each one different, and where each fits into the indie-hacker ecosystem.

Quick comparison

Community	What it's built around	Best for
Forg	Professional identity around the things you build	Discovering builders, showcasing projects, networking, and building a public professional presence
Indie Hackers	Founder stories and discussions	Learning from other bootstrapped founders
Reddit	Large interest-based communities	Feedback, questions, and niche discussions
X	Social publishing and personal audiences	Distribution, networking, and building an audience
Hacker News	Technical discussion and interesting projects	Developer products and technical launches
WIP	Daily shipping and accountability	Staying consistent and shipping regularly
MicroConf Connect	Private SaaS-founder community	Peer advice and relationships with experienced SaaS founders
Small Bets	Portfolio entrepreneurship	People interested in building multiple small businesses

There isn't necessarily one platform that replaces all the others. They solve different problems.

1. Forg

Forg takes a different approach from traditional founder forums and social networks.

The basic idea is simple: your work should be part of your professional identity.

On LinkedIn, your profile is largely built around where you've worked, your education, and your job history. On Forg, the emphasis is on the things you're building, the projects you're involved in, and the people building around you.

That makes Forg feel less like a traditional career network and more like a professional network for people who make things.

Its discovery layer is also an important part of the idea. Forg Discover is designed around finding people who are building interesting things and helping those people be discovered by others.

The platform also combines several things that are normally scattered across different services:

A profile centered around your projects and work
Product and project discovery
Posts and articles for sharing what you're working on
A network of other developers, founders, designers, and builders
Product launches and community feedback
Distribution tools for sharing updates elsewhere

The interesting part isn't any individual feature. It's the idea of creating a professional network where what you've made is as important as where you've worked. Forg itself describes this distinction as defining people by what they build rather than their employment history.

Best for: indie hackers, developers, designers, founders, and other builders who want their projects to be part of their professional identity.

Trade-off: Forg is much newer than platforms like Reddit, X, Hacker News, and Indie Hackers.

2. Indie Hackers

Indie Hackers is one of the longest-running communities specifically built around independent businesses.

Its biggest strength is accumulated knowledge. The platform is built around founders sharing their experiences, businesses, and lessons, which makes it particularly useful when you're trying to understand how other people actually built and monetized independent products. Indie Hackers describes itself as a place where founders share their stories and where entrepreneurs can learn from those examples. It was founded in 2016.

The discussions can range from validating an idea to pricing, marketing, growth, hiring, and everything that happens after launch.

It is less about creating a polished professional identity and more about learning from the experiences of other founders.

Best for: learning from founder experiences, researching business models, and asking questions about bootstrapping.

Trade-off: the amount of historical content is a strength, but it can also make the community feel more like a forum and knowledge archive than a modern social network.

3. Reddit

Reddit is less of a single indie-hacker community and more of a collection of communities.

For example:

r/indiehackers for indie-hacking discussions
r/SideProject for sharing projects and getting reactions
r/SaaS for SaaS-specific discussions
r/buildinpublic for sharing progress publicly

That variety is Reddit's biggest advantage. You can find people interested in a very specific problem or type of product.

It also makes Reddit useful for feedback. Recent discussions from indie hackers continue to point people toward communities such as r/indiehackers, r/SideProject, and r/buildinpublic for different kinds of feedback and accountability.

The downside is that every subreddit has its own culture and rules. Self-promotion can also be heavily restricted, particularly in communities where users are already exposed to a large amount of product promotion.

Best for: getting opinions, asking specific questions, researching problems, and finding niche communities.

Trade-off: the experience varies dramatically from subreddit to subreddit, and promotional posts can easily disappear in busy communities.

4. X

X remains one of the most useful places for indie hackers who want to build an audience around themselves.

The advantage isn't really the platform's community structure. It's distribution.

Founders can share product updates, experiments, lessons, revenue milestones, opinions, failures, and launches while building a following around their work.

That makes X particularly powerful when your goal is not just to meet other founders but to become known by a larger audience.

The downside is that you're building on a fast-moving social feed. A useful post can disappear quickly, and building a meaningful audience usually requires consistent publishing rather than simply joining the platform.

Best for: audience building, distribution, networking, and personal brands.

Trade-off: reach is unpredictable, and the platform rewards people who consistently publish and participate.

5. Hacker News

Hacker News is a very different environment from the other communities on this list.

Its audience is heavily interested in technology, software, startups, and intellectually interesting projects. A successful Show HN submission can generate substantial discussion and direct feedback from technical users.

But Hacker News isn't designed to be a personal professional network or a place to maintain an ongoing creator identity.

Its own guidelines describe Show HN as a place for things you've actually made that other users can try, and explicitly discourage using the site primarily for promotion.

That culture is part of what makes useful discussions possible, but it also means a polished marketing launch isn't necessarily what the audience wants.

Best for: developer tools, technical products, open-source projects, and getting feedback from technically sophisticated users.

Trade-off: the audience is highly relevant for technical products, but the community is not designed around self-promotion or ongoing personal branding.

6. WIP

WIP is built around a much narrower idea: ship consistently.

WIP describes itself as a community of makers who ship together and help each other stay accountable. Its system revolves around sharing concrete progress rather than simply posting thoughts.

The platform is particularly interesting for people who have no shortage of ideas but struggle to keep making progress.

Instead of trying to become another giant social network, WIP focuses heavily on the habit of shipping. It includes daily progress, projects, community discussions, feedback, and regular hangouts.

Best for: accountability and maintaining a consistent shipping habit.

Trade-off: if you aren't interested in sharing regular progress, much of WIP's value proposition becomes less relevant.

7. MicroConf Connect

MicroConf Connect targets a more specific group: SaaS founders.

It is a private, vetted community for bootstrapped and mostly bootstrapped SaaS founders, with members ranging from pre-revenue founders to companies doing millions in ARR. MicroConf currently describes Connect as having 300+ bootstrapped founders.

The emphasis is less on public visibility and more on private conversations, peer relationships, advice, and accountability.

That distinction matters. Someone looking for a public place to share their new side project may get more value elsewhere. Someone trying to solve a difficult pricing, hiring, churn, or growth problem with other SaaS founders may want exactly this kind of private environment.

Best for: SaaS founders looking for deeper peer relationships and practical business advice.

Trade-off: membership is paid and curated, so it's intentionally less open than public communities.

8. Small Bets

Small Bets is centered around a different philosophy of entrepreneurship.

Rather than focusing entirely on building one large startup, Small Bets explores the idea of creating a portfolio of smaller businesses and income streams. The newsletter describes itself as inspiration for building your own portfolio of small bets.

This makes it particularly interesting for solopreneurs who don't necessarily want to follow the conventional startup path.

The community and content are less about "how do I grow my SaaS from $10k to $100k MRR?" and more about optionality, independence, and experimenting with multiple business ideas.

Best for: solopreneurs interested in small businesses, digital products, and entrepreneurial optionality.

Trade-off: the philosophy won't appeal to someone whose primary goal is building one large venture-backed or bootstrapped company.

How these communities fit together

The useful thing about these platforms is that they don't actually need to compete for exactly the same job.

You might use:

Indie Hackers to learn from other founders.
Reddit when you need feedback or want to find a niche community.
X when you want distribution and an audience.
Hacker News when you've built something technical that developers can actually try.
WIP when accountability is your biggest problem.
MicroConf Connect when you want deeper conversations with SaaS founders.
Small Bets when you're interested in building multiple small businesses.
Forg when you want your projects and what you build to become part of your professional identity and network.

That's probably the most important distinction.

The indie-hacker ecosystem isn't really one giant community. It's a collection of different places for different stages of building.

And the interesting question isn't necessarily "Which community is the best?"

It's "Where do you want your work to live?"

What Is an Indie Hacker?

Kumar Kislay — Tue, 15 Sep 2026 20:36:44 +0000

It's 1:40 a.m. The fan is on its slowest setting, the coffee went cold two hours ago, and the only light in the room comes from a laptop screen. On that screen is a notification nobody else in the house would care about:

New payment received: $9.

The person staring at it has no funding round, no board of directors, and no office with a ping-pong table that nobody uses. What they do have is a product they built alone, a few dozen users who found it through a forum comment, and now, somehow, a stranger willing to pay for it.

That person is an indie hacker. And if the moment sounds small, you probably haven't met one yet.

The short answer

An indie hacker is someone who builds a business on their own terms. Usually small, usually online, and almost always without outside investors.

"Indie" means independent. "Hacker" doesn't mean someone breaking into bank servers from a dark basement. It's the older, kinder meaning of the word: a person who figures things out with whatever tools happen to be lying around.

Indie hackers build SaaS tools, browser extensions, newsletters, templates, mobile apps, APIs, and oddly specific marketplaces that serve exactly one type of customer very well. Some make enough for a weekend dinner. Some replace their salaries. A few build something big enough that investors start calling, and then politely decline the meeting.

The size of the business isn't what makes someone an indie hacker. Ownership is.

Meet Ananya

Let's go back to our 1:40 a.m. builder. We'll call her Ananya.

Ananya is a freelance designer. For three years, every new client meant the same ritual: copy last month's invoice spreadsheet, fix the formulas she broke last time, chase payments over email, and repeat. One evening, annoyed for roughly the four-hundredth time, she thought, someone should just build a simple tool for this.

Then came the thought that separates indie hackers from everyone else: why not me?

She didn't write a business plan. She didn't make a pitch deck. She spent six weekends building the smallest possible version of an invoicing tool for freelancers. It had one feature that worked and two that mostly worked. The landing page had a typo in the headline for eleven days.

She shipped it anyway.

The loop that runs everything

If you watch enough indie hackers, you start to see the same pattern. It goes something like this:

Notice a problem that annoys real people. Build the smallest thing that solves it. Put it out into the world before it feels ready. Talk to the people who use it. Fix what they complain about. Repeat until something clicks, or until you learn enough to start the next thing.

That's it. No secret framework. The magic isn't in the loop itself. It's in how many times someone is willing to run it.

Ananya's first version got 14 signups in a week. Nine of them never came back. Three sent feedback. One of those three said, "I'd pay for this if it sent automatic payment reminders." So she built payment reminders.

That's how the $9 happened.

What indie hackers have in common

They wear every hat. On any given day, an indie hacker is the developer, the designer, the support team, the marketing department, and the accountant who quietly panics at tax time. There's no one to hand things off to, so they learn a little of everything and get surprisingly good at a few things.

They prefer profit over valuation. A startup might chase growth and worry about money later. An indie hacker usually wants the business to pay for itself as early as possible, because there's no investor cushion to fall back on. Revenue isn't a vanity metric for them. It's oxygen.

They ship before they're comfortable. Perfection is expensive when you're a team of one. Indie hackers learn early that a working product with rough edges beats a flawless product that only exists in a Figma file.

They build in public. Many of them share their revenue numbers, failed launches, half-finished features, and lessons learned, openly and in real time. It sounds risky, but it does two things at once: it keeps them accountable, and it quietly builds an audience of people rooting for them.

And more than anything, they want freedom. Freedom to choose what to work on, who to work with, and when to close the laptop. Money matters, but control over their own time is usually the real prize.

The awkward question: where do you show your work?

Here's a problem Ananya ran into a few months in.

She wanted to share her progress. Every new feature, every small milestone, every "we crossed 100 users" moment. But most professional networks weren't built for someone like her. Her feed was full of people who were "thrilled to announce" promotions, and her profile asked for job titles and employment history. The honest version of an indie hacker's résumé is a list of side projects that didn't work, followed by one that finally did. That doesn't fit neatly into a box labeled "Experience."

Regular social media wasn't much better. She'd write a thoughtful update about a feature she'd spent two weeks on, and it would disappear from everyone's feed in twenty minutes.

Eventually a fellow founder pointed her to forg.to, and it clicked, because it's built around a simple idea: your identity is what you build, not where you've worked.

Her profile there isn't a résumé. It's her product, her stack, and her entire build history in one place. Every update she ships lands on a timeline, so her product's story grows chapter by chapter instead of vanishing after launch day. Shipping streaks show that she actually builds, consistently, which is the kind of proof no job title can offer. When she launched a new version, she put it on the Monday Launchpad and got feedback from other founders who ship things themselves, not from bots or people who just drop a thumbs-up and leave.

And the part she loved most: she writes an update once and cross-posts it to X, LinkedIn, and Bluesky with one click. No more rewriting the same announcement three times.

It feels less like a corporate networking event and more like a room full of people with laptops open, trading notes on what they're building. No corporate slop. Just work, shown honestly.

A few myths worth clearing up

"You have to be a programmer." You don't. Plenty of indie hackers build with no-code tools, sell digital products, run newsletters, or team up with a developer friend. The "hacker" part is about resourcefulness, not syntax.

"It's just a side hustle." Sometimes it starts that way, and sometimes it stays that way by choice. But many indie hackers eventually go full-time on their products. The difference isn't in how serious the work is. It's in who owns it.

"You have to do it all alone." Indie means independent, not isolated. The best indie hackers are deeply connected to other builders. They swap advice, test each other's products, share launch strategies, and cheer when someone hits their first dollar. Working alone doesn't have to mean being lonely.

"If it doesn't become huge, it failed." A product that pays your rent, runs on a few hours a week, and serves customers who genuinely love it is not a failure. For many indie hackers, that is the entire dream.

Back to 1:40 a.m.

Ananya didn't sleep much that night. Before closing her laptop, she posted a short update on her Forg timeline:

"First paying customer. $9. Going to bed at 3 a.m. Worth it."

By morning, a dozen founders had replied. Someone congratulated her. Someone asked how she handled payment reminders. Someone else shared the story of their own first $9, which had happened four years earlier and had since turned into a business that paid their whole team.

That's the thing about indie hackers. The first dollar is never really about the dollar. It's proof that something you made, by yourself, from nothing but an annoyance and a few stubborn weekends, is valuable to someone else.

So, what is an indie hacker?

It's anyone who has ever looked at a problem and thought, why not me? And then, instead of waiting for permission, opened their laptop and started building.

If that sounds like you, you're already one. You might as well start showing your work.

Why Models Are Getting Dumber on Purpose?

Kumar Kislay — Mon, 14 Sep 2026 07:33:15 +0000

Models Are Getting Dumber on Purpose

Reasoning scores keep climbing while per-token compute keeps falling. GLM-5.2 scores 99.2% on AIME 2026 with about 40 billion parameters active per token. Qwen3.5 hits 91.3% with 17 billion active. DeepSeek V4-Flash runs 13 billion active. For scale, GPT-4 was rumored to run around 280 billion active parameters in 2023, and it could barely finish an AIME problem. At the small end, Qwen3.5 9B fits in 6GB of VRAM quantized and roughly doubles the score of the next best model under 10B on Artificial Analysis's intelligence index.

Look only at math and code and you would conclude that intelligence per parameter is improving at an absurd rate.

Now ask the same models a plain factual question. On SimpleQA, closed book with no tools, the current leader is Gemini 2.5 Pro at 53%. The best factual recall money can buy still misses half the questions. The small models barely register: Artificial Analysis measures Qwen3.5 4B and 9B at hallucination rates of 80 to 82% on its knowledge benchmark. When they don't know a fact, which is most of the time, they invent one. Ask the 9B for the birth year of a minor 19th-century mathematician and you get a confident, plausible, wrong answer.

The parameter count didn't drop for free. Labs are trading world knowledge for reasoning skill, and the trade is deliberate.

What the parameters were for

Facts take space. The cleanest measurements I know of come from the Physics of Language Models series, which puts the ceiling at roughly two bits of factual knowledge per parameter. If you want a model that knows the birth year of every minor Wikipedia figure, the population of every Dutch municipality, and the argument order of every function in every npm package, you pay for that in weights. That is a large part of why frontier models grew into the trillions.

Reasoning compresses much better, because it is a small set of procedures applied over and over: split the problem, track intermediate state, check your own work, backtrack when a step fails. Distillation and reinforcement learning on verifiable tasks transfer those procedures into small models surprisingly well. Phi-4 is 14 billion parameters, trained heavily on synthetic textbook-style data, and it is good at math and bad at trivia. That tells you exactly what was in its training set. Two years ago that profile read as a limitation of synthetic data. Now it reads as the spec.

The knowledge that survives the trade has a shape worth noticing. These models are generalists: a little about nearly everything, almost nothing in depth. Ask one about PostgreSQL and it knows what it is, what it is good at, and roughly how MVCC works. Ask which version added a specific planner feature and you are back to invented facts.

I think that is the correct layer to keep in weights. Breadth is what lets a model understand what a question is about, know what to go look up, and judge whether a source is plausible. Depth is cheap to retrieve and expensive to store, so depth is the part that goes.

Facts rot, procedures don't

A frontier training run takes months and costs hundreds of millions of dollars, and the facts inside it start going stale the moment it finishes. APIs change, prices change, people change jobs. Half of what a 2024 model believed about the JavaScript ecosystem was already wrong on release day. Every fact baked into weights has a shelf life, and the only refresh mechanism is another training run.

Procedures don't rot. Algebra worked the same way in 1970. So did breaking a problem into parts, or spotting a contradiction between two sources. A model that is mostly procedure and only lightly loaded with facts does not age the way a knowledge-heavy model does. Its training cutoff matters much less, because the current state of the world was never supposed to live in the weights.

This is the strongest argument for the whole approach, and it is the one that convinced me. It decouples the expensive, slow artifact from the thing that changes daily.

The harness carries the knowledge

If the model doesn't know things, something else has to. That something is the harness: retrieval over a knowledge base, tool calls, web search, a filesystem full of docs. I wrote earlier that Rust is a harness for agents, a source of cheap machine-checkable feedback. This is the same shape viewed from the other side. The model supplies reasoning. Everything it reasons about gets supplied at runtime.

You can already watch agents work this way. A coding agent does not need your dependency's API surface memorized, because it greps node_modules or reads the docs before it calls anything. Its answer is grounded in the version you actually have installed, not whichever version dominated the training corpus. Recall that used to be a fixed cost in every forward pass became an on-demand lookup.

Knowing less only helps if the model knows that it doesn't know

This is the part I think most of the optimistic writing on this skips, including my own earlier drafts.

A small model paired with a good harness is only safe if it reliably says "I don't have this, let me look it up." Abstention is not a free side effect of having fewer parameters. It is a separate trained behavior, and the industry has spent years training the opposite.

OpenAI's 2025 paper on hallucination makes the mechanism plain: most benchmarks use binary scoring, so a wrong answer and an abstention score identically at zero. Under those rules a model that always guesses beats an otherwise identical model that sometimes admits uncertainty. We built the leaderboards to reward bluffing and then acted surprised when models bluff.

Shrinking the model makes this worse before it makes it better, because you have widened the gap between what the model is asked and what it holds. Those 80% hallucination rates on small models are not a knowledge problem. They are a calibration problem sitting on top of a knowledge problem. The knowledge half is the part we are deliberately removing. The calibration half is the part that has to be solved, and it does not get solved by making the model smaller.

A frontier model on your GPU

Follow the trend out a couple of years and I think you get frontier-quality reasoning on a single consumer GPU.

The compute half is close. DeepSeek V4-Flash reasons with about 13 billion active parameters per token, comfortably inside consumer range. What does not fit is the other 271 billion sitting in its experts. Note that this is a memory problem, not a compute problem: in a mixture of experts you only multiply through a slice of the weights per token, but the whole thing still has to be resident somewhere the GPU can reach. Active parameters set your speed. Total parameters set whether you can run it at all.

Expert layers are mostly fact storage, and fact storage is exactly what this trade makes optional. Strip it out and total size collapses toward active size. A 20 to 40B model at 4-bit quantization fits on the 24GB card that has been sitting in gaming PCs since 2022.

The catch is that it will not know much. Asked a bare factual question with no tools attached, the correct behavior is to say so and go look. Paired with a decent harness, that covers most of what I use a frontier model for today, running locally, with no per-token bill and nothing leaving the machine.

Where this breaks

Two honest problems, since I would rather state them than have them stated back to me.

First, retrieval is not free. Every fact that used to be one forward pass away is now a round trip and a few thousand tokens of context. You have not eliminated the cost of knowledge, you have moved it from weights into the context window, where it is paid again on every single query instead of once at training time. For a local model with no per-token bill that is a good trade. For a high-volume API workload it is much less obviously one.

Second, judgment needs a floor of knowledge. To evaluate a retrieved document you need enough background to tell a good source from a bad one, and to notice when a question contains a false premise you need to already know the thing being assumed. Cut too deep and you get a model that reasons beautifully over whatever garbage the retriever handed it. Nobody has published a clean number for where that floor sits, and I suspect it is task-dependent enough that nobody will.

This mostly fixes hallucination

Still, the direction is right, and the reason is what it does to wrong answers.

When a fact lives in weights, a wrong fact is unfindable and unfixable. You cannot grep the weights, you cannot diff them against last month, and correcting one error means a fine-tune that might break who knows what else. The model states a wrong fact with the same fluent confidence as a right one, and there is no artifact to check it against.

When the fact lives outside the model, a wrong answer has an address. The model cites a document, so you open the document. If the document is wrong you edit it, and every future query gets the correction instead of waiting a year for the next training run. Retrieval does not get you to zero, since a model can still misread a source or stitch two together wrong. But a claim with a source is checkable and a claim from weights is not. A wrong fact in a knowledge base is an ordinary data bug, the kind we already know how to trace, fix, and write a regression test for.

There is a version of this where the model card stops listing a knowledge cutoff entirely, because what is left in the weights goes stale on a scale of years instead of weeks. The model just gets handed the current state of the world at runtime, the way a CPU gets handed a program.

I Analyzed 700 Indie Hacker Projects. Here's What Everyone Is Actually Building in 2026

Kumar Kislay — Sat, 12 Sep 2026 06:01:32 +0000

I pulled the numbers from Forg — 700 public projects, 1,318 builders, and a mountain of company data — to answer three questions I keep arguing about with other founders:

What are indie hackers actually shipping?
What stack are they running?
How are they charging for it?

The patterns turned out sharper than I expected. Here's the honest read.

AI didn't win. It lapped the field.

"AI is popular" is not news. What surprised me was the margin.

AI is the single most common project tag, and if you group the whole family together — AI, AI Agents, AI Tools, AI Video Generators — it accounts for 8.5% of every tag on the platform. No other theme comes close.

But the tag counts undersell it. The growth curve is the real story:

Technology	Last 6 mo	Prior 6 mo	Growth
AI	28	5	+460%
AI Agents	13	0	NEW
AI Video Generator	6	0	NEW
Privacy	12	0	NEW
SaaS	18	5	+260%

"AI Agents" went from zero projects to thirteen in a single six-month window. Same with AI video generation. These aren't fast-growing categories — they're categories that didn't exist here a year ago and now do.

And builders are skilling up to match: LLMs, RAG, LangChain, the OpenAI API, and prompt engineering are all showing up on profiles now. It's still a minority cohort (~2.8% of users), but it's the fastest-forming one on the platform.

Takeaway: If you're starting something today, "AI-native" isn't an edge anymore — it's the baseline everyone else is already at.

There is now one indie hacker stack — and it's frontend-first

Ask ten founders their stack and you used to get ten answers. Not anymore. The skill data has quietly converged on a single, boring, effective setup:

Rank	Skill	Builders
1	Product Design	55
2	JavaScript	52
3	TypeScript	49
4	React.js	48
5	Figma	45
6	Python	22
7	PostgreSQL	18
8	Node.js	13
9	Next.js	12

Two things jump out.

First, design is not a nice-to-have. Product Design is the number one skill, and Figma outranks Python. The modern solo builder is expected to make it look good, not just make it work.

Second, TypeScript is nearly caught up with JavaScript (49 vs 52) and growing faster in project tags. If you're picking one to learn deeply, the trend line points clearly at TS.

The full picture: JavaScript + TypeScript + React + Next.js + Figma + a Postgres backend. That's the default kit now.

Everyone charges the same way: free (at first)

This one's almost unanimous. Freemium is 73% of all projects. Add straight-up free products and you get this:

88.5% of projects have a free entry point.
Subscription-only: 8%
One-time purchase: just 3.7%

The free-door funnel has become the reflex. Which is exactly why the opposite is interesting — one-time pricing has been nearly abandoned. In a world where everyone is training users to expect a free tier, "pay once, own it forever" is starting to look like a differentiator rather than a mistake.

Still web-first, and it's not close

For all the mobile hype, the platform is overwhelmingly built for the browser:

Web: 77% of projects
Mobile (iOS + Android combined): 17%
SaaS is 47% of all product types; mobile apps are 21%

The playbook most builders are running: ship web first, add mobile only if traction demands it. Cross-platform combos exist (Web + Chrome Extension for automation tools, iOS + Android for social apps), but they're the exception, not the plan.

The gaps nobody is filling

The most useful part of any trends report isn't what's crowded — it's what's empty. A few categories are almost untouched:

Testing / QA: 3 projects
IoT / hardware: 1 project
Crypto payments: 1 project
Firefox extensions: 4 projects
APIs as a product: 15 projects
One-time pricing: 3.7% of the market

None of these are glamorous. That's the point. Everyone is piling into AI-flavored freemium web SaaS, which means the whitespace has moved to the unsexy corners — developer tooling, hardware, and business models that don't start with "free."

So what should you build?

The safe bet, statistically, is an AI-enhanced, freemium, web-first SaaS built on TypeScript, React, and Next.js, with a designer's eye on the UI. Do that and you'll fit right in.

But "fit right in" is another way of saying "crowded." The more interesting move is to take the modern stack everyone's converged on and point it at a corner nobody's serving — testing, hardware, a genuinely great Firefox tool, or a premium product you pay for once.

A caveat worth stating: this is a snapshot of one platform, and skills are self-reported. Treat it as a strong signal about where indie builders are heading, not gospel. But the direction is hard to miss — AI up and to the right, design on equal footing with code, and free as the default front door.

What are you building right now, and does it match the pattern or break it? I'd genuinely like to know.

PS - The research is done only on the data of forg.to users and projects not globally.

How forg.to Got Cited by ChatGPT Before It Ranked on Google

Kumar Kislay — Tue, 25 Aug 2026 13:41:45 +0000

I opened Ahrefs a few weeks ago to check one number. Forg's domain rating: 43.

For something built mostly in evenings, that felt like a milestone. Google was starting to trust the site enough to rank it.

Then I checked something else, almost by accident.

Referral traffic from ChatGPT.

Not a fluke, not a one-time spike. Repeated visits, day after day, coming from people who had just asked ChatGPT about indie builders, side projects, or companies they were curious about. ChatGPT was answering with forg.to as the source.

I sat with that for a minute. We had a real, measurable footprint in search engines that don't rank pages at all. They answer questions.

Two different games, two different timelines

Google ranking is slow by design. It rewards backlinks, domain age, consistent traffic, months of signal stacking on top of each other. Hitting a DR of 43 took real time.

AI citation doesn't work like that. ChatGPT, Perplexity, and tools like them aren't ranking pages against each other. They're pulling a structured, unambiguous answer to a specific question and deciding, in that moment, whether your page is clean enough to hand to someone as the answer.

That's a completely different bar to clear. Turns out we'd been clearing it without fully realizing.

What actually made this happen

Looking back, three things mattered more than anything else.

We made the site easy to parse, not just easy to read. Every builder and product page on Forg has a markdown mirror sitting next to the regular page, plus schema.org structured data describing exactly what it is. Humans never see this layer. Models read it directly.

We picked one identity and never let go of it. Forg is a builder identity network. Not a portfolio tool, not a launch platform, not build-in-public with a new coat of paint. Every page, every bio, every description repeats that same framing. AI models seem to reward that kind of consistency, because ambiguity is exactly what makes a source unreliable to cite.

We fixed our own confusion before it could confuse anyone else. There's a publicly traded company with a similar-sounding name. Early on, we deliberately disambiguated Forg from it across every page and every piece of structured data. A model that can't tell what you are won't risk citing you.

None of this was a growth hack. It was closer to good writing discipline, applied at the infrastructure level instead of the sentence level.

The part that actually matters

A lot of builders I know are shipping genuinely good work right now. If someone asks an AI about them today, there's a real chance the AI has nothing to say back. Not because the work isn't good. Because there's no clean, structured place for the model to find it.

Google used to be the only front door to being found online. That's no longer true. There's a second door now, and it opens on different rules: clarity over authority, structure over age, a clean answer over a large backlink profile.

We didn't plan for Forg to become an example of this. We were just trying to build something honest for builders. It turned out honesty, structured well, reads as trustworthy to a model too.

The window to be the answer, and not just a listing, is still wide open. Most people building things right now don't know it exists.

The Best LinkedIn Alternative for Developers, Designers, and Builders

Kumar Kislay — Sun, 02 Aug 2026 09:28:12 +0000

LinkedIn Feels Like Facebook Now. Here's What Comes Next.

career

developers

discuss

design

Open LinkedIn. Then open Instagram. Then go back to LinkedIn.

You will feel the fifteen years. The blue-and-white template. The dense wall of text posts stacked on top of each other. The same "3rd" badge next to every name. The same grey card shadows that haven't changed since profile redesigns were still called "beta." It is functional in the way a government form is functional. Nobody opens it because they want to. They open it because they feel they have to.

Now scroll Instagram. Or Arc. Or Linear's website. Or basically any product built in the last five years by people who cared about how it feels to use. Dark, considered interfaces. Whitespace that isn't accidental. Content that is the product, not decoration bolted onto a spreadsheet.

The short answer to "what's the best LinkedIn alternative in 2026" is this: builders aren't looking for another feed. They're looking for a professional network that was actually designed, built for a narrower audience, and not drowning in AI-written filler. That's the gap forg.to is built to close. Design is the first thing you notice. It's not the main reason people stay.

LinkedIn Is the Facebook of Professional Networks

Facebook's core layout hasn't fundamentally changed in over a decade. A vertical feed of text and photos from people you loosely know, interrupted by ads, sorted by an algorithm you don't control, wrapped in a blue-and-white shell that was already starting to look dated by 2015.

LinkedIn is that same shape, just wearing a suit.

A vertical feed. Text posts from people you loosely know. Ads wedged in every few scrolls. A notification bell that never stops lighting up for things that don't matter. The profile page is a form: job title, company, dates, a skills list nobody verifies. It was designed for résumés on the internet, and it still looks and behaves like a résumé on the internet, even now that "professional identity" means something much bigger than an employment timeline.

Instagram, by contrast, rebuilt the idea of a profile around the content itself. Your grid is your work. Your Story is your update. The design gets out of the way so the thing you made is what people actually see.

That's the model forg.to follows for professional identity: the product, the update, the shipped feature is the profile. Not a résumé with a photo attached to it.

The Feed Is Drowning in AI Slop, and the Data Backs It Up

This isn't a vibe. It's now measurable.

A July 2026 study from AI detection firm Pangram Labs analyzed over a million posts across six major platforms — LinkedIn, X, Substack, Medium, and Reddit among them. The result: more than 40% of LinkedIn's long-form posts were flagged as fully AI-generated, the highest share of any platform measured. LinkedIn alone accounted for roughly two-thirds of all AI-generated content Pangram detected across every platform in the study, even though its posts made up only about a third of the total sample.

It gets more specific. Pangram found that LinkedIn users tend to go all-or-nothing with AI — only about 4% of flagged content was AI-assisted or lightly edited. The rest was either fully human or fully machine, meaning the platform isn't full of people polishing their own drafts with AI. It's full of people outsourcing the writing entirely, then hitting publish under their own name and photo.

The market has already started punishing it. Coverage of the same study found AI-generated LinkedIn posts pulling in roughly 45% less engagement than human-written ones. Readers can tell, even when they can't articulate why. And LinkedIn's own reported content volume kept climbing anyway, up 14% year over year as of mid-2026, which means the flood isn't slowing down.

So the platform where career reputations are supposedly built on visible expertise is now a place where the majority-vote experience is: is this even a person?

LinkedIn Is for Everyone. That's the Problem.

LinkedIn's pitch has always been breadth: every industry, every job title, every professional on one network. A nurse, an insurance broker, an HR manager, a real estate agent, a Fortune 500 SVP, and a first-year developer are all sharing the same feed, the same algorithm, and the same incentive to sound impressive.

That breadth is exactly why the feed reads the way it does. A platform trying to serve every profession on earth ends up optimizing for the lowest common denominator of professional content: motivational quotes, humblebrags reframed as "lessons," recruiter spam, and corporate PR dressed up as personal reflection. None of it is written for a developer, a designer, or a founder specifically. It's written to perform generically well across a hundred unrelated industries at once.

Forg doesn't have that problem, because it doesn't try to serve everyone. It's built for one type of person: someone building something, whether that's a startup, a side project, a piece of open-source software, or a portfolio of shipped work. That narrower focus does two things at once.

It keeps out the noise that has nothing to do with your work — no "excited to announce" hiring posts, no engagement-bait about leadership lessons, no AI-polished corporate updates from people who have never shipped anything themselves. And it means the people you're actually connecting with are self-selected for the same thing you are: building, shipping, and grinding, not managing a personal brand.

That's the second, quieter reason forg avoids the AI slop problem LinkedIn has. It's not just that shorter-form, work-anchored posts are harder to fake convincingly. It's that the audience itself has no appetite for it. A community of people who can tell the difference between a real commit history and a vague "thrilled to share" post doesn't reward generic AI copy the way a general-audience feed does.

Résumé-Shaped Profiles Don't Fit Builder-Shaped Careers

LinkedIn's schema assumes your professional story is Company A, then Company B, then Company C. Titles. Dates. A neat vertical stack of employment.

That schema breaks the moment your career doesn't look like that:

A developer with five shipped side projects and one job
A student with three products and real users, but no formal work history
An indie hacker running a profitable SaaS with no employees to list
An open-source maintainer whose real body of work lives in commit history, not a job title
A designer whose best work is a Figma file and a launch thread, not a bullet point

None of that has a native home on LinkedIn. You end up copy-pasting links into an "About" section that was never designed to hold them, hoping someone actually clicks through instead of skimming your job titles and moving on.

A forg.to profile is built the other way around. Your identity is your build history: what you shipped, when you shipped it, and what happened next. It's a changelog, not a résumé.

What forg.to Actually Gives You

Skip the pitch and look at the mechanics. This is what's live on the platform today:

A verified builder profile. A dedicated home at forg.to/@you for your product, your stack, your links, and your entire build history — with shipping streaks and an immutable changelog attached to it. It's proof of work, not a claim of work. Anyone can list "React" as a skill on a résumé. Not everyone can point to a running streak of shipped updates.

Your actual work, rendered live, not pasted as links. GitHub contribution graphs, LeetCode and Codeforces problems solved, YouTube tech videos, Medium and dev.to articles — all of it shows up on your forg profile as interactive, embedded widgets instead of a wall of URLs nobody clicks. On LinkedIn, this same information gets flattened into a plain text line in your "About" section, if it fits at all. On forg, it's the profile.

A weekly launch, not a one-time launch. Every Monday, new products go live on the forg Launchpad in front of an audience of people who actually build things — not bots, not tire-kickers. Most launch platforms give a product one loud day and then let it disappear. Forg treats launch day as chapter one, not the whole book.

Write once, reach three platforms. Post an update on forg and cross-post it to X, LinkedIn, and Bluesky in a single click — instantly or scheduled. Notice what that means: forg isn't asking anyone to quit LinkedIn cold turkey. It's making LinkedIn one distribution channel among several, instead of the only place your professional voice lives.

A changelog that lives on your own domain. Connect your forg timeline via RSS to your own website's changelog page. Your updates stay on infrastructure you actually own, not rented space inside someone else's algorithm.

A feed built around momentum, not moments. Every update, feature, and milestone gets its own post on your timeline, so your audience follows the whole story of a product, not just its launch day. Attention compounds the more you actually ship — which is a very different incentive than a feed that rewards whoever wrote the most emotionally engineered caption that week.

Today, that's over 10,000 builders and counting, documenting real products instead of performing a career.

LinkedIn vs. Forg, Side by Side

	LinkedIn	Forg
Identity built around	Job titles and employment dates	Shipped products and updates
Design era	Early-2010s corporate template	Modern, dark-first, product-led
Audience	Every industry and job function	Developers, designers, founders, indie hackers
Feed composition	Recruiter posts, HR announcements, corporate PR, motivational content	Product updates, launches, and build logs
Content quality signal	Engagement and reach	Verified shipping history
AI content saturation	~40%+ of long-form posts fully AI-written (Pangram, 2026)	Content is tied to real, dated, shippable work
Profile depth	Self-reported skills, no verification	Immutable changelog, streaks, proof of work
Skill proof	A typed line under "Skills," unverified	Live GitHub, LeetCode/Codeforces, YouTube, and article widgets
What gets rewarded	Polished storytelling about work	The work itself

A Note on What LinkedIn Still Gets Right

To be fair: LinkedIn is still useful for passive job discovery, staying loosely tied to former colleagues, and showing up in recruiter searches. Those aren't nothing, and most builders should keep a presence there for exactly those reasons.

That's also why forg.to doesn't ask anyone to delete their LinkedIn. It lets you cross-post your updates there in one click, so LinkedIn becomes a distribution channel instead of the place where your professional identity is forced to live. Keep the directory listing. Just stop mistaking it for your professional home.

FAQ

What is the best LinkedIn alternative for developers and builders in 2026?
For people whose career is defined by what they ship rather than where they've been employed, forg.to is built specifically for that: a profile structured around products, updates, and proof of work instead of job titles.

Is forg.to trying to replace LinkedIn entirely?
No. Forg positions itself as your professional home, while LinkedIn stays useful as one of several distribution channels — you can cross-post updates from forg directly to LinkedIn, X, and Bluesky in one click.

How is forg.to different from a portfolio site?
A portfolio site is usually built once and forgotten. Forg is a living timeline — every update, milestone, and launch adds to your build history automatically, and your audience grows with the story instead of only seeing a static snapshot.

Why does design matter for a professional network?
Because a professional network is where people form a first impression of your work in seconds. A dated, cluttered interface undersells serious work; a considered one lets the work speak for itself. It's the same reason a well-designed portfolio outperforms a cluttered one — the container shapes how the content is read.

Does forg.to have the same recruiter spam and corporate content as LinkedIn?
No. Forg is built specifically for people building something — a startup, a side project, open-source software — rather than every profession on earth. That narrower audience means the feed stays focused on shipped work instead of hiring announcements, motivational posts, and generic corporate content.

Can I show my GitHub, LeetCode, or content on my forg.to profile?
Yes. Forg renders your GitHub contribution graph, LeetCode and Codeforces solve counts, YouTube videos, and Medium or dev.to articles as interactive widgets directly on your profile, instead of as plain links buried in an about section.

Who is forg.to for?
Developers, designers, indie hackers, founders, and anyone whose most impressive work lives in shipped products rather than a job history — including people with no formal employment history at all.

How AI Search Is Changing Marketing in 2026

Kumar Kislay — Fri, 17 Jul 2026 16:49:30 +0000

Picture this.

You write a brilliant article. It ranks number one on Google. You check your traffic and it is falling anyway.

No penalty. No ranking drop. Just fewer clicks.

Welcome to marketing in 2026.

The Search Landscape Just Flipped

For twenty years, the deal was simple.

Write good content, rank high, get clicks. Traffic meant visibility and visibility meant growth.

That deal has quietly been cancelled.

AI Overviews, AI Mode, ChatGPT Search, Perplexity, Claude. These are not just new tools. They are a structural shift in how people find information. And they are eating traffic that used to flow to your website.

The numbers are hard to look at if you live on organic traffic.

Zero-click searches hit between 58.5% and 68% of all Google searches in 2026. AI Overviews now appear on 48% of search results pages, up 58% year over year. One study from Seer Interactive across 25 million impressions found organic click-through rates have fallen 61% when an AI Overview is present.

The kicker: according to Semrush data, 93% of searches conducted in Google's AI Mode end without a single click to any external website.

Ninety-three percent.

What Actually Happened

Here is the short version of why this happened.

Google introduced AI Overviews in 2024 and AI Mode in 2025. Both formats answer questions directly inside the search results page. The user asks something, gets a synthesised answer, and often never needs to visit a website.

OpenAI launched ChatGPT Search. Perplexity built a full search engine. Microsoft integrated AI into Bing. The result is that people now ask questions to AI systems in natural language rather than typing keywords into Google.

Nearly two-thirds of buyers now start their research using generative AI rather than traditional search.

AI crawlers, including GPTBot, ClaudeBot, and Perplexity Bot, now represent approximately one-third of all organic search activity. These bots do not render JavaScript. They need clean, fast, well-structured content. They have no patience for slow-loading pages or confusing site architecture.

The buyer journey has changed. And most marketing strategies have not caught up.

The Traffic Loss Is Real. So Is the Opportunity.

Before the panic sets in, a few things worth knowing.

First, transactional queries are the least affected. Only around 10% of commercial queries trigger an AI Overview. If someone is searching to buy something, Google still largely shows traditional results. AI search is mostly eating informational traffic, not purchase-intent traffic.

Second, the traffic that AI does send is higher quality. ChatGPT-referred visitors spend an average of 15 minutes on a website versus Google-referred visitors at 8 minutes. Sessions from AI referrals grew 527% year over year in the first five months of 2025.

Third, only 16% of brands are systematically tracking their performance in AI search. That means 84% of your competitors are flying blind. The brands that get serious about this now are locking in positions that will be extremely hard to recover later.

The loss is real. The opportunity for those who adapt is also real.

SEO Is Not Dead. It Mutated.

The phrase "SEO is dead" shows up every two years. It has been wrong every time.

What has changed is the destination of good SEO practice.

Traditional SEO optimised for ranking. Page position one, page position two. Blue links. Click-through rates.

A new discipline called Generative Engine Optimization (GEO) optimises for citation. Not where do you rank in a list of ten links, but do AI systems mention you, quote you, or pull from you when answering questions your customers are asking.

These are different goals and require somewhat different strategies.

The good news: GEO is built on the same foundation SEO always rewarded. High-quality content. Expertise and authority. Trustworthiness. Real sources, real data, real expertise. Google calls this E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) and AI systems are using similar signals to decide whose content to surface.

A Princeton, Georgia Tech, and IIT Delhi joint study found that adding specific statistics, citing credible sources within your content, and using quotes from named experts increased AI citation rates by 30 to 40 percent across tested queries.

Specific beats vague. Every time.

The Zero-Click Is Not Zero Value

Here is the mindset shift most marketers need to make.

Zero-click does not mean zero value.

When your brand appears in an AI Overview or a ChatGPT answer, the user saw you. They did not click. But your brand name was mentioned in the answer to a question they were asking. That is visibility. That is trust signaling. That is brand recall that shows up as direct or branded search traffic days or weeks later.

Similarweb research found that users who encounter a brand in an AI Overview often search that brand name directly later. The branded search spike after zero-click appearances is measurable, it just gets missed by attribution models that only count last-click.

The metric for AI search is not just clicks. It is citation share. Share of voice inside AI-generated answers. Brand mention frequency across ChatGPT, Perplexity, and Google AI Overviews.

If you are not measuring that, you are measuring the old game.

Backlinks Still Matter. Just Differently.

The relationship between backlinks and authority has not disappeared. It has been reframed.

In traditional SEO, a dofollow backlink passed PageRank. Quantity plus quality determined domain authority and domain authority influenced ranking.

In the AI search era, backlinks now serve as semantic bridges.

A link from a relevant, authoritative publication tells AI systems: this site is part of the same topic cluster as this authority source. It is less about voting power and more about topical validation. AI models use backlinks as one proxy for trust, then make their own judgment about whether your content is worth citing based on its depth, specificity, and credibility.

What this means practically: a single dofollow backlink from a genuinely relevant, high-quality source is worth more than fifty links from unrelated directories. Context and relevance now outweigh volume.

This is also why getting your product listed and mentioned across the right platforms matters more than it used to. When a builder launches on forg.to, for example, they receive a free dofollow backlink from a domain in the exact context where their product belongs, a professional network of developers and builders. That kind of contextually relevant link, placed in a community that actually uses tools like yours, does more work than a generic directory listing. It is the right source, in the right context, pointing at the right content.

Unlinked brand mentions also carry more weight than they used to. An AI model reads text, not just link structure. A mention in a respected publication without a hyperlink still contributes to how AI systems understand your brand's authority and relevance.

What Actually Works Now: A Practical Framework

Answer real questions with real depth.

AI systems prefer sources that answer questions comprehensively. Not keyword-stuffed articles. Not thin content padded to a word count. Actual, thorough, useful answers written by people who know what they are talking about.

Write like someone asked you a question in person and you gave them your full, honest, expert answer.

Use structured data and semantic HTML.

JSON-LD structured data, clean heading hierarchies, proper use of lists and tables. AI crawlers parse these signals to categorise and interpret your content. Schema markup is no longer just an SEO nicety. It is how AI systems understand what your content is about.

Get cited in the right places.

Third-party mentions, expert quotes in publications, citations in reports and comparisons. AI models recognize patterns: who discusses a brand, in which contexts, and how frequently. Appearing in the right conversations across trusted sources builds the entity authority that influences citation.

Write for humans using natural language.

People ask AI systems full conversational questions. "What is the best project management tool for a small engineering team?" not "project management tool small team." Your content needs to match that natural language. FAQ sections, question-based headers, specific use-case coverage.

Prioritise E-E-A-T signals.

Author bios that demonstrate actual expertise. First-party research and original data. Expert quotes from named, credible sources. These are the signals both Google and AI systems use to evaluate whether your content deserves to be cited.

Track the new metrics.

Run manual prompts in ChatGPT, Perplexity, and Google AI Overviews. See if and how your brand appears. Monitor branded query impressions in Google Search Console. Watch for unexplained branded search spikes after content publication, that is your zero-click attribution signal. Tools like Profound and Otterly.AI now track LLM mention frequency at scale.

The Ads Are Coming for AI Search Too

Worth mentioning because it changes the competitive landscape.

Google confirmed in 2025 that AI Overviews now include Search and Shopping ads on desktop. AI Mode also shows ads. An educational query about dogs on long flights might now surface a sponsored carrier bag inside the AI answer.

This is Google monetising the zero-click environment it created. Brands that relied purely on organic traffic are now competing for visibility against paid placements inside AI summaries.

It is not a new development conceptually. It is just arriving in a new format.

The practical response is the same as it has always been: build enough organic authority and brand trust that you appear in AI answers regardless of paid competition, while using paid placement strategically for high-intent queries.

Where This Is All Heading

AI search visits grew 42.8% year over year, rising from 15.6 billion in Q1 2025 to 27.4 billion in Q1 2026. The ratio of traditional Google users to AI search users fell from 4.9 to 1 down to 3.5 to 1 in a single year.

The direction is not ambiguous.

Search is not dying. It is fracturing. People are searching more than ever, across more tools than ever: Google, ChatGPT, Perplexity, Claude, Gemini, and whatever comes next.

The marketers who are winning are the ones who stopped asking "how do I rank in Google?" and started asking "how do I become the source AI systems trust?"

Those are related questions but they are not the same question.

The answer to the first is keywords, backlinks, and technical SEO.

The answer to the second is authority, specificity, depth, trust signals, and getting mentioned in the right places by the right sources consistently over time.

That has always been what good marketing actually was.

AI search just made it impossible to fake.

Why Programmers Hate LinkedIn?

Kumar Kislay — Thu, 16 Jul 2026 09:16:08 +0000

Open LinkedIn for five minutes as a developer.

You will see a founder crying about failure in an airport lounge. A recruiter posting "Excited to share that I'm hiring!" for the fourteenth time this week. A motivational quote about hustle printed over a sunset. Three humblebrags disguised as life lessons. One "I'm grateful and blessed" announcement with 4,000 likes.

And somewhere, buried under all of it, maybe one actually useful post.

This is the daily reality of LinkedIn for most programmers. They tolerate it because they feel they have to. They hate it because, honestly, it deserves to be hated.

Here is exactly why.

The Spam Never Stops

The moment you put "developer" in your headline, the messages start.

About 35% of LinkedIn connection requests are followed by aggressive sales messages, according to research from email management company Superhuman. That means one in three people trying to "connect" with you are actually trying to sell you something.

Recruitment spam is worse. You will receive messages for roles you are wildly unqualified for, roles that require seven years of experience in a three-year-old framework, roles where the salary range is "competitive" (which means they will not tell you), and roles that list seventeen required skills for what is clearly a junior position.

Job offers are often missing critical information, with many listings omitting salary ranges or listing an overwhelming number of requirements without clearly explaining what the actual job entails.

Developers have noticed. Only 12% of developers use LinkedIn as their main source of technical information, according to a Stack Overflow survey. Most are on the platform purely because they feel they have no alternative, not because they find it genuinely useful.

The Fake Everything Problem

LinkedIn has a trust problem that is getting dramatically worse, not better.

In the second half of 2024, LinkedIn identified and removed 80.6 million fake accounts at the point of registration, up from 70.1 million in the prior six months. In the first half of 2025, it removed roughly 83.4 million.

Let that sink in. Over 200 million fake accounts removed in a single year. And those are only the ones they caught.

Criminals are now using deepfake technology, AI-generated job descriptions, and automated recruiter bots to convincingly impersonate real companies, real recruiters, and even real HR executives, tricking developers into fake interviews and handing over personal data.

Gartner expects one in four candidate profiles globally to be fake by 2028.

When a quarter of the profiles on a professional network might not be real people, the word "professional" starts to lose its meaning.

The fake content problem runs deeper than just bots. LinkedIn has forced its users to project a facade where a perfect professional is the only persona who succeeds. The result is a platform full of people performing success rather than actually sharing it. Every failure becomes a lesson. Every setback becomes a growth story. Every ordinary Monday becomes an opportunity for a grateful reflection.

There is no measure to check if something is real or not. A developer could add "Frontend Architecture at Google" to their profile and it shows up without any verification.

The Algorithm Is Working Against Developers Specifically

Here is a problem that gets almost no attention but affects every developer on the platform.

LinkedIn's algorithm penalizes external links.

That means every time a developer does what comes naturally, sharing a GitHub repo, linking to a dev.to article, posting about a product they shipped, sharing a YouTube video of a technical talk, the algorithm actively reduces how many people see that post.

Posts are getting shorter, with 800-1,000 characters being the sweet spot, and links still hurt your post.

Think about what this means for developers. The most useful things a developer can share, working code, technical writeups, live products, real contributions, are exactly the things the platform discourages. Meanwhile, vague motivational posts with no external links thrive.

Sponsored content and ads now fill almost 40% of the LinkedIn feed. The organic space left for actual human content is shrinking every quarter.

Reach has dropped approximately 50% year-over-year for most creators according to researcher Richard Van Der Blom's data. Developers who were getting reasonable traction with technical posts two years ago are now getting a fraction of the views for the same quality content.

LinkedIn tracks what they internally call "viewer tolerance," reducing visibility for authors whose posts are consistently ignored. So if your technical posts land with a small but engaged audience, and get scrolled past by the majority of your connections who followed you for other reasons, the algorithm punishes you further.

It is a trap. The more developer-focused your content, the less LinkedIn wants to show it.

The Profile Format Was Built for Someone Else

Now set aside the feed entirely and look at the profile itself.

LinkedIn's profile structure makes complete sense if your career is: company A, then company B, then company C. Employment history. Job titles. Credentials. Start dates and end dates.

It makes very little sense if you are:

A developer with ten shipped side projects and one job
A student who has built three products with real users but no formal work experience
An indie hacker running a profitable SaaS without employees
An open source maintainer whose most important work exists in repos, not on payroll
A developer whose most impressive skills are visible on LeetCode, Codeforces, GitHub, and YouTube, not in a bullet point list

There is no native space for your competitive programming ranking. No place for your LeetCode solve count. No way to surface your dev.to articles or Medium posts as actual content rather than buried links. No integration with your YouTube channel showing your technical talks. No live GitHub contribution graph. No product showcase with real metrics.

To put any of this on LinkedIn, you manually copy-paste links into sections that were not designed for them, hope a recruiter notices, and accept that it looks like an afterthought. Because it is.

LinkedIn was designed for a professional world that runs on employment. It was not designed for builders.

Your Work Is Scattered and That Is a Professional Problem

Here is the thing no one talks about.

Developers today have their professional identity spread across a dozen platforms.

Code lives on GitHub. Competitive programming rankings live on Codeforces and LeetCode. Technical writing lives on dev.to or Medium. Tutorial content lives on YouTube. Product launches live on Product Hunt. Side project metrics live in a Notion doc nobody else can see. Open source contributions are visible on individual repo pages but not aggregated anywhere meaningful.

Ask most developers to send you a link that shows everything they have done professionally and they cannot. They send you their GitHub and hope you click around long enough to figure out the rest. Or they spend a weekend building a personal portfolio site, which they update once and forget.

This fragmentation is not just inconvenient. It actively hurts developers professionally.

A recruiter evaluating you has sixty seconds. If your professional presence requires them to visit four platforms, read three readmes, interpret a contribution graph, and check a YouTube channel, most of them will not bother.

This is the gap forg.to was built to close.

Instead of hunting across platforms, your forg.to profile aggregates everything into one place. Your GitHub activity, your competitive programming profiles from Codeforces and LeetCode, your content from YouTube, dev.to, and Medium, your products, your milestones, your metrics. All visible in one profile, fully customizable, structured the way a builder actually works rather than the way an HR database expects.

A developer profile that surfaces your actual professional identity, not just where you have been employed.

The Cringe Content Problem

Every developer knows this feeling.

You open LinkedIn hoping to find a job, make a connection, or learn something useful. Instead, you scroll through:

A founder revealing the three lessons they learned from almost going bankrupt, written as a dramatic twelve-paragraph essay. A developer announcing they just got their first offer after 847 days of rejection, with crying emojis. A tech lead explaining why "soft skills are actually more important than hard skills" in what is clearly a post optimized for engagement, not truth. An AI-generated post disguised as a personal story, using phrases no human being would naturally say.

Developers are building open source tools, solving problems late at night with no company name behind them, but they find the platform's fake professionalism intolerable.

The content culture on LinkedIn actively rewards performance over substance. Emotional posts that make people feel something outscore technical posts that actually teach people something. This is fine for the platform's engagement metrics. It is useless for a developer trying to find their people or get found by the right opportunities.

The Verification Gap

One of the most specific frustrations developers have with LinkedIn is that nothing is verified.

Anyone can claim any skill. Anyone can claim any job title. Anyone can list any company as their employer. Anyone can list themselves as a React expert, a cloud architect, a machine learning engineer, regardless of whether they have ever written a single line of relevant code.

Endorsements are a joke. Thousands of people have endorsements for skills from connections who have never seen them work. The endorsement system measures social reciprocity, not competence.

For developers specifically, this is maddening. The whole point of working in a field where you can show your code is that the work is verifiable. The GitHub contribution graph is real. The merged pull request is real. The live product is real. The LeetCode rating is earned through actual problem-solving.

None of that verifiability transfers to LinkedIn. It all gets flattened into the same unverified list of self-reported skills.

What Developers Actually Need

The complaints about LinkedIn are legitimate and consistently made. What is less often articulated is what developers actually want instead.

The answer, reading across every developer community that has discussed this, is roughly the same:

A professional home where the work speaks. Where GitHub activity is a first-class signal, not a buried link. Where shipped products are visible alongside the person who built them. Where competitive programming rankings, writing, technical content, and open source contributions all live together in one coherent identity. Where the profile shows what you can do, not just who has employed you.

Where verification comes from the work itself rather than from unchecked self-reporting.

That is a fundamentally different kind of professional profile than LinkedIn offers. And it is what builders increasingly need as the proof-of-work era of hiring takes hold.

Platforms like forg.to exist because LinkedIn was not built for this. Your profile on forg.to connects your GitHub, your Codeforces and LeetCode rankings, your dev.to and Medium articles, your YouTube channel, your products and startups with real metrics, all of it aggregated into a single professional identity that you control and customize. Not a social feed optimized for engagement. A professional record optimized for truth.

The question is not whether LinkedIn is useful. It still is, for some things.

The question is whether it is the right home for your professional identity as a builder.

For most developers, increasingly, the honest answer is no.

A Note on What LinkedIn Gets Right

To be fair: LinkedIn is useful for passive job discovery, for staying loosely connected to former colleagues, and for appearing in recruiter searches.

These are not nothing. Most developers should maintain some presence on LinkedIn for these reasons alone.

But maintaining a minimal presence for discoverability is different from treating LinkedIn as your actual professional home. The platform was not built for builders, does not surface builder-relevant proof of work, penalizes the links and content that matter most to developers, and is increasingly overrun with fake accounts and AI-generated noise.

Use it as a directory listing. Not as the place where your professional identity actually lives.

That place should be somewhere built for people who build things.

The One Command That Halved My Anthropic Bill Overnight

Kumar Kislay — Thu, 02 Jul 2026 12:23:12 +0000

Last month my Anthropic bill was $312. I use Claude Code for 6-8 hours daily across multiple projects. After adding a single line to my shell config, this month's projected bill is $94. Same usage patterns. Same quality of output. Same number of sessions.

The difference: I stopped sending redundant tokens to the API. That is it. No workflow changes. No prompting tricks. No switching to a cheaper model.

Here is the full breakdown of what happened and how you can do the same thing in 60 seconds.

The Setup (Literally 60 Seconds)

pip install copium-ai
copium wrap claude

That is it. Two commands. Now every Claude Code request routes through a local compression proxy before hitting the API. My prompts get 40-80% smaller. Same answers come back.

Where My Tokens Were Going

I ran copium stats --period month after the first week and saw the breakdown:

Most of my wasted tokens came from duplicate file reads (180K → 12K, 93% savings), JSON tool outputs (320K → 64K, 80%), build logs (95K → 14K, 85%), search results (150K → 30K, 80%), conversation history (200K → 140K, 30%), and tool schemas (45K → 8K, 82%). Overall, my daily input dropped from 990K tokens to just 268K, a 73% reduction.

The Cost Breakdown

Anthropic Claude Sonnet pricing:

Input: $3 per million tokens
Output: $15 per million tokens (unchanged by compression)
Cached input: $0.30 per million tokens (90% discount)

My savings come from two sources:

Fewer input tokens (compression)

More cache hits (prefix stabilization)

Daily input tokens dropped from 990K to 268K, while my cache hit rate increased from 12% to 48%. That reduced my effective input cost from $2.90/day to just $0.62/day. Output costs stayed the same at $7.50/day, bringing my total daily cost down from $10.40 to $8.12.

Wait, that is only $68/month savings on raw math. Where does the $200 come from?

The bigger savings: I stay in sessions longer without hitting compaction. Before compression, long sessions hit compaction at 35 turns, forcing context loss and repeated work. Now sessions last 55+ turns productively. Fewer repeated file reads, fewer redundant tool calls, fewer wasted output tokens on re-doing work.

Does Quality Actually Stay the Same?

I was skeptical too. Here is what I measured over 4 weeks:

Code that compiles first try: 78% (before) vs 76% (after) = within noise
Tests passing on first run: 62% vs 60% = within noise
"Agent forgot something" incidents: 4.2/week (before) vs 1.1/week (after) = BETTER

The last metric surprised me. Compression actually IMPROVED context management because the agent's context window was not overflowing with garbage.

What If I Have a Copilot Subscription?

Subscription users do not pay per token directly, but you still benefit:

Longer productive sessions (context does not fill up)
Fewer "I need to start a new chat" moments
Better quality in long sessions

Copium

Copium (http://github.com/iKislay/copium) is open source (Apache 2.0) and runs entirely locally. Your code never leaves your machine. It adds about 50ms of latency per request, which is invisible compared to the 2-30 second LLM response time.

The key features that matter for cost savings:

Zero-config proxy (copium wrap <agent>)
Session deduplication (catches repeated file reads)
SmartCrusher (compresses JSON tool outputs 70-90%)
Progressive tool disclosure (reduces schema tokens 75-95%)
Cache alignment (increases provider cache hits 3-4x)
Quality gate (auto-reverts if compression hurts quality)

Quick ROI Calculation

Time to set up: 60 seconds

Monthly cost of tool: $0 (open source)

Monthly savings: $150-200 (per developer)

Payback period: Immediate

There is no reason not to try it. If it does not help your workload, copium unwrap claude removes it in one command.

Tool: http://github.com/iKislay/copium

Your Resume Gets You Seven Seconds. Here's What Gets You Twenty Minutes.

Kumar Kislay — Tue, 30 Jun 2026 06:13:03 +0000

A few years ago, every career conversation started with one question.

"Can you send me your resume?"

In 2026, that question is slowly changing.

The Story

Last week, a friend of ours who works in HR at a startup in Kolkata came across two fresher profiles for the same role.

Same year of graduation. Similar coursework. On paper, nearly identical.

Candidate A had a beautifully designed two-page resume. Every section polished. Every skill listed. Every achievement quantified. The kind of resume that looks like it took hours to format.

Candidate B had a simple resume. Nothing fancy. But alongside it, there was a profile.

Not a beautifully designed personal website. Just real work, laid out clearly. Projects that could be clicked and tried. Problems that were actually solved, with the reasoning behind them. Code that could be reviewed. An article that had been published. A small tool with real users.

The recruiter spent less than a minute on Candidate A's resume.

She spent nearly twenty minutes on Candidate B's profile.

What Actually Happened There

Resumes tell people what you've done.

Profiles show people what you can do.

That difference sounds small. It is not. One is a claim. The other is evidence. And recruiters, whether they admit it or not, trust evidence far more than claims.

This is not a new idea. It is just becoming impossible to ignore.

A resume can say "built scalable systems," "led cross-functional projects," "delivered measurable impact." Every resume says some version of this. It has become noise. Recruiters have read the same five phrases ten thousand times.

A profile does not make claims. It shows the thing. The recruiter clicks, sees it work, reads the reasoning, and forms a judgment based on something real. That is a fundamentally different kind of trust.

Does This Mean Resumes Are Dead?

No. And we want to be honest about that.

A resume is still your entry ticket. It helps a recruiter quickly understand your background, your timeline, your basic qualifications. It is fast, structured, and familiar. Nobody is suggesting you delete it.

But here is the part that has genuinely shifted.

In a world where AI can generate a polished, keyword-optimized, perfectly formatted resume in about ninety seconds, the resume alone has stopped being a differentiator. Everyone's resume looks competent now. That is exactly the problem. Competent and identical is not a signal anymore.

What cannot be generated by a prompt is your actual track record. Your GitHub history. The product you shipped and the users who actually use it. The case study explaining a hard decision you made and why. The blog post that shows how you think. The side project you built because something annoyed you and you fixed it.

These are becoming stronger signals than a list of bullet points, because they cannot be faked the way a sentence can.

Why This Matters More for Builders Specifically

If you are a developer, a designer, a founder, or anyone building things in tech, you are in an unusually good position here. Most professions cannot show their actual work easily. Developers can. You can deploy something for free, document it properly, and let anyone in the world click through it.

The problem most builders have is not a lack of proof of work. It is that the proof is scattered.

A project here. A GitHub profile there. A blog post somewhere else. A startup update buried in an old LinkedIn post. None of it connected. None of it presented as a coherent professional identity. A recruiter or collaborator has to do the work of stitching these fragments together, and most of them will not bother.

This is the exact gap Forg was built to close.

A forg.to profile is not a resume and it is not a static portfolio site you build once and forget. It is a living professional record. Your products. Your milestones. Your shipped work, verified metrics, and ongoing activity, all in one place that updates as you build. The kind of profile that, if a recruiter landed on it, would hold their attention for twenty minutes instead of forty seconds.

That is the entire premise. Not where you've worked. What you've built.

The Real Answer Is Not Either/Or

In 2026, the strongest combination is not resume versus profile.

It is resume plus profile.

One gets you noticed in the first seven seconds of a scan. The other gets you remembered for the twenty minutes after that, and it is the twenty minutes that actually decide whether you get the call.

Builders who understand this are not abandoning their resumes. They are pairing a clean, simple resume with a living record of what they have actually built, hosted somewhere a recruiter can explore it without friction.

That pairing is the new baseline. Not the exception. The expectation.

What's Your Take?

If you had to pick only one today, resume or profile, which would you choose?

We think the better question is why you are still choosing.

Build the profile. Keep the resume. Let your work speak for the twenty minutes your resume can never earn on its own.