Almost every company I talk to has run a generative AI pilot this year. Very few of those pilots are still running six months later.

That is not because the technology stopped working. The demo still works fine. What usually happens is quieter than a failure. The project just stops getting attention, the budget gets reassigned, and nobody officially cancels it.

After looking at enough of these pilots, a pattern shows up. The projects that die share the same three gaps, and none of them are about model quality.

The first gap is ownership. A pilot often starts because someone in IT or innovation wanted to test a capability. It proves the model can do something useful. But nobody on the business side actually asked for it, which means nobody on the business side is accountable for keeping it alive once the initial excitement fades.

The second gap is data readiness. A demo can run on a clean, hand picked set of examples. Production cannot. The moment real documents, real customer messages, and real edge cases hit the system, the outputs get inconsistent, and the team that built the pilot is not equipped to fix a data problem. They built a model integration, not a data pipeline.

The third gap is the review step. Somebody has to check the output before it reaches a customer or gets used in a decision. In the pilot phase, that reviewer is usually the same person who built the thing, checking their own work on a small sample. In production, review has to scale to volume, and almost nobody plans for who does that or how long it takes.

None of these are AI problems. They are the same problems that kill any new internal tool: unclear ownership, messy inputs, and no plan for quality control at scale. Generative AI just makes them show up faster, because the barrier to building an impressive first version is so low.

So what actually gets a pilot to production?

Start with a named business owner before the first prototype exists, not after. If nobody with a budget and a deadline wants this enough to defend it in a planning meeting, it is a demo, not a project.

Test on messy data early, not clean data late. Pull the ugliest real examples you can find in week one. If the model falls apart on those, you have found the real work before you have sunk months into the easy version.

Design the review process as part of the system, not as an afterthought. Decide who checks the output, how long that takes, and what happens when the model is wrong, before you scale volume, not after complaints start.

The technology is ready for far more than most companies are using it for. The gap is not capability. It is the unglamorous work of ownership, data, and review that never makes it into the pilot deck.

Most Generative AI Pilots Never Reach Production. Here’s Why. was originally published in Towards Deep Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

What is this Jev AI?
Does Jev replace LLMs?
Where do we actually need Jev in the AI era?
If an LLM can already classify text, route requests, extract information and make decisions, why do we need another type of AI model?
And perhaps the more important question: Are we using LLMs for tasks that don’t actually require an LLM?

These questions become interesting when we look at Jev, the first public model from TypeSafe’s new category of System One Models.

Jev isn’t trying to be another ChatGPT. It isn’t designed to write articles, generate code or have long conversations.

Its purpose is much narrower — and that’s exactly what makes it interesting.

Jev is designed to make fast, structured decisions that software can directly use.

The problem with using an LLM for everything

Over the last few years, LLMs have become the default solution for almost every AI problem.

Need sentiment analysis? Use an LLM.
Need classification? Use an LLM.
Need routing? Use an LLM.
Need to decide which tool an agent should call? Use an LLM.
Need to extract information? Use an LLM.

And honestly, it works surprisingly well.

But there is a problem. Not every AI task requires generating text.

Suppose a customer sends: “The payment was deducted from my account but the order was cancelled.”

Your application might need to decide:

Intent → Payment issue
Urgency → High
Department → Billing
Escalate → Yes

You don’t need a paragraph from the AI. You need four decisions. And your software needs those decisions immediately. This is the type of problem Jev is targeting.

So, what exactly is Jev?

The simplest mental model is:

Context + Questions
        ↓
       Jev
        ↓
Structured decisions + confidence

For example:

Context:
"The phone takes excellent photos but the battery
doesn't last through the day."

Questions:
Camera → ?
Battery → ?
Overall sentiment → ?

Jev can return structured answers such as:

Camera → Positive
Battery → Negative
Sentiment → Mixed

The important difference is that the output is designed to be consumed by software, rather than primarily read by a human.

TypeSafe describes Jev as a model that takes unstructured state and produces typed decisions with probabilities and confidence scores.

And this leads to the most important idea behind Jev:

LLMs generate. Jev decides.

Does Jev replace LLMs?

No.

And this is probably the first thing we need to make clear.

If you want to:

• write an article
• generate code
• summarize a document
• have a conversation
• reason through a complex problem
• generate creative content

you still need a model designed for those tasks.

Jev is solving a different problem. Think about an AI application like this:

                  User
                    |
                    ↓
              LLM / Agent
                    |
          ┌─────────┼─────────┐
          ↓         ↓         ↓
         RAG       Tools     Jev
          ↓         ↓         ↓
      Retrieve    Execute   Decide

The LLM can handle complex reasoning.

RAG can retrieve information.

Traditional code can execute deterministic logic.

And Jev can handle smaller semantic decisions.

So the future isn’t necessarily:

Jev vs LLM

It could be:

Jev + LLM + RAG + Code

Each doing what it is best at.

Why do we need Jev if LLMs can already make decisions?

This is where Jev gets interesting.

Imagine asking an LLM: “Should this customer request go to billing or technical support?”

The LLM can certainly answer. But an LLM is fundamentally optimized around generating sequences of tokens. For a simple decision, that can be overkill.

Jev takes a different approach. Instead of generating a long response and asking your application to interpret it, you define the possible decisions upfront.

For example:

Department:
    Billing
    Technical Support
    Sales

The model chooses among those options. This makes the output much easier for software to consume. And that creates several potential advantages like:

1. Speed

This is probably one of Jev’s biggest selling points. LLMs generate output token by token.

Jev is designed around structured decisions rather than generating a long sequence of text.

TypeSafe reports 70–500 ms end-to-end response times for its service and says this can be substantially faster than frontier LLMs for System One-shaped queries.

Why does that matter? Because latency matters differently when AI is inside software.

If a human is waiting for an AI answer, a few seconds may be acceptable. But imagine an application making thousands or millions of small decisions.

For example:

10,000 documents
×
5 decisions per document

Now you’re making 50,000 AI decisions. At that scale, every millisecond matters. This opens the door to AI-powered decisions inside systems where using a large LLM for every small step may be too slow.

2. Cost

Speed is only half of the equation. The other half is cost.

TypeSafe currently lists Jev’s input pricing at $0.042 per million tokens, with output tokens effectively free to meter because the model returns structured decisions rather than generated text.

TypeSafe’s published workflow evaluations report very large efficiency differences in certain System One workloads, including a headline result of up to 444.6× cheaper than the compared LLM setups.

These numbers shouldn’t be interpreted as: “Jev is always 444× cheaper than every LLM.”

They come from specific workflows and evaluations. But the underlying idea is important.

If AI becomes dramatically cheaper to call, developers can afford to put more intelligence inside ordinary software. And that could be a much bigger change than it initially sounds.

3. Structured output

This is perhaps the most important architectural difference.

An LLM might return: “I believe this customer is probably asking about billing, although there is a possibility that it could be related to an order issue.”

Your code now has to interpret that response.

With Jev, the developer can define the possible output.

For example:

{
  "department": "billing",
  "confidence": 0.94
}

Now the application knows exactly what to do.

if department == "billing":
       → Just call Billing API

if department == "technical":
       → Technical Support

if confidence < threshold:
       → Human review

This is why TypeSafe positions Jev as something closer to a software primitive than a traditional chatbot.

4. Confidence becomes part of the workflow

Here’s another interesting capability. Instead of returning only:

YES

the model can provide a probability or confidence estimate.

For example:

Decision: Escalate
Confidence: 96%

Your software can then decide what to do.

> 90%  → Automate
60–90% → Additional checks
< 60%  → Human review

This is important because good automation isn’t necessarily about making every decision automatically.

It’s about knowing:

When should the system act, and when should it ask for help?

TypeSafe explicitly emphasizes calibrated probabilities and confidence as a core part of its System One approach.

Note: A confidence score is useful only when it is well calibrated; high confidence does not guarantee correctness.

5. Multiple decisions from the same context

This is where the Flipkart example becomes really useful.

Imagine 50 smartphone reviews. Instead of asking an LLM to summarize each review, we can ask multiple structured questions about the same review:

Camera?
Battery?
Display?
Performance?
Design?
Build quality?
Value for money?
Overall sentiment?

Multiple questions can be sent against the same review, and the resulting decisions can then be aggregated across the reviews.

The final output could look like:

Camera        → 4.6 / 5
Battery       → 3.8 / 5
Display       → 4.5 / 5
Performance   → 4.7 / 5
Design        → 4.4 / 5

Now we’ve converted: Thousands of unstructured reviews → structured business intelligence.

That’s a very practical use case.

The Flipkart example: where Jev starts making sense

Consider a smartphone with thousands of reviews. Flipkart might want to understand not only the overall rating, but what customers think about specific attributes:

• Camera
• Battery
• Display
• Design
• Performance
• Build quality
• Value for money

Traditionally, this could require building and maintaining a dedicated NLP classification pipeline.

The Jev approach is different. We can ask questions directly against the review:

Review:
"The camera is excellent but the battery is disappointing."

Questions:

Camera → ?
Battery → ?
Overall sentiment → ?

The result becomes structured data.

Do this across thousands of reviews, aggregate the results, and suddenly you have a detailed picture of what customers actually think.

The interesting part is that the developer doesn’t necessarily need to build a separate fine-tuned classifier for every new question.

Jev as the “AI if-statement”

One phrase from the TypeSafe ecosystem captures the idea nicely:

AI-powered workflows / smart if-statements.

Think about normal software.

We write:

if customer_type == "premium":
    ...

But many real-world decisions cannot be expressed with simple rules.

For example:

if customer seems frustrated
AND
the issue is urgent
AND
there is a payment problem
→ escalate

The problem is that “seems frustrated” isn’t a deterministic variable. You need intelligence. This is where a decision model can potentially act as the fuzzy part of an otherwise deterministic program.

Code
 +
Jev
 ↓
Intelligent workflow

That is a powerful idea.

Where can Jev be used?

AI Agent Routing

An agent may need to decide:

Should I use:
→ SQL?
→ RAG?
→ Web search?
→ API?
→ Human?

Jev can potentially act as the decision layer while the LLM handles the more complex reasoning.

Agentic RAG

This becomes even more interesting with Agentic RAG. Instead of always doing:

Query
 ↓
Vector DB
 ↓
Answer

the system can first decide:

What should I use?

Internal documents?
SQL?
Web?
Vector database?

Then the appropriate tool is called. This is exactly where a fast decision layer can fit naturally into an agentic architecture.

Customer Support

A customer message can be converted into:

Intent       → Billing
Urgency      → High
Sentiment    → Negative
Escalation   → Yes

The application can then automatically route the conversation.

Content Classification

For large platforms:

Content
 ↓
Jev
 ↓
Safe / Spam / Review / Block

This can be much more useful than generating an explanation for every single piece of content.

Large-scale data processing

Imagine processing millions of records. You may want to ask:

Is this relevant?
Which category?
What is the sentiment?
Should this be reviewed?
What action should happen next?

These are all decisions. And decisions are exactly where Jev is designed to operate.

The bigger shift: Intelligence becomes a software primitive

This is the part I find most interesting about Jev. For years, AI has mostly been presented as:

Human
 ↓
Chatbot
 ↓
Answer

But AI is increasingly moving inside software. Imagine:

Application
   |
   ├── Database
   ├── APIs
   ├── Business Rules
   ├── RAG
   ├── LLM
   └── Decision Model

Now AI isn’t just something humans talk to. It becomes a component that software calls.

That’s why speed, cost and structured output matter so much.

A model that is 10× cheaper and dramatically faster can be used in places where calling a large LLM for every decision simply doesn’t make economic or latency sense.

So, should you use Jev instead of an LLM?

Not necessarily. The better question is:

Does this task require generation? → LLM

Does it require knowledge retrieval? → RAG / Search

Does it require deterministic logic? → Traditional code

Does it require a fast semantic decision? → A model like Jev may be worth evaluating

This is the real lesson.

Don’t ask:

Which model is better?

Ask:

Which type of intelligence does this part of my application need?

LLM + Jev could be more powerful than LLM alone

Imagine an AI agent handling a customer request.

Instead of:

User
 ↓
LLM
 ↓
LLM
 ↓
LLM
 ↓
Tool
 ↓
LLM
 ↓
Answer

we could have:

                  User
                   ↓
                 LLM
                   ↓
        ┌──────────┴──────────┐
        ↓                     ↓
      Jev                    RAG
   Decisions               Knowledge
        ↓                     ↓
     Tools ←────────────── Agent
        ↓
      Result
        ↓
       LLM
        ↓
      Answer

The LLM handles the complex parts. Jev handles fast decisions. Code handles deterministic operations. RAG provides knowledge.

Each component has a job.

And that may be a more scalable way to build AI systems.

The real question isn’t “Will Jev replace LLMs?”

It is:

Why are we asking an LLM to make every small decision in our software?

LLMs are incredibly powerful.

But power doesn’t always mean efficiency. If a task is simply:

Choose A or B.
Route here or there.
Approve or reject.
Relevant or irrelevant.
Score this.
Extract this.

we may not need a model whose primary strength is generating language.

We may need something optimized for fast, structured decision-making. That’s the idea behind Jev.

And if models like Jev continue improving, the future of AI applications may not be dominated by one giant model. Instead, we may build systems where:

LLMs reason.
RAG retrieves.
Code executes.
Decision models decide.

And agents coordinate everything.

The future of AI may not be about finding one model that can do everything. It may be about finding the right model for every decision.

What do you think?

Would you use a decision model like Jev instead of an LLM for tasks such as classification, routing, agent decisions, or large-scale data processing?

And more importantly —

Where do you think a lightweight decision model makes more sense than an LLM?

I’d love to hear your thoughts in the comments.

Jev AI: Do We Really Need an LLM for Every Decision? was originally published in Towards Deep Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

When a fire breaks out in an apartment building, within minutes, the smoke will begin spreading throughout the hallways, stairwells, and rooms.

Predicting exactly where that smoke will go is an incredibly complicated problem, as it requires modeling the air’s density, velocity, pressure, and temperature. If we can accurately simulate this system, we can design better ventilation systems and evacuation routes. However, since the quantities in this system are governed by complex partial differential equations, solving them at a high resolution with traditional methods can be extremely expensive. In fact, simulating just 10 minutes of smoke transport in an enclosed space using conventional computational fluid dynamics (CFD) techniques can take a full day on a personal computer.

But why are traditional methods so slow? When working with complex systems such as smoke transport, the governing PDEs usually don’t have a closed-form analytical solution. Instead, we would use numerical methods, which approximate the space with a discrete grid and estimate the PDE solution at each point on the grid.

The problem begins when working with larger scales. As we increase either the resolution or size of the grid, the number of points we need to calculate increases exponentially, especially in higher dimensions. In 3 dimensions, halving the grid spacing will increase the number of grid cells by 8 times. Evaluating the governing PDEs from scratch millions of times across thousands of time steps becomes very expensive.

Instead of constantly computing the governing PDEs, why don’t we train a machine learning model on previously generated data? This is the idea behind data-driven machine learning surrogate models. We can use autoencoders to compress the physical state into a lower-dimensional latent state and LSTMs to learn how that latent state changes over time. Once we train the model, the cost per query is almost negligible compared to repeatedly running numerical simulations. However, these purely data-driven methods can often generalize poorly or produce outputs that are not physically realistic.

Physical constrained neural networks improve on those aspects of purely data-driven networks by integrating physical laws along with data fitting. However, these networks struggle with training complexity, especially in high-dimensional systems. Training PCNNs involves evaluating PDE residuals for each output. A PDE residual is a measure of how much a model’s prediction violates the governing physical equation. If the prediction is physically possible, it will perfectly satisfy the PDE, so the residual is zero. These residuals, along with other physical constraints such as conservation laws, can be incorporated into a physics-based loss function. However, computing derivatives over the full high-resolution domain at each time step quickly becomes expensive.

One recent approach known as the Multi-Scale Physics-Constrained Neural Network (MSPCNN) takes a multi-fidelity approach to this problem. In multi-fidelity modeling, a high-fidelity (HF) simulation is one that uses a finer grid or more accurate numerical method, making it more precise but also much more expensive, while a low-fidelity (LF) simulation uses a cheaper, coarser approximation. Instead of evaluating the physics-based loss on the full high-resolution state. MSPCNN connects both HF and LF data streams through the same latent space using their respective autoencoders. We can then use an LSTM to learn how the latent representation changes over time. We can pass the LSTM’s predicted latent states through the LF decoder to get a low-resolution reconstruction. This way, evaluating the physics-based loss becomes computationally cheaper, as we can do it on this LF field. In short, MSPCNN has the physical reliability of a high-fidelity PCNN without paying the full computational cost of enforcing those constraints at high resolution.

The results speak for themselves. when tested on the two-dimensional Burgers’ system, a simplified fluid-dynamics problem governed by Burgers’ equations, MSPCNN was able to substantially reduce error while cutting the cost of enforcing physical constraints.

In the table, EC represents an energy-conservation constraint, while FO represents a flow-operator constraint. HF-MulCons, the conventional PCNN applying both constraints at high fidelity, achieved the lowest error at just 5.2% of the baseline LSTM’s MSE, but required 164.36 seconds per training epoch. By contrast, LF-MulCons achieved 22.0% of the baseline MSE in just 54.96 seconds per epoch, trading some accuracy for roughly a threefold reduction in training time.

Multi-Scale Physics-Constrained Neural Networks was originally published in Towards Deep Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Suppose you are a scientist trying to create a surrogate model to model a complex system, let’s say the drag on an airplane wing, or the deterioration of different pipe materials. You face a fundamental tradeoff. On one hand, you have a low-fidelity (LF) model that is computationally cheap and can generate a large amount of data with limited accuracy. On the other hand, you have a high-fidelity (HF) model that is more accurate but is slow and expensive, limiting you to only a handful of simulations. Relying solely on LF data for your surrogate model will get you a model that inherits systematic biases and misrepresents critical dynamics. However, using only HF data will cause overfitting to sparse samples, leading to poor generalization.

With multi-fidelity modeling, we don’t have to choose between the two. We can combine data from models of different fidelities to make accurate models at a lower cost.

One of the earliest multi-fidelity frameworks was proposed by Kennedy and O’Hagan in 2000. Their approach Fhf(x) = p*Flf(x)+δ(x) assumes that the high-fidelity model (HF) is a linear transformation of the low-fidelity model (LF). By learning this mapping, we can adjust LF predictions using a limited number of HF observations, effectively blending the two fidelities. While this model lets us improve on low-fidelity evaluations by correcting them using fewer high-fidelity observations, it has a few limitations. Because the relationship between the LF and HF models is assumed to be linear, in many real-world systems, especially those governed by complex, nonlinear dynamics, this model breaks down. Stretching and shifting the LF model isn’t sufficient to correct intricate discrepancies. Imagine trying to fit a pair of shoes to a bunch of people with wide feet, narrow feet, high arches, flat feet, etc. Simply adjusting the size of the shoe from a 9 to a 10.5 won’t always make the shoe fit well. You need to modify both the shoe size and shape.

What if we want to learn nonlinear high-dimensional corrections without underlying assumptions about the structure?

That’s where ML-based modern approaches such as Bi-Fidelity Weighted Learning (BFWL) come in. BFWL is a hybrid neural network approach that applies transfer learning to multi-fidelity data.

Transfer learning in machine learning is the process of taking a model that was trained on 1 task and “reusing” it for a similar task. The idea is that the representation learned from the first problem is applicable to the second problem, eliminating the need to train a new model from scratch.

BFWL uses a student-teacher approach that is based on the idea of learning using privileged information. First, a “student” neural network is trained on the LF dataset. This network learns the general patterns of the dataset. Then, a Gaussian process “teacher” is fit to the HF dataset, learning the residual between the LF and HF functions. The GP teacher is then used to predict outputs and posterior variances (confidence) of the combined LF and HF dataset Xb. These predictions give us the “soft bi-fidelity dataset” containing HF predictions and the confidence of those predictions. The soft bi-fidelity dataset is used to fine-tune the student network. The weighted learning rate

is used. When fine-tuning, not every sample in the soft dataset is treated equally. Low variance ∑(Xb) means the prediction is confident, so the learning rate nk is higher. High variance lowers the learning rate. In summary, the student network corrects its base representation of the LF data using the teacher network, trusting the teacher’s confident predictions over uncertain predictions.

Application

To demonstrate how BFWL works in practice, let’s apply it to the toy 1D functions,

The LF function approximates the HF one that has substantially fewer data points (20).

Here are the results when BFWL is compared to an HF-only network

The plot shows us the actual HF function (HF Ground Truth), actual LF function, HF training points, and BFWL and HF-only predictions.

Because of the limited amount of HF training points, the HF-only model struggles with generalization while BFWL does not.

Even with limited HF data, BFWL produces a student model that generalizes well across the full domain. This is especially valuable in scientific computing, where LF data is abundant and HF simulations are expensive.

Conclusion

Multi-fidelity methods like BFWL offer ways to build surrogate models while mitigating the limitations of large-scale HF simulations. In fields such as aerospace design, computational physics, climate modeling, derivatives pricing, etc., where LF approximations are abundant and HF data is expensive, the ability to learn nuanced corrections from a small sample of HF data makes BFWL extremely valuable. However, the main limitation of BFWL is its scalability issues due to the Gaussian process teacher. BFWL struggles with larger HF datasets as the training time for the GP teacher scales exponentially with the size of the HF dataset. Despite this limitation, BFWL is a powerful tool for surrogate modeling in settings where balancing efficiency with generalization is important.

An Introduction to Bi-Fidelity Weighted Learning was originally published in Towards Deep Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hi, I’m Henry.One thing I’ve learned from working with Linux servers and development environments is that small improvements can save a surprising amount of time.

You don’t always need a complicated setup or a huge productivity system. Sometimes, replacing one slow or awkward command with a better tool is enough to make your daily workflow feel completely different.

These are eight terminal tools I install early whenever I’m setting up a new machine.

If you only have time to try three, I’d start with fzf, ripgrep, and zoxide.

1. fzf: Find Anything by Typing a Few Letters

fzf is a fuzzy finder.

One of my favorite uses is searching shell history. Instead of pressing the up arrow over and over, you can turn your history into a searchable list.

For example, you might remember part of a Docker command but not the exact syntax.

docker system prune -af

Type a few words and fzf can help you find it.

It also works nicely with other commands:

git checkout $(git branch | fzf)
vim $(fzf)

The first lets you choose a Git branch interactively. The second lets you pick a file without remembering its full path.

For zsh:

source <(fzf --zsh)

For bash:

eval "$(fzf --bash)"

Without the shell integration, you get the basic command but miss some of the really useful shortcuts.

2. ripgrep (rg): Search Code Without the Noise

If you regularly search through source code, ripgrep is one of those tools that becomes difficult to give up once you’ve used it.

Instead of:

grep -r "TODO" .

I usually use:

rg "TODO"

Some useful examples:

rg "useEffect" src/
rg -t py "def main"
rg -l TODO

One reason it feels so much better than recursive grep is that it automatically respects .gitignore and avoids many files you probably didn't want to search in the first place.

So you don’t accidentally spend time searching through node_modules, build directories, or other generated files.

If you actually need to search ignored and hidden files, you can use:

rg -uu "term"

That little difference makes a big difference when you’re working in large projects.

3. zoxide: Stop Typing Full Paths

If you spend a lot of time jumping between project directories, zoxide is worth installing.

Instead of typing:

cd ~/projects/client-site/src/components

you can eventually do something like:

z comp

zoxide remembers the directories you visit and lets you jump to them using a small part of the path.

There’s also:

zi

which gives you an interactive picker when several directories match.

For zsh:

eval "$(zoxide init zsh)"

For bash:

eval "$(zoxide init bash)"

It doesn’t feel magical on the first day because it needs to learn your directory habits.

Give it a few days.

4. fd: find With Sane Syntax

The traditional find command is powerful, but I don't always enjoy remembering its syntax.

fd gives you a simpler alternative.

For example:

fd '\.test\.js$'

Find Markdown files:

fd -e md

Or search for something called config:

fd config ~/projects

Compare that with:

find . -name "*.md" -type f

Both work. I just find the first version easier to remember.

One Debian/Ubuntu detail

On some Ubuntu and Debian systems, the package is called fd-find and the command is:

fdfind

You can make it easier to use:

alias fd=fdfind

5. bat: cat With Syntax Highlighting

bat is basically what happens when you give cat a few useful features.

For example:

bat src/app.js

You get syntax highlighting, line numbers, and Git change indicators.

You can also display a specific section:

bat --line-range 10:30 src/app.js

It’s particularly useful when you’re quickly checking configuration files or source code from the terminal.

On some Debian-based systems, the command may be:

batcat

So you may want:

alias bat=batcat

6. eza: A More Readable ls

eza is a modern replacement for ls.

A simple listing:

eza -la --git

Or a project tree:

eza --tree --level=2 --git-ignore

The Git information is especially useful when you’re working inside a repository.

And the tree view makes it easy to understand a project without getting buried in directories such as node_modules.

If you remember exa, eza is its maintained successor.

7. lazygit: Git Without Memorizing Every Flag

lazygit is a terminal UI for Git.

Run:

lazygit

inside a repository and you get an interactive interface for common Git operations.

You can stage individual lines, amend commits, inspect changes, manage branches, and work through conflicts without constantly remembering Git flags.

One feature I particularly like is that lazygit can show the Git commands it’s running.

That means you can use the interface while still learning what the underlying Git commands actually do.

I don’t see it as a replacement for learning Git.

I see it as a faster way to use Git while you’re learning.

8. tldr: Man Pages for Humans

The man command is useful, but sometimes you don't need twenty pages of documentation.

You just need to remember how to do one thing.

That’s where tldr comes in.

For example:

tldr tar

Instead of reading through every option, you’ll get practical examples such as:

tar -xzf archive.tar.gz

The Rust implementation, tealdeer, is a fast option.

After installing it, you can update the pages with:

tldr --update

For commands I haven’t used in months, this is often much faster than searching through a full man page.

Install Everything at Once

You don’t have to install these one by one.

macOS

brew install fzf ripgrep zoxide fd bat eza lazygit tealdeer

Windows

With winget:

winget install junegunn.fzf BurntSushi.ripgrep.MSVC ajeetdsouza.zoxide sharkdp.fd sharkdp.bat JesseDuffield.lazygit

For eza and tealdeer, you can search for the current package IDs:

winget search eza
winget search tealdeer

Ubuntu/Debian

sudo apt install fzf ripgrep zoxide fd-find bat

Depending on your distribution version, you may need to install eza, lazygit, or tealdeer separately.

A Few Aliases Worth Adding

Once the tools are installed, a few simple aliases make them easier to use:

alias cat='bat --paging=never'
alias ls='eza'
alias ll='eza -la --git'
alias tree='eza --tree --git-ignore'

These aliases only affect your interactive shell.

Your scripts and cron jobs will still use the normal commands, so you aren’t changing how existing automation works.

Taking the Same Setup to a Server

This is where these tools become even more useful for me.

Your laptop might have everything configured exactly the way you like it.

Then you SSH into a new Linux server and suddenly you’re back to the basics.

No fuzzy history search.

No better file search.

No directory jumping.

No Git UI.

If you have root or sudo access to a VPS, you can set up your preferred tools there too.

For example, on a fresh Ubuntu server:

sudo apt update && sudo apt install -y fzf ripgrep zoxide fd-find bat

Then:

echo 'alias fd=fdfind' >> ~/.bashrc
echo 'alias bat=batcat' >> ~/.bashrc
echo 'source /usr/share/doc/fzf/examples/key-bindings.bash' >> ~/.bashrc
echo 'eval "$(zoxide init bash)"' >> ~/.bashrc

source ~/.bashrc

After that, your remote terminal starts feeling much closer to your local environment.

If you’re looking for a small server to practice this kind of setup, HelloServer is one option you can compare for VPS hosting and root access.

The important part isn’t really which provider you choose.

It’s having a server where you can actually experiment, break things, reinstall the OS, and build your own setup.

Don’t Go Too Far With It

There are a few things I’d avoid.

Don’t alias grep to rg

The commands aren’t identical.

For example, in traditional grep, -r means recursive.

In ripgrep, recursive searching is already the default, and the flags don’t always mean the same thing.

That kind of alias can create confusing problems when you’re switching between machines.

Don’t Make Your Scripts Depend on These Tools

Your personal terminal can use whatever you like.

But if you’re writing a script for other people, assuming everyone has fd, rg, or eza installed can make the script unnecessarily difficult to use.

For shared scripts, the standard Unix tools are often still the safer choice.

Give Yourself Time

The first few days, you’ll probably keep typing:

grep
find
cd
ls

out of habit.

That’s normal.

After a week or two, you may start wondering how you ever worked without some of these tools.

If I Could Only Install Three

I’d choose:

1. fzf — because searching history and files becomes much easier.

2. ripgrep — because code searching becomes faster and cleaner.

3. zoxide — because jumping between projects saves small amounts of time all day.

None of these tools completely changes how you use the terminal.

That’s actually why I like them.

They just remove a lot of small frustrations that add up when you’re working on servers and projects every day.

If you’re setting up a new machine today, install one and use it for a week before adding everything else.

You might be surprised by which one becomes part of your everyday workflow.

8 Terminal Tools I’d Install First on Any New Machine was originally published in Towards Deep Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.