DEV Community: Rijul Rajesh

AI Models Can Learn from Data. But What Can They Learn from Other Models?

Rijul Rajesh — Fri, 16 Oct 2026 05:23:40 +0000

Hello, I'm Rijul, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.

Imagine you've trained a huge AI model that is very good at its job, such as recognizing objects in photos or answering questions.

But there's a problem. The model is enormous. It needs powerful servers, costs a lot to run, and may be too slow or too large for a phone, smartwatch, or car.

You want a smaller model that performs almost as well but runs faster and costs less.

One option is to train a small model from scratch using your original data. However, it may not reach the same level of performance as the larger model.

Knowledge distillation offers another approach. Instead of learning only from the original data, the smaller model also learns from the larger model, much like a student learning from a teacher rather than studying a textbook alone.

Let's see how it works.

1. The Teacher and the Student

Think about two ways of learning mathematics.

In the first, you get a textbook containing problems and their final answers.

In the second, you also have a tutor who explains how they approach each problem. The tutor might show you that one problem resembles another, even though the answers are different.

The second approach gives you additional information that can help you learn.

Knowledge distillation applies a similar idea to AI models:

Teacher model: The larger model that already performs well.
Student model: The smaller model that learns from the teacher.

The teacher provides additional learning signals that help the student reproduce some of its capabilities.

2. Learning from More Than the Correct Answer

Let's say we have an AI model that classifies animal photos into three categories:

When the model receives a photo of a cat, it produces a score for each category. These scores are called logits. A function called softmax can convert them into probabilities that add up to 100%.

For example, the teacher might produce these probabilities:

Class	Probability
Cat	90%
Dog	9%
Fox	1%

The teacher predicts cat because it assigns the highest probability to that class.

But notice something else: it considers dog more likely than fox.

Those smaller probabilities provide additional information about how the teacher distinguishes between the categories.

Hard labels vs. soft labels

In ordinary supervised classification, the training target might be a hard label:

Cat = 100%, Dog = 0%, Fox = 0%

This tells the model which category is correct, but it doesn't directly communicate how the other categories compare.

The teacher's output, on the other hand, gives us a distribution:

Cat = 90%, Dog = 9%, Fox = 1%

These are called soft labels. They provide information about the teacher's relative confidence across all three categories.

The teacher is effectively saying, "This is a cat. Dog is less likely, but fox is even less likely."

This information can help the student learn distinctions that a simple correct-or-incorrect label doesn't express.

Geoffrey Hinton and his colleagues popularized the term dark knowledge for the useful information contained in a teacher's output probabilities, particularly the information in the less likely alternatives.

The key idea is:

Train the student to learn from the teacher's full probability distribution, not just the correct answer.

3. Making the Hidden Information Easier to See: Temperature

There's a problem with the example above.

Imagine the teacher is extremely confident and produces these probabilities:

Class	Probability
Cat	99.9%
Dog	0.09%
Fox	0.01%

The probabilities for dog and fox are tiny. The difference between them may provide a useful learning signal, but the teacher's output is dominated by the cat prediction.

This is where temperature comes in.

Temperature, usually represented by (T), controls how soft or sharp the probability distribution becomes when softmax is applied to the teacher's logits.

T = 1: The usual softmax distribution.
Higher temperature: The probabilities become more evenly distributed, making the differences between less likely classes easier to observe.
Lower temperature: The distribution becomes sharper, giving more weight to the highest-scoring class.

For example, with a higher temperature, the teacher might produce a distribution like this:

Class	Illustrative probability
Cat	70%
Dog	22%
Fox	8%

These numbers are illustrative, not a guaranteed result of a particular temperature.

The important point is that the ranking remains the same, while the probability distribution becomes softer.

The student can now receive a more informative signal about how the teacher relates the different classes.

4. How the Student Actually Learns

The student needs to learn two things:

How to imitate the teacher.
How to predict the correct answers from the original training data.

During training, these goals can be combined into a single loss function.

A. Match the teacher

First, the student produces its own probability distribution using the same temperature.

The training process compares the student's softened probabilities with the teacher's softened probabilities.

One way to measure this difference is KL divergence. It measures how different two probability distributions are.

The student is trained to reduce this difference, making its outputs more similar to the teacher's.

B. Match the correct labels

The student is also trained using the actual labels in the dataset.

For example, if the image contains a cat, the student should still learn that cat is the correct category.

This is commonly done using cross-entropy loss, a standard method for training classification models.

C. Combine both learning signals

The two losses can be combined using a weighted sum:

Distillation loss: Encourages the student to imitate the teacher.
Label loss: Encourages the student to predict the correct answers.

The weights determine how much each objective contributes to training.

This combination helps the student learn from both the teacher's behavior and the original training labels.

5. The Knowledge Distillation Process

Here's the overall workflow:

Prepare the teacher: Train a large model or use an existing one.
Choose the student: Select a smaller model architecture suitable for your use case.
Prepare the training data: Run the examples through the teacher to obtain its outputs.
Train the student: Use the teacher's outputs and the original labels to calculate the training loss.
Deploy the student: Once training and evaluation are complete, use the smaller model for inference. The teacher usually isn't needed during deployment.

The result is a student model that aims to retain as much of the teacher's useful behavior as possible while requiring fewer resources.

6. Does Knowledge Distillation Really Work?

Yes. One well-known example is DistilBERT, a smaller version of BERT developed by Hugging Face.

According to its creators, DistilBERT is approximately 40% smaller and 60% faster than BERT while retaining around 97% of its language-understanding capabilities on the evaluated benchmarks.

These figures describe that particular model and evaluation setup. Results vary depending on the teacher, student architecture, training data, and task.

Knowledge distillation is also relevant to large language models.

A smaller language model can be trained using outputs generated by a larger model. This is one form of learning from a teacher, although the exact methods differ from probability-based distillation used in classification.

For example, a larger model might generate answers to a collection of questions. Those answers can then be used as training examples for a smaller model.

This can help transfer some of the larger model's capabilities into a model that is cheaper to run.

However, distillation doesn't guarantee that the student will match the teacher. The quality of the training data, the student architecture, and the distillation method all matter.

Conclusion

Knowledge distillation is a way to transfer useful behavior from a larger AI model to a smaller one.

Instead of learning only from the correct answers, the student can also learn from the teacher's output probabilities or other signals. This gives the student additional information about how the teacher approaches a task.

The goal is to preserve as much useful performance as possible while reducing the cost and resources needed to run the model.

In simple terms, knowledge distillation helps a smaller model learn to do more with less by learning from a larger model.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Risk-Aware AI Code Review for Business-Critical Systems

LiveReview: Risk-Aware AI Code Review for Business-Critical Systems

LiveReview is built for engineering teams that ship often, but also care about keeping production stable for customers. It approves some 40-50% of low-risk changes automatically, and it gives your team the tools to handle the rest:

Understand risky changes faster.

Fix problems in those changes, with human attention directed to the work that needs it.

Enforce your engineering standards.

Learn from production outcomes, such as incidents, rollbacks, and queue wait times.

Improve the review process over time and make it more efficient.

Connect to the major engineering tools that your team already uses.

Auto-Approve: Ship the Safe 50% Without a Human

Auto-Approve Upto 50% of Your Pull Requests, Safely. Risk scoring decides which MRs/PRs are safe enough to ship without a human, so your team only spends review time on risky and critical changes.
demo.mp4
LiveReview auto-approving a low-risk change while…

View on GitHub

Click below to try LiveReview with your codebase:

OpenCode Can Write Code. What If It Could Use Your Browser Too?

Rijul Rajesh — Wed, 14 Oct 2026 05:12:41 +0000

We use AI agents for all sorts of tasks. Some agents can even interact with your browser and act as companions while you work.

As someone who uses OpenCode, I wanted to bring that capability into my workflow. I wanted OpenCode to interact with my browser so it could access the relevant browser context while helping me with tasks.

In this article, let's see how to connect your browser to OpenCode using Browser MCP.

1. What You Need

To set this up, you need two components:

Browser extension: Connects your browser to the MCP server.
Local MCP server: Allows your AI client to interact with the browser through the Model Context Protocol (MCP).

Let's set them up.

2. Install the Browser Extension

First, visit the following page to install the Browser MCP extension:

https://browsermcp.io/install

After installing the extension, you'll be directed to a page with more information.

This page links to the official Browser MCP documentation, where you can find additional setup instructions and details about how it works:

https://docs.browsermcp.io/

3. Add the MCP Server to OpenCode

Next, configure OpenCode to use the Browser MCP server.

Open your OpenCode configuration file and add the following configuration:

    {
      "$schema": "https://opencode.ai/config.json",
      "mcp": {
        "browsermcp": {
          "type": "local",
          "command": ["npx", "-y", "@browsermcp/mcp@latest"]
        }
      }
    }

This configuration tells OpenCode to start the Browser MCP server locally using npx.

Save the configuration after adding it.

4. Connect and Test the Browser

Once you've configured the MCP server, make sure Browser MCP is connected.

Now, let's test whether it works.

Go to OpenCode and give it a task that requires browser interaction. For example:

    Go to the Wikipedia page for "Open-source software" and list the main section headings.

The Browser MCP server allows OpenCode to interact with the browser and navigate to the requested page.

Here's the result returned by the agent.

As you can see, OpenCode can use the browser to complete the task instead of relying only on the information already available in the conversation.

Conclusion

That's how you can connect Browser MCP to OpenCode.

This setup lets you bring browser interaction into your AI-assisted workflow. Instead of working with your AI agent and browser separately, you can give OpenCode tasks that involve navigating web pages and gathering information through the connected browser.

It can be useful when you want your AI coding assistant to work with relevant information from the web alongside your existing workflow.

That's it for this article. See you in the next one!

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Risk-Aware AI Code Review for Business-Critical Systems

LiveReview: Risk-Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box Visualize blast radius at a glance Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:

A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.

A 300-line UI change in one file, fully covered by tests…

View on GitHub

Click below to try LiveReview with your codebase:

AI Generates Text One Token at a Time. But How Does It Know When to Stop?

Rijul Rajesh — Tue, 13 Oct 2026 03:18:29 +0000

A language model generates text one token at a time. But how does it know when to stop?

It doesn't understand completion in the same way a human does. Instead, it learns patterns that help it predict when a response should end. Special tokens, instructions, and generation settings all play a role in this process.

Let's explore how it works.

1. How a Model Generates Text

Each time a language model generates text, it predicts the next token based on the tokens that came before it.

A token can represent a word, part of a word, punctuation, or another piece of text. The model assigns probabilities to possible next tokens and selects one according to its generation settings.

One possible token is a special marker that signals the end of generation. This is commonly called an end-of-sequence (EOS) token. Depending on the model, it might look like </s> or <|endoftext|>.

When the model generates an EOS token, generation normally ends. In chat models, a separate end-of-turn token may serve this purpose by indicating that the assistant has finished its response.

2. How a Model Learns to Stop

During training, models learn to predict the next token from examples of text. Special tokens are included in the training data to mark boundaries, such as the end of a sequence or a conversational turn.

For example, a training sequence might look like this:

User: What is the capital of France?
Assistant: Paris. [end-of-turn token]

By learning from many examples, the model learns when these ending tokens tend to appear.

After generating a complete answer, the model may assign a high probability to an ending token. However, the model does not explicitly verify that it has answered the question correctly or included every necessary detail. It predicts the next token based on patterns learned during training.

The exact behavior depends on how the model was trained and which ending tokens it uses.

3. What Influences When a Model Stops?

Several factors influence whether a model generates another token or ends its response.

Context

The model uses the preceding text to predict what should come next. If the response resembles patterns associated with a completed answer, an ending token may become more likely.

However, a response can appear complete to a reader without the model actually selecting an ending token.

Instructions

Instructions such as "Answer in one sentence" or "Keep your response under 100 words" can influence the length of the generated response.

Fine-tuning methods, including reinforcement learning from human feedback (RLHF), can also shape how a model responds and when it tends to finish.

These factors influence the model's behavior, but they do not guarantee a particular response length.

Sampling settings

Generation settings affect how the model selects its next token.

Temperature: Adjusts how strongly the model favors higher-probability tokens over lower-probability ones.
Top-p: Restricts sampling to a set of tokens whose cumulative probability reaches a specified threshold.

These settings can affect whether an ending token is selected, particularly when it competes with other plausible next tokens.

4. External Conditions That Stop Generation

Not every response ends because the model generates an ending token. The application running the model can also stop generation.

Common external stopping conditions include:

Maximum token limit: The application sets a maximum number of tokens the model can generate. Once the limit is reached, generation stops even if the response is incomplete.
Stop sequences: The application can specify text sequences that trigger a stop when detected. For example, an application might stop when it encounters "\n\nUser:".
Context window limits: The model can only process a limited amount of text at once. If the available context or generation capacity is exhausted, the application may be unable to continue generating.

These mechanisms are different from the model selecting an EOS token. They are stopping conditions imposed by the model's runtime or application.

5. Common Stopping Problems

Understanding the difference between model-generated endings and external stopping conditions helps explain several common problems.

Rambling or repetitive responses

The model continues generating because it keeps predicting additional tokens instead of selecting an ending token. It may repeat earlier points, introduce unnecessary details, or continue beyond what the user needs.

Premature stopping

The model generates an ending token before fully answering the question. This can happen even when the response is incomplete because the model predicts that the sequence should end.

Truncation

The application reaches its maximum generation limit and stops the response. The output may end mid-sentence, making it appear as though the model decided to stop on its own.

The distinction matters: premature stopping comes from the model's generated ending, while truncation occurs because an external limit was reached.

Conclusion

A language model does not have a reliable, human-like understanding of when an answer is complete. It learns patterns that help it predict when to generate an ending token, while instructions and sampling settings influence its behavior. External limits can also stop generation independently of the model's predictions.

This distinction matters when building AI applications. If a model stops too early, users may receive incomplete answers. If it continues for too long, it can increase token usage, latency, and cost.

Understanding these mechanisms helps developers configure generation settings, choose appropriate token limits, and diagnose whether a response ended because the model generated an ending token or the application stopped it.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview: Risk-Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box Visualize blast radius at a glance Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:

A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.

A 300-line UI change in one file, fully covered by tests…

View on GitHub

Click below to try LiveReview with your codebase:

Jev Can Make Decisions. But How Do You Work With It?

Rijul Rajesh — Sat, 10 Oct 2026 21:04:19 +0000

In the previous article, we explored the basic concepts behind Jev and its three decision types: Choice, Score, and Noul.

Now, let's look at how to work with Jev more effectively. We'll cover the kind of input it accepts, how to structure a request, how multiple questions are evaluated, and how to design Choice questions that avoid forced or misleading answers.

1. Understanding State

In Jev, state is the information the model uses to evaluate your questions.

A state can be provided in three formats:

String: Plain text, such as a customer message or incident report.
JSON object: Structured information containing fields such as an order ID, customer status, or error message.
Array: A collection of context items that provide information for a decision.

For example, a customer support application might provide this state:

{
  "customer_message": "My payment failed, but I was charged twice.",
  "account_status": "active",
  "previous_contact": "No previous complaints"
}

Jev can use this information to answer questions about the customer's issue, account, or next steps.

However, Jev is a text-based model. It does not directly accept images, audio, video, or other binary inputs as state. If your application receives these formats, you need to extract relevant information into text or structured data before sending it to Jev.

2. Understanding Request Anatomy

A Jev request consists of three main components:

model: The Jev model you want to use.
state: The information the model should evaluate.
questions: A map of named questions you want answered.

Each question has its own identifier and definition. The identifier helps your application locate the corresponding answer in the response.

Here's an example:

{
  "model": "jev-latest",
  "state": {
    "customer_message": "My payment failed, but I was charged twice."
  },
  "questions": {
    "issue_type": {
      "type": "choice",
      "instructions": "What is the primary issue?",
      "criteria": {
        "billing": "Payment failures, duplicate charges, or refunds",
        "technical": "Application errors or technical failures",
        "account": "Account access or account management issues",
        "other": "The issue does not fit any of the other categories"
      }
    },
    "needs_follow_up": {
      "type": "noul",
      "instructions": "Does this customer need a follow-up from support?"
    }
  }
}

In this example, the request contains two questions about the same customer message.

The first uses Choice to classify the issue. The second uses Noul to evaluate whether follow-up is needed.

Notice that each question has its own type and instructions. Choice uses a criteria field to define the available options. Score uses criteria to define an ordered scale, while Noul can evaluate a yes-or-no question without requiring criteria.

This structure lets you define multiple decisions in one request rather than making a separate request for every question.

3. Parallel, Independent Evaluation

Jev can evaluate multiple questions in the same request. However, each question is evaluated independently against the shared state.

This means one question does not receive another question's answer as additional context.

Consider an AI agent that needs to process a customer support ticket. You might want it to:

Identify the issue type.
Determine its severity.
Decide whether it needs human intervention.

You can ask all three questions in one request. But the severity question cannot use the answer from the issue classification question, and the escalation question cannot inspect the severity answer.

Each question evaluates the original state independently.

Why does this matter?

Suppose your application should escalate a ticket when its severity reaches the high-severity threshold.

You cannot assume that asking Jev to classify the issue and score its severity will automatically connect those answers. Instead, your application needs to combine the returned values and apply the escalation rule.

For example, if your Score scale defines 2 as the severe level:

# Example scale: 0 = minor, 1 = moderate, 2 = severe
if severity >= 2:
    escalate_to_human()

Here, the application makes the final decision using the returned score. If the scale allows values between defined levels, establish and test the threshold against representative examples before using it in production.

If a later question genuinely depends on an earlier answer, use a second request with the relevant result included in its state. Alternatively, combine independent answers in your application code when a second model evaluation is unnecessary.

The key principle is to separate evaluating individual questions from combining their answers into a workflow.

4. Designing Better Choice Questions

Choice is useful when you need to select one answer from a predefined set of options.

However, the quality of the result depends partly on how you define those options.

Consider this example:

{
  "type": "choice",
  "instructions": "What is the primary issue?",
  "criteria": {
    "billing": "Payment failures or duplicate charges",
    "technical": "Software bugs or application errors",
    "account": "Login or account access problems"
  }
}

What happens if a customer asks about a shipping delay?

None of these options fits the issue. Without a suitable fallback, the model may still select one of the available options, producing a misleading classification.

Include an "other" or "none" option

When your predefined choices might not cover every possible input, include a fallback option.

For example:

{
  "type": "choice",
  "instructions": "What is the primary issue?",
  "criteria": {
    "billing": "Payment failures or duplicate charges",
    "technical": "Software bugs or application errors",
    "account": "Login or account access problems",
    "other": "The issue does not fit any of the categories above"
  }
}

Now, the application has an option for issues that fall outside the expected categories.

This is especially useful when processing real-world data, where customer messages and other inputs may not always fit neatly into predefined classifications.

Make the options distinct

A fallback option is only one part of good question design. The other options should also be clearly distinguishable.

For example, if both billing and account include subscription problems, Jev may have difficulty distinguishing between them.

Define each option in terms of what it covers, and avoid unnecessary overlap. If two options represent different outcomes, their descriptions should make that difference clear.

Remember that Choice selects from the options you provide. It does not automatically expand the list when an unexpected case appears.

Wrapping Up

Working with Jev involves more than choosing between Choice, Score, and Noul. You also need to structure the state, define each question clearly, and understand how the answers relate to one another.

Keep these principles in mind:

Provide the relevant context through a string, JSON object, or array of context items.
Give every question clear instructions and the appropriate criteria.
Treat questions in the same request as independent evaluations.
Combine their answers in your application when a workflow requires multiple decisions.
Include an other or none option when your Choice categories may not cover every case.

With these basics in place, you can build more controlled decision workflows around Jev while keeping the application logic under your control. Clear instructions and well-defined options can help, but they do not guarantee correct decisions. Evaluate your workflow against labelled examples before deployment, and continue monitoring its performance as real-world inputs change.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview: Risk-Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box Visualize blast radius at a glance Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:

A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.

A 300-line UI change in one file, fully covered by tests…

View on GitHub

Click below to try LiveReview with your codebase:

AI Can Generate Paragraphs. But What If You Just Need a Decision? Meet Jev

Rijul Rajesh — Fri, 09 Oct 2026 17:56:47 +0000

There’s a new AI model that’s been getting people talking, and you might have heard of it. It’s called Jev.

But what exactly is Jev, and what makes it different from the general-purpose LLMs we use every day?

Let’s take a look at what Jev is all about.

Jev is an AI model from TypeSafe AI designed to make structured decisions rather than generate long-form text.

To understand why it exists, let's start with a simple problem.

Imagine you're building an application that receives 100,000 customer messages. For every message, your application needs to decide:

Is this a billing problem?
Is this a technical problem?
Is this an account problem?

You could send every message to a general-purpose LLM like GPT and ask it to classify each message. But you're using a model capable of writing essays and generating code just to select one of three options.

Jev is designed for this narrower kind of task: making decisions based on the information provided.

Three Things Jev Can Answer

Jev provides three types of decisions called Choice, Score, and Noul.

1. Choice

Which option is correct?

Input: "My payment failed, and I was charged twice."
Options: billing, technical, account
Example output: billing

This is useful when you need to classify information into a predefined set of options.

2. Score

How well does this fit a defined scale?

Input: "The production service is down for every customer."
Scale: 0 = minor, 1 = moderate, 2 = severe
Example output: 2

This is useful when you need to evaluate something against a predefined scale.

3. Noul

How likely is a particular statement to be true?

Input: "The production service is down."
Question: "Does this incident require immediate escalation?"
Example output: 0.95, meaning a 95% estimated probability of a positive answer, assuming the output represents a calibrated probability.

This is useful when you need a structured answer to a specific question rather than a long explanation.

Take Jev for a Spin

The fastest way to try it is through the Jev Playground.

Go to https://jevplayground.com/.

It's an independent playground where you can experiment with Jev.

Choice

Score

Noul (Boolean)

Wrapping Up

So, that's Jev.

For decision-based tasks in an AI agent, Jev could be an option to consider instead of relying entirely on general-purpose LLMs. Using a model designed for structured decisions can help diversify your setup and may make specific decision-making tasks more efficient.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview: Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box Visualize blast radius at a glance Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:

A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.

A 300-line UI change in one file, fully covered by…

View on GitHub

Click below to try LiveReview with your codebase:

What Makes a 3D Model Move? Understanding Animation Basics in Blender

Rijul Rajesh — Wed, 07 Oct 2026 06:56:53 +0000

In this article, we will explore how you can animate anything in Blender.

Before that, we need to understand an important concept called keyframes.

What Is a Keyframe?

Suppose you want to animate a cube by moving it from point A, to point B, and then to point C.

There are three points where we want the cube to move.

In software like Blender, we can set these positions as keyframes.

When the animation is played, Blender calculates the movement between these keyframes, creating the in-between animation as the cube moves from point A to point B and then to point C.

Let's start keyframing.

How to Add a Keyframe in Blender

First, select the object you want to animate. For this simple example, I will select a cube.

Now press I to insert a keyframe.

Once you have inserted it, you can see the keyframe in the timeline below.

Creating a Simple Moving Animation

Let's start with a simple moving animation.

I want to animate the cube moving along the X axis.

In the timeline, you can see that the first keyframe is placed at the 0th frame.

My goal is to make the cube move towards the right by the end of the 10th frame.

I have moved the playhead to the 10th frame.

Now go to the cube, press G, and then X to move it along the X axis.

If you notice, on the right, you can see Location X highlighted in orange.

This means the change has not been added as a keyframe yet.

So let's apply it by pressing I.

Now the keyframe is added, and the orange turns yellow, indicating that a keyframe has been added.

Let's play our newly created animation.

Move the playhead back to the beginning and press play.

The block has come to life.

Animating a Rigged Model

Now let's try animating a rigged model.

I rigged this model in my previous article.

I want to make him wave.

So I select his lower arm and add a keyframe.

Now, after 10 frames, I want to move his arm a bit.

So I select the bone and rotate it after 10 frames.

After that, I have to mark the keyframe by pressing I.

Again, I need to create a back-and-forth effect. In the 20th frame, I rotate his arm to the rightmost position.

One back-and-forth movement is done.

If I want to move his hand back to the left, I don't need to rotate it manually. I can simply copy the keyframe from frame 10 and paste it into frame 30.

Let's play the animation now.

Wrapping Up

So this is the basic idea behind animation in Blender.

We alter the position, rotation, scale, or other properties of an object, mark the changes as keyframes in the timeline, and Blender creates the animation between them.

See you in the next article.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview: Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box Visualize blast radius at a glance Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:

A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.

A 300-line UI change in one file, fully covered by…

View on GitHub

Click below to try LiveReview with your codebase:

How Do You Bring a 3D Character to Life? 6 Steps to Rigging in Blender

Rijul Rajesh — Tue, 06 Oct 2026 05:55:32 +0000

In this article, I'll show you how to rig a character model in Blender.

You can imagine rigging like adding a skeleton inside a character. The bones give you something to control so you can move different parts of the model and eventually animate it.

So, rigging is essential when you want to move parts of a character around or animate it.

I'm starting with a simple character model here.

Add the First Armature

First, we need to add an armature.

Press Shift + A to add a new object.

Then click Armature.

We have added a bone now.

I want the bone to always be visible, so click the bone, go to Data, open Viewport Display, and check In Front.

Understanding a Bone

A bone has three main parts:

Head
Body
Tail

Now let's move this bone into the torso.

Press Tab to go into Edit Mode.

Select the bone and press S to scale it down.

Then press G to move it up.

The bone now becomes the first bone in the torso.

Building the Spine

Let's add the second bone.

Select the tail of the bone and press E to extrude.

Now let's add the neck.

Press E to extrude again.

Repeat the same process for the head.

Adding the Arms and Hips

Now let's add the arms.

Extrude the bones like before, and you can get something like this.

Let's add the hips now.

We now have the bones on one side, but we need the same structure on the other side.

Click this button to apply the changes to the matching bones on the opposite side of the axis.

Naming the Bones

We also need to name our bones properly.

A common naming convention is:

bone_name.l

Here, .l stands for left.

Select the bone, press F2 to rename it, and follow the naming convention.

After renaming the bones, select the entire armature by pressing A.

Then right-click and press Symmetrize.

We now have the same changes on the other side.

Adding the Legs

Now let's create the legs just like before.

Switch between the views to get better positioning.

Parenting the Model

We now need to attach the bones to the body.

Switch to Object Mode.

First, select the body, and then select the bones.

Press Ctrl + P.

Then click With Automatic Weights.

This tells Blender to automatically determine how the character's mesh should move when we move the bones.

Time to Pose

Now let's see if our rig actually works.

Click the armature and switch to Pose Mode.

You can use Ctrl + Tab to switch modes.

Now select any bone and change the pose.

For example, select the upper arm, press R, and rotate it.

You can now try out different poses with the rig.

And with that, our basic rigging is complete.

You can pair this up with animations as well.

See you in the next article.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview: Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box Visualize blast radius at a glance Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:

A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.

A 300-line UI change in one file, fully covered by…

View on GitHub

Click below to try LiveReview with your codebase:

Just Started Blender? Here Are 10 Shortcuts You Actually Need

Rijul Rajesh — Mon, 05 Oct 2026 04:34:32 +0000

Blender is a world full of shortcuts. Even in tutorials, we're often expected to quickly get used to them.

But it's good to have some of the essentials in one place so you can refer back to them from time to time.

So here are 10 basic Blender shortcuts.

1. Navigate the Viewport: Middle Mouse Button

The viewport is what you currently see on the screen.

Before you can build anything, you need to look around.

Orbit: Hold the middle mouse button and drag.
Pan: Shift + middle mouse drag.
Zoom: Scroll the mouse wheel (or Ctrl + middle mouse drag).

2. Jump Between Views: Numpad 1, 3, 7, 0

In this 3D view, if you only want to view along a certain axis, there are shortcuts for that.

The numpad gives you instant standard views:

1: Front
3: Right side
7: Top
0: Camera view

If your keyboard doesn't have a numpad, or you're having difficulty remembering these, just use the backtick key (`). It will bring up a pie menu.

3. Add Something: Shift + A

If you want to add anything new, just press Shift + A.

This opens the Add menu, where you can create meshes, lights, cameras, and more. Hover over Mesh and pick a cube, sphere, or monkey. Yes, Blender includes a monkey head called Suzanne, and she is a tradition.

4. Move, Rotate, Scale: G, R, S

These three are the heart of Blender. Select an object, press the key, and then move your mouse:

G: Grab (move)
R: Rotate
S: Scale

Click to confirm, or right-click/Esc to cancel. You can also type numbers. For example, G then 5 moves the object 5 units.

5. Lock to an Axis: X, Y, Z

Combine the shortcuts above with an axis key to constrain the movement. G then Z moves the object only up and down. R then Z then 90 rotates it exactly 90 degrees around the vertical axis.

Press Shift + X (or Y/Z) to move along the two other axes instead. This one habit will make your work much cleaner.

For example, I pressed S and then Z, so it scaled the model along the Z axis, making it appear elongated.

6. Switch Modes: Tab

Tab toggles between Object Mode, where you're working with whole objects, and Edit Mode, where you reshape the mesh itself.

In Edit Mode, press 1, 2, or 3 to switch between selecting vertices, edges, and faces. Go and open a cube, press Tab, and start pulling the corners around. This is where modeling really begins.

When I press 1, I can select the vertices.

When I press 2, I can select the edges.

When I press 3, I can select the faces.

7. Extrude: E

In Edit Mode, select a face and press E, then move your mouse. The face pulls out into new geometry, like stretching a box into a tower.

It's one of the most-used modeling tools, and you can build surprisingly complex shapes with extrusion alone.

8. Cut New Edges: Ctrl + R

The Loop Cut tool adds a ring of edges around your mesh. Hover over the model in Edit Mode, press Ctrl + R, scroll to add more cuts, and click to confirm.

It gives you extra geometry to shape fine details like the bend of a knee or the edge of a window.

9. Change How You See It: Z

Press Z to open the shading pie menu. Switch between Wireframe, Solid, Material Preview, and Rendered views.

Wireframe lets you see through your model, while Rendered gives you a preview of the final look. It's a great way to explore what Blender can do early on.

10. Search for Anything: F3

This one is very handy. Even if you forget the other nine, this one can save you.

Can't remember where a tool is, or what its shortcut is? Press F3 and type what you're looking for. Blender searches through its menus and operators for you.

It's the best safety net for beginners because you never need to hunt through menus again.

A Few More Bonus Shortcuts

Ctrl + Z: Undo
Shift + D: Duplicate
X: Delete
A / Alt + A: Select all / deselect all
F12: Render an image

Wrapping Up

There is no pressure to memorize everything at once. Practice making some basic shapes, and these shortcuts will become second nature.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview: Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box Visualize blast radius at a glance Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:

A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.

A 300-line UI change in one file, fully covered by…

View on GitHub

Click below to try LiveReview with your codebase:

I Gave AI Access to Blender. Here's What It Built

Rijul Rajesh — Mon, 28 Sep 2026 19:49:27 +0000

We see MCPs being used for a wide variety of tasks.

But have you imagined how they can help with software like Blender?

Let's take a look.

This is the repository:

https://github.com/ahujasid/mcp-for-blender

This is a plugin that lets you control Blender with any LLM of your choice. You can prompt the LLM, and Blender can act accordingly.

Which is pretty cool.

To install it, you can follow the instructions in the README.

Step 1: Install UV

First, you need to install UV.

# macOS
brew install uv

# Linux
curl -LsSf https://astral.sh/uv/install.sh | sh

# Windows
powershell -c "irm https://astral.sh/uv/install.ps1 | iex"

Step 2: Add the MCP server to your client

Claude Desktop:

{
    "mcpServers": {
        "blender": {
            "command": "uvx",
            "args": ["mcp-for-blender"]
        }
    }
}

Claude Code:

claude mcp add blender uvx mcp-for-blender

Codex:

codex mcp add blender -- uvx mcp-for-blender

Or, if you are using OpenCode, use this:

{
  "mcp": {
    "blender-mcp": {
      "type": "local",
      "command": ["uvx", "mcp-for-blender"],
      "enabled": true,
      "environment": {
        "BLENDER_HOST": "localhost",
        "BLENDER_PORT": "9876"
      }
    }
  }
}

Step 3: Install the Blender add-on

uvx mcp-for-blender install-addon

Step 4: Go to Blender → Edit → Preferences

Step 5: Click Add-ons and check MCP for Blender

Step 6: Connect the MCP server

In Blender, press N. The following will appear on the screen.

Now click the MCP for Blender tab.

Ensure that the server is connected.

Under Asset Libraries, check Poly Haven.

Poly Haven is a free library of high-quality HDRIs, textures, and 3D models that anyone can use commercially without attribution.

The setup is done. Let's get to the fun part.

This is my current Blender scene:

It's the default scene, with the cube, light, and camera.

Let's try asking the MCP about this scene.

Open your agent. Here, I'm using OpenCode.

What's currently in my Blender scene?

As you can see, it accurately describes the current scene.

Now let's put it to more work, I'll ask it to make a simple room.

Delete the default cube. Create a simple room: a floor and four walls, about 5x5 meters, 3 meters tall.

We got ourselves a room.

So, this was a basic example. Now let's make a scene.

I'm trying out this prompt, this creates an island with textures and lighting from Poly Haven.

Build a striking low-poly floating island scene in Blender. Steps:

1. Clear the default scene.
2. Create a floating island base using a deformed icosphere or cube with noise-based displacement, flattened on top for a grassy surface and jagged on the underside for rock.
3. Add a simple low-poly tree on top, slightly off-center.
4. Scatter 4-6 small rocks on the surface at varied scale and rotation.
5. Apply Poly Haven textures: grass/moss on top, rock/stone on the underside.
6. Add a Poly Haven HDRI for a dramatic sunset or golden-hour sky.
7. Position the camera for an epic three-quarter low-angle shot that makes the island feel large and floating.
8. Render the final image.

Use Poly Haven assets for all textures and lighting. Favor bold silhouette and dramatic lighting over fine geometric detail.

Once it has finished building the scene, I get the following:

When I render it, I get the following output:

You can prompt it again and make all the tweaks you need until you are satisfied :)

Wrapping Up

You don't need to be a Blender pro to quickly create the 3D models or scenes you need.

With MCP, you can describe what you want in natural language, and the agent can interact with Blender to create and modify the scene for you.

You can start with something as simple as asking what's currently in the scene, then move on to creating a room, and eventually build a much more complex scene with a single prompt.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview: Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box Visualize blast radius at a glance Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:

A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.

A 300-line UI change in one file, fully covered by…

View on GitHub

Click below to try LiveReview with your codebase:

Can AI Get Better Without Getting Bigger? Meet Test-Time Compute

Rijul Rajesh — Sun, 27 Sep 2026 18:36:14 +0000

Usually, when we intend to upgrade our AI, we think about improving the model size.

This is called training-time compute.

But there is another scaling factor that can be used to scale AI.

This is called test-time compute.

What Is Test-Time Compute?

Test-time compute means spending extra computation while answering a question, instead of doing all the computation during training.

Usually, an LLM generates its answer in a fast, sequential process: read the prompt, predict the next token, predict the next token, and so on.

Test-time compute means that before locking in the final answer, we let the model "think" by generating intermediate reasoning, exploring multiple paths, checking its own work, and doing additional computation. This extra work happens live, at the moment you ask the question, hence "test time," as opposed to "training time."

What Does Thinking Longer Look Like?

These are some of the mechanisms that can take place during thinking.

Chain-of-thought reasoning:

Instead of jumping straight to the answer, the model generates a series of intermediate reasoning steps.
This takes time, but can produce better results, especially on math and logic-related problems.

Generating multiple candidate answers, then picking the best one:

In this mechanism, the model generates multiple attempts.
It then uses a scoring mechanism to choose the best one.

Self-verification/self-correction:

The model generates an answer, then checks its own reasoning for mistakes and revises it if needed.

Search over reasoning paths:

More advanced setups treat reasoning like a tree.
The model explores several possible next steps, evaluates which ones look promising, and can backtrack from dead ends.

Wrapping Up

Test-time compute comes with a trade-off.

The first one is speed. If the model spends more time thinking, the response naturally takes longer. Reasoning models can feel noticeably slower than a normal chatbot.

Then there is cost. More thinking means more generated tokens and more computation, which can increase the API cost of each query. The reasoning can be quite long, even when it isn't shown to the user.

There are also diminishing returns. Thinking longer doesn't always mean thinking better. After a certain point, spending more compute may not improve the answer and can sometimes make things worse by causing the model to overthink or go in circles.

And finally, test-time compute isn't a magic fix for every problem. If the model starts with a fundamentally wrong approach, giving it more time to reason can sometimes just produce a longer and more confident wrong answer. It works best when the problem is difficult but still solvable using what the model already knows.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview: Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box Visualize blast radius at a glance Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:

A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.

A 300-line UI change in one file, fully covered by…

View on GitHub

Click below to try LiveReview with your codebase:

Your RAG Searches by Meaning. But What About Exact Words? Meet BM25

Rijul Rajesh — Sat, 26 Sep 2026 20:44:55 +0000

When you work with RAG systems and come across scenarios where keyword matching is relevant, you might come across a term called BM25.

It sounds like some technical code word, but it is actually quite straightforward.

BM25 = Best Matching 25

It's essentially the name researchers landed on for this particular ranking function. The "25" doesn't have a deeper meaning.

So what exactly is BM25?

BM25 is a ranking formula used to score how relevant a document is to a search query.

Instead of simply asking:

"Does this word appear: yes/no?"

BM25 calculates a relevance score based on three main ideas.

The Three Ingredients of BM25

1. Term Frequency

This basically means: how many times does the word show up?

If you search for:

"dog training"

A document that mentions "dog" 5 times is probably more relevant to dogs than one that mentions it once.

More mentions can mean more relevance.

But there is an important nuance.

The benefit of additional mentions decreases as the word appears more often.

Going from 1 mention to 2 matters more than going from 20 mentions to 21.

BM25 has a built-in diminishing returns effect, so a document can't simply win by repeating the same word hundreds of times.

2. Inverse Document Frequency (IDF)

This basically means:

How rare or special is this word?

Common words like:

"the", "is", "and"

appear in almost every document.

So matching on them tells you very little.

Rare words like:

"gnocchi" or "arrhythmia"

appear in far fewer documents.

If both the query and a document contain a rare word, that can be a much stronger signal of relevance.

BM25 therefore gives more weight to rare terms and less weight to common terms.

3. Document Length Normalization

This basically asks:

Is this document relevant, or is it just really long?

A 5,000-word document will naturally contain more words and potentially more repetitions than a 50-word document.

That doesn't necessarily mean it is more relevant.

BM25 adjusts the score based on document length so that long documents don't get an unfair advantage simply because they contain more words.

It compares each document's length with the average document length in the collection and uses that information when calculating the score.

An Example

Let's say the query is:

"laptop battery life"

We have two documents.

Document A

A 200-word product review that says:

"battery" 4 times
"laptop" 3 times
"life" 2 times

Document B

A 3,000-word laptop manual that says:

"battery" 4 times
"laptop" several times
"life" isn't used in the relevant context

BM25 can rank Document A higher because it matches more of the query terms, while its shorter length also means those occurrences carry more weight relative to the document as a whole.

Document B's greater length can work against it through the length-normalization component.

Why Is BM25 Still Used Today?

Despite embeddings being the newer approach, BM25 is decades old and is still widely used.

It doesn't require model training or a GPU. It can run efficiently on CPUs and is particularly useful when exact terms matter.

For example:

Product IDs
Error codes
Names
Technical terms
Exact phrases

This is why BM25 remains an important part of search systems and is often combined with dense retrieval in hybrid search.

Wrapping Up

BM25 is a way of ranking documents based on how well their terms match a query.

It considers three main things:

Term frequency → How often does the term appear?

Inverse document frequency → How rare is the term?

Document length → Is the document unusually long?

Together, these produce a relevance score that helps the search system decide which documents should appear first.

Even with modern embedding-based retrieval, BM25 remains useful because semantic similarity and exact keyword matching solve different problems.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview: Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box Visualize blast radius at a glance Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:

A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.

A 300-line UI change in one file, fully covered by…

View on GitHub

Click below to try LiveReview with your codebase:

Embeddings Turn Text Into Numbers. But There’s More Than One Way to Do It

Rijul Rajesh — Fri, 25 Sep 2026 18:58:09 +0000

If you have read about RAG, you will probably be familiar with the concept of embeddings.

We take a bunch of text and turn it into numbers.

That's it.

But there is one more layer here.

There are different ways to represent text for retrieval.

Two important approaches are sparse representations and dense embeddings.

Let's understand how they work and when each one is useful.

Sparse Representations

Imagine you have a giant dictionary containing every word in your language. Let's say it has 50,000 words.

A sparse representation for a sentence can assign a value to each of those 50,000 words based on how relevant that word is to the sentence.

Most sentences only contain a small number of those words.

So, out of 50,000 possible positions, only a small number will have meaningful values. The rest will be zero.

That's why it's called sparse: most of the vector is empty, with only a few non-zero values.

Here is a simpler example.

Let's say our vocabulary contains just these 10 words, in this order:

[cat, dog, run, fast, food, eat, blue, sky, car, drive]

Now take the sentence:

"The dog can run fast"

The sparse vector could represent it like this:

cat  dog  run  fast  food  eat  blue  sky  car  drive
0    1    1    1     0     0    0     0    0    0

It's essentially a representation of which words are present and how important they are.

Now take a second sentence:

"I like to eat food fast"

cat  dog  run  fast  food  eat  blue  sky  car  drive
0    0    0    1     1    1    0     0    0    0

You can see that both vectors are mostly zeros.

This kind of representation works well when the exact words in the text matter.

But that also creates some limitations.

Where Sparse Representations Can Struggle

Synonyms

"buy" and "purchase" have similar meanings, but a traditional word-based representation can treat them as completely different terms.

Paraphrasing

Two people can ask the same question using completely different words, making it harder to connect them based on literal word overlap.

Conversational queries

Consider:

"Why is my package taking so long?"

and:

"Shipping delays explained"

There is very little literal word overlap, even though the second document could contain exactly the information the user needs.

This is where dense embeddings become useful.

Dense Embeddings

With sparse representations, we are largely looking at which words appear.

With dense embeddings, we are more interested in the semantic meaning of the text.

A dense embedding represents a piece of text as a relatively small vector containing many numerical values.

Instead of having thousands of mostly-zero positions corresponding to vocabulary terms, a dense vector might contain hundreds or thousands of values, with most of them being non-zero.

A simple example:

Sentence 1:

"The dog ran quickly"

Sentence 2:

"The puppy sprinted"

Look closely. These two sentences don't share a single word.

"Dog" ≠ "puppy."

"Ran" ≠ "sprinted."

If we only looked for matching words, these sentences could appear completely different.

Dense embedding models are trained to capture semantic relationships between text.

So these two sentences can end up with embeddings that are relatively close to each other because they express a similar idea.

This is one of the reasons dense embeddings are useful for semantic search.

But dense embeddings have their own limitations.

Where Dense Embeddings Can Struggle

Dense embeddings are designed to capture broader semantic relationships, but they may not be as effective when exact terms are important.

For example:

Product codes such as SKU-4471B
Exact names
Error codes
Rare technical terms
Specific identifiers

A search for an exact product code may be better handled by a method that focuses on literal term matching rather than only semantic similarity.

Wrapping Up

Embeddings turn text into numbers, but there isn't just one way to do that.

Sparse representations preserve explicit lexical signals and are useful when exact terms matter.

Dense embeddings capture broader semantic relationships and are useful when the same idea can be expressed using different words.

Understanding this difference helps explain why RAG systems sometimes use more than one retrieval method instead of relying on dense embeddings alone.

Your team's attention is limited, and the deluge of AI-generated code is making it harder to keep production reliable and secure without slowing you down.

I'm building LiveReview, a blast-radius aware AI code review built for your business-critical systems.

Instead of presenting every diff with equal emphasis, LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.

Spend code review effort where business risk is highest — not spread evenly across every diff.

⭐ Star it on GitHub:

HexmosTech / LiveReview

Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview: Blast-Radius Aware AI Code Review for Business-Critical Systems

LiveReview is an AI code reviewer that scores every hunk of a diff by blast radius: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.
blast-radius-demo.mp4
LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.

The exact math, not a black box Visualize blast radius at a glance Every factor that feeds the score

How does Blast Radius scoring work? (a more technical explanation)
Here's the goal:

A 3-line fix in a function used by 40 other files, that also writes to a database, should score high.

A 300-line UI change in one file, fully covered by…

View on GitHub

Click below to try LiveReview with your codebase: