This process of finding a path through a space of possibilities is what we refer to as search in artificial intelligence. It’s one of the most fundamental problem-solving tools in the field. And while it may sound simple, there’s a surprising amount of depth and elegance in how it works.

“In which we see how an agent can find a sequence of actions that achieves its goals when no single action will do.” - Peter Norvig and Stuart J. Russel

From Real-World Goals to Search Problems

Before an AI system can search, it needs to understand what it’s searching for. This means turning a real-world problem into a well-defined structure that the machine can reason about. We start by defining the initial state, where the agent begins. We also define the goal, what the agent is trying to reach. Then we list all the actions available at each point, and describe how those actions move the agent from one state to another. This forms a search space, a kind of mental map the agent can explore.

Imagine a robot in a house. Its initial state might be in the kitchen and the goal is in the living room. The actions are things like move forward, turn left or open door. Once this is modeled, the AI can start figuring out how to get from point A to point B.

How Machines Search

To find a path to the goal, the AI explores different possible sequences of actions, essentially walking a decision tree. Each branch represents a new state that results from taking an action. Some paths lead to dead ends. Others eventually reach the goal.

Unlike humans, machines don’t have intuition or shortcuts built in. So we need to give them algorithms, precise strategies for exploring the search space.

Some of these strategies are quite basic, treating all options equally. Others use clever tricks to prioritise certain paths over others. Broadly, we divide them into two categories: uninformed and informed search.

Blind Strategies: Uninformed Search

Uninformed search algorithms don’t use any knowledge about the goal’s location. They treat all states equally and rely solely on the problem definition. These methods are useful when no heuristic guidance is available.

Breadth-First Search (BFS)

It explores all paths that take one step, then all paths that take two steps, and so on. It guarantees the shortest solution (in terms of number of steps), but can be slow and memory-intensive.

def BFS(graph, start, goal):
    # Initialize the queue with the starting node and an empty path
    queue = [(start, [])]
    # Set to keep track of visited nodes
    visited = set()
    # Counter to keep track of node expansions
    node_expansions = 0

    while queue:
        # Dequeue a node and its path
        node, path = queue.pop(0)

        # If the node has been visited, skip it
        if node in visited:
            continue

        # Mark the node as visited
        visited.add(node)

        # Append the current node to the path
        path = path + [node]

        # If the goal is reached, return the path, its length, and the number of node expansions
        if node == goal:
            return path, len(path), node_expansions

        # Increment the node expansions counter
        node_expansions += 1

        # Add all unvisited neighbors to the queue
        for neighbor in graph.neighbors(node):
            if neighbor not in visited:
                queue.append((neighbor, path))

    # If no path is found, return an empty list, infinity for path length, and the number of node expansions
    return [], float("inf"), node_expansions

Depth-First Search (DFS)

It goes as far down a single path as it can before backtracking. It’s more memory-efficient but can get lost if the search space is deep or looping.

def DFS(graph, start, goal):
    # Initialize the stack with the starting node and an empty path
    stack = [(start, [])]
    # Set to keep track of visited nodes
    visited = set()
    # Counter to keep track of node expansions
    node_expansions = 0

    while stack:
        # Pop a node and its path from the stack
        node, path = stack.pop()

        # If the node has been visited, skip it
        if node in visited:
            continue

        # Mark the node as visited
        visited.add(node)

        # Append the current node to the path
        path = path + [node]

        # If the goal is reached, return the path, its length, and the number of node expansions
        if node == goal:
            return path, len(path), node_expansions

        # Increment the node expansions counter
        node_expansions += 1

        # Add all unvisited neighbors to the stack
        for neighbor in reversed(list(graph.neighbors(node))):
            if neighbor not in visited:
                stack.append((neighbor, path))

    # If no path is found, return an empty list, infinity for path length, and the number of node expansions
    return [], float("inf"), node_expansions

Uniform Cost Search (UCS)

Adds a layer of realism by considering the cost of each action. Instead of counting steps, it looks for the path with the lowest total cost, useful when some actions are harder, slower, or more expensive than others.

def UCS(graph, start, goal):
    # Initialize the priority queue with the starting node, cost 0, and an empty path
    queue = [(0, start, [])]
    # Set to keep track of visited nodes
    visited = set()
    # Counter to keep track of node expansions
    node_expansions = 0

    while queue:
        # Dequeue the node with the lowest cost
        cost, node, path = heapq.heappop(queue)

        # If the node has been visited, skip it
        if node in visited:
            continue

        # Mark the node as visited
        visited.add(node)

        # Append the current node to the path
        path = path + [node]

        # If the goal is reached, return the path, its length, and the number of node expansions
        if node == goal:
            return path, cost, node_expansions

        # Increment the node expansions counter
        node_expansions += 1

        # Add all unvisited neighbors to the priority queue with their cumulative cost
        for neighbor in graph.neighbors(node):
            if neighbor not in visited:
                edge_weight = graph.edges[node, neighbor].get("weight", 1)
                heapq.heappush(queue, (cost + edge_weight, neighbor, path))

    # If no path is found, return an empty list, infinity for path length, and the number of node expansions
    return [], float("inf"), node_expansions

All of these algorithms are systematic, but none of them are particularly smart. They don’t know which direction is better; they just explore everything. A few other uninformed search algorithms include:

• Depth-Limited Search - DFS with a fixed depth limit. Prevents infinite loops, but might miss deeper solutions.

• Iterative Deepening Search (IDDFS) - Combines the space efficiency of DFS with the completeness of BFS. Performs DFS to increasing depths.

• Bidirectional Search - Searches forward from the start and backward from the goal simultaneously. Efficient if the goal is known.

Smarter Strategies: Informed (Heuristic) Search

Informed search, sometimes called heuristic search, brings some knowledge into the process. These algorithms use heuristics (estimates of how far a given state is from the goal) to make better choices about what to explore next.

Greedy Best-First Search

Always picks the path that looks closest to the goal. It’s fast but not always accurate; sometimes it’s lured into traps because it doesn’t consider the cost of the path so far.

def best_first_search(graph, start, goal, heuristic):
    # Initialize the priority queue with the starting node, its heuristic value, and an empty path
    queue = [(heuristic[start], start, [])]
    # Set to keep track of visited nodes
    visited = set()
    # Counter to keep track of node expansions
    node_expansions = 0

    while queue:
        # Dequeue the node with the lowest heuristic value
        _, node, path = heapq.heappop(queue)

        # If the node has been visited, skip it
        if node in visited:
            continue

        # Mark the node as visited
        visited.add(node)

        # Append the current node to the path
        path = path + [node]

        # If the goal is reached, return the path, its length, and the number of node expansions
        if node == goal:
            return path, len(path), node_expansions

        # Increment the node expansions counter
        node_expansions += 1

        # Add all unvisited neighbors to the priority queue with their heuristic value
        for neighbor in graph.neighbors(node):
            if neighbor not in visited:
                heapq.heappush(queue, (heuristic[neighbor], neighbor, path))

    # If no path is found, return an empty list, infinity for path length, and the number of node expansions
    return [], float("inf"), node_expansions

A* Search

It tries to balance two things: how much progress has already been made, and how much further there is to go (based on the heuristic). If the heuristic is well-designed, A* can find the best path quickly and reliably.

def a_star(graph, start, goal, heuristic):
    # Initialize the priority queue with the starting node, cost 0, its heuristic value, and an empty path
    queue = [(heuristic[start], 0, start, [])]
    # Set to keep track of visited nodes
    visited = set()
    # Counter to keep track of node expansions
    node_expansions = 0

    while queue:
        # Dequeue the node with the lowest cost + heuristic value
        _, cost, node, path = heapq.heappop(queue)

        # If the node has been visited, skip it
        if node in visited:
            continue

        # Mark the node as visited
        visited.add(node)

        # Append the current node to the path
        path = path + [node]

        # If the goal is reached, return the path, its length, and the number of node expansions
        if node == goal:
            return path, cost, node_expansions

        # Increment the node expansions counter
        node_expansions += 1

        # Add all unvisited neighbors to the priority queue with their cumulative cost + heuristic value
        for neighbor in graph.neighbors(node):
            if neighbor not in visited:
                # This line retrieves the weight (or cost) of the edge between the current node and the neighbor.
                # The code uses .get("weight", 1) to get the weight of the edge, with a default value of 1 if the weight is not specified.
                edge_weight = graph.edges[node, neighbor].get("weight", 1)
                total_cost = cost + edge_weight
                heapq.heappush(
                    queue,
                    (total_cost + heuristic[neighbor], total_cost, neighbor, path),
                )

    # If no path is found, return an empty list, infinity for path length, and the number of node expansions
    return [], float("inf"), node_expansions

Designing good heuristics is an art of its own. A heuristic must be efficient to compute and ideally never overestimate the true cost. When done right, it can drastically improve performance, especially in large or complex search spaces.

Why Search Matters

Search algorithms are the decision-making backbone of many AI systems: robot navigation, game playing, logistics, and even basic planning in smart assistants.

Each algorithm offers trade-offs in speed, memory, and optimality. Some are fast but risky, others are thorough but slow. Choosing the right one depends on what your agent is trying to do, and how much it knows about the world.

Understanding search is the first step in designing agents that can act intelligently, not just react, but think ahead, reason with uncertainty, and solve problems.

Looking Ahead

So far, we’ve focused on planning, choosing actions in a known world. But what if the world is unknown, complex, or constantly changing?

That’s where learning comes in. In our next article, we’ll explore neural networks, how they learn patterns from data, recognise images, understand speech, and drive modern AI systems.

Artificial Intelligence is everywhere right now - in headlines, tools, startups, fears, and dreams. But the term gets thrown around so loosely that it’s easy to lose sight of what it actually means. Is AI just chatbots and neural networks? Is it machine learning? Is it robots? Is it Python?

This series aims to slow things down and build up a real understanding, piece by piece. In this series, we’ll explore the fundamental concepts in AI. We begin with the most basic (and most misunderstood) question: what even is AI?

A Brief History of the Idea of Intelligence

The quest to understand and replicate intelligence didn’t start with computers. It goes back over 2,000 years to philosophers, mathematicians, and logicians trying to formalise how we think, reason, and learn.

• Aristotle laid the early foundations of formal logic c. 350 BC.

• Euclid’s algorithms, c. 300 BC, anticipated procedural problem-solving.

• Francis Bacon introduced inductive reasoning in the 16th century - an early precursor to learning from data.

• Thomas Bayes (17th century) and Blaise Pascal (18th century) laid the foundations of probabilistic reasoning.

• Alan Turing, in 1950, proposed the imitation game and imagined a child machine - a mind that could learn and grow through experience.

By the time the term “Artificial Intelligence” was coined at the Dartmouth Conference in 1956, many of the core ingredients were already in place: logic, search, probability, learning, and formal systems.

“I believe that in about fifty years time [2000] it will be possible to programme computers to make them play the imitation game so well that an average interrogator will not have more than 70 per cent chance of making the right identification after five minutes of questioning.” - Alan Turing

So, What Is AI?

At its core, intelligence is the ability to perceive, reason, and act adaptively in response to a changing environment. Artificial Intelligence, then, is the field that aims to build systems that can do exactly that - not just compute, but behave intelligently. Russell & Norvig’s classic textbook frames it around four perspectives:

“Systems that think humanly, act humanly, think rationally, or act rationally.”

That’s a broad space - and on purpose. AI isn’t one technique. It’s a long-term attempt to make machines that behave intelligently, however that’s defined.

AI Is Not ML Is Not DL

Let’s clear up a common confusion:

• Artificial Intelligence (AI) is the goal: intelligent behaviour.

• Machine Learning (ML) is one approach to achieving that goal, focused on learning from data.

• Deep Learning (DL) is a type of ML model.

• Python (or any language) is just a tool, not part of the definition.

We can build AI without learning, and we can use learning without achieving intelligence.

Thinking in Terms of Agents

One of the most useful ways to understand AI systems is to think in terms of agents - entities that perceive their environment and act upon it to achieve specific goals. This agent-based view helps us break down complex behaviours into manageable, modular components.

Agents come in many forms, each with increasing levels of sophistication:

• Reactive agents respond directly to their current sensory input. They don’t store memory or learn - they simply react based on predefined rules. Think of a basic obstacle-avoiding robot.

• Model-based agents go a step further by maintaining an internal representation (or model) of the world. This allows them to handle partial information and make decisions based on past perceptions, not just current input.

• Goal-based agents evaluate possible actions against desired outcomes. Instead of blindly following rules, they consider what they’re trying to achieve and plan accordingly.

• Utility-based agents assign value (or “utility”) to outcomes and choose actions that maximise expected benefit, often weighing trade-offs under uncertainty.

• Learning agents improve over time. They adapt their behaviour based on experience, feedback, or exploration, allowing them to function effectively even in changing or unknown environments.

This layered framework allows us to build intelligent behaviour incrementally, starting with simple reflexes and evolving toward agents that can plan, evaluate, and adapt in complex environments.

Why Knowledge Matters

But sensing and acting aren’t enough. To behave truly intelligently, an agent must have some understanding of how the world works. That’s where knowledge representation and reasoning (KRR) come in. KRR is a fundamental area of AI that focuses on how knowledge about the world can be formally represented and used by a machine to solve complex tasks. This discipline intertwines the cognitive aspects of how humans understand and process information with the computational methods necessary for enabling machines to exhibit intelligent behaviour.

AI systems need a way to structure information about the world - facts, rules, relationships, categories - so that they can reason, infer, and make informed decisions. This is more than storing data; it’s about organising information in a way that supports meaningful conclusions.

Common approaches include:

• Symbolic logic, such as propositional and first-order logic, which allows systems to make precise, rule-based inferences.

• Ontologies and taxonomies, which define structured hierarchies of categories and concepts, like “a car is a kind of vehicle.”

• Rule-based systems that encode expert knowledge as a series of “if-then” statements.

• Semantic networks, where objects, attributes, and relationships are connected in graph-like structures for efficient reasoning.

These methods allow AI agents to go beyond reactive behaviour. For example, if a system knows: all fruit is edible, and apples are fruit, it can logically infer that apples are edible. That’s reasoning - not hardcoded knowledge, but structured inference drawn from more general principles. In short, knowledge representation enables AI to move from responding to understanding - from executing actions to explaining why those actions make sense.

Looking Ahead

Artificial Intelligence is not just deep learning, chatbots, or hype. It’s the structured study of intelligent behaviour, grounded in perception, logic, learning, and reasoning. In this article, we unpacked its roots, core definitions, and the foundational idea of intelligent agents.

In the next article, we’ll explore one of the most fundamental tools in any intelligent system: search. What is search, and why is it needed? How does human search compare to how machines search? And how do we translate real-world problems into ones a machine can solve efficiently.

See you then!

Over the years, I’ve landed on a setup that saves mental overhead, keeps the codebase clean and scales well across teams and projects. In this guide, I’ll walk you through how I configure Prettier, ESLint with Airbnb’s style guide, Stylelint, Husky and lint-staged in a Node.js environment.

Let’s start with a high-level view of what each tool brings to the table.

📦 Overview: What Each Tool Does (and Why You Need It)

When combined, these tools reduce the surface area for bugs, reduce friction in code reviews and let you focus on solving real problems — not arguing about trailing commas.

🧹 Step 1: Prettier — Your Formatting Backbone

Prettier is an opinionated formatter. It doesn’t care how you want your code to look — it enforces a consistent, readable style. It supports many file types: .html, .json, .js, .ts, .css, .scss, .md, etc.

🔧 Install

npm install --save-dev prettier

Create a .prettierrc file at the root of your project. You can modify these settings as per your preferences. Refer to the Prettier documentation for all available options. Here's a sample configuration I use:

{
  "bracketSpacing": true,
  "printWidth": 120,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "all"
}

Why these settings?

• bracketSpacing - Improves readability with space inside object literals: { key: value }.

• printWidth - I find 80 too cramped; 120 gives more breathing room, especially for modern monitors.

• singleQuote - JavaScript traditionally uses single quotes; this reduces diff noise and aligns with many style guides.

• tabWidth - Standard size, especially in JS/TS communities.

• trailingComma - Makes diffs cleaner and reduces bugs when adding new lines.

Create a .prettierignore file at the root of your project to exclude files/directories you don’t want Prettier to touch — generated files, IDE configs, etc.

node_modules
build
dist
coverage
.vscode

🧠 Step 2: ESLint + Airbnb — Code Quality & Best Practices

Where Prettier handles style, ESLint enforces logic and structure. It catches things like unused variables, accidental globals and subtle syntax issues.

The Airbnb style guide is battle-tested and opinionated. It promotes clarity, consistency and best practices out of the box.

🔧 Install dependencies

npm install --save-dev eslint eslint-plugin-node eslint-config-node
npm install --save -dev eslint-plugin-prettier eslint-config-prettier
npx install-peerdeps --dev eslint-config-airbnb-base

Note: Use eslint-config-airbnb instead of airbnb-base if you’re working with React.

Create an .eslintrc.json file at the root of your project. Here's a sample configuration that uses the Airbnb base rules (which exclude React-specific rules). It also adds Prettier and node config as a rule. Check out ESLint docs for full sets of available rules:

{
  "env": {
    "browser": true,
    "commonjs": true,
    "es2021": true
  },
  "extends": ["airbnb-base", "prettier", "plugin:node/recommended"],
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "warn",
    "no-console": "warn",
    "no-unused-vars": "warn",
    "no-shadow": "off",
    "no-underscore-dangle": "off"
  }
}

Key rules explained:

• prettier/prettier - ESLint surfaces Prettier issues, but only as warnings.

• no-console - Logs are useful during development, but shouldn’t ship to prod.

• no-unused-vars - Helps avoid bloated, misleading code.

• no-underscore-dangle - I often use _id from MongoDB, so this rule gets turned off.

🎨 Step 3: Stylelint — Keep Your Stylesheets Clean

Stylelint works just like ESLint, but for styles. It ensures your SCSS/CSS is consistent, avoids deprecated syntax and promotes clean layout logic.

🔧 Install

npm install --save-dev sass stylelint stylelint-config-standard-scss stylelint-config-prettier

Create .stylelintrc.json in the project root. Here's a sample configuration:

{
  "extends": ["stylelint-config-standard-scss", "stylelint-config-prettier"],
  "rules": {
    "color-function-notation": "legacy",
    "selector-class-pattern": null
  }
}

What this does:

• standard-scss gives us a solid base config for SCSS.

• tylelint-config-prettier disables rules that conflict with Prettier.

• We relax strict class naming rules selector-class-pattern to suit different naming conventions (BEM, utility-first, etc.).

⚡ Step 4: lint-staged — Lint Only What Changed

Without lint-staged, Husky would run ESLint/Prettier on the whole codebase for every commit. That’s slow and unnecessary. lint-staged is a package that can be used to run formatting and linting commands on staged files in a Git repo.

🔧 Install

npm install --save-dev lint-staged

lint-staged will run specific commands on staged files before committing them. Add the following configuration to your package.json. The below configures lint-staged to run Prettier, Stylelint and ESLint. Only add the Stylelint script for front-end projects:

"lint-staged": {
  "*.{js,ts,jsx,tsx}": ["prettier --write", "eslint"],
  "*.{css,scss,json,md}": ["prettier --write", "stylelint --allow-empty-input"]
}

This setup makes sure only staged files are linted/formatted, keeping pre-commit hooks fast and focused.

🔐 Step 5: Husky — Git Gatekeeper

Husky allows us to run scripts at key Git lifecycle moments. Here, we’ll use it to run lint-staged before any commit. Thus code only ever gets into the repo after it has been consistently formatted and verified to be free of linting errors. This is a particularly big advantage in a team setting.

🔧 Install and set up

npm install --save-dev husky
npx husky init

The init command simplifies setting up Husky in a project. It creates a pre-commit script in .husky/ and updates the prepare script in package.json. Modifications can be made later to suit your workflow.

Update the .husky/pre-commit file:

npx lint-staged

This ensures your staged files pass all checks before being committed.

Create .husky/install.mjs file:

// Skip Husky install in production and CI
if (process.env.NODE_ENV === 'production' || process.env.CI === 'true') {
    process.exit(0);
}

const husky = (await import('husky')).default;
console.log(husky());

This ensures husky is only installed in dev environment.

🛠️ Step 6: Helpful NPM Scripts

Add these to your package.json for manual use or CI pipelines, adjust according to your project setup:

"scripts": {
  "lint": "eslint './**/*.@(js|jsx|ts|tsx)'",
  "lint:fix": "eslint './**/*.@(js|jsx|ts|tsx)' --fix",
  "prettier:check": "prettier --check './**/*.{js,ts,json,md,css,scss}'",
  "prettier:write": "prettier --write './**/*.{js,ts,json,md,css,scss}'",
  "style:check": "stylelint '**/*.{css,scss}' --allow-empty-input",
  "prepare": "node .husky/install.mjs"
}

• lint - This script will run ESLint on all JavaScript, TypeScript, JSX and TSX files in your project.

• lint:fix - This will do the same as the lint script but will also attempt to automatically fix any issues that ESLint can handle.

• prettier:write - This script will format all JS, JSX, TS, TSX, JSON, CSS, SCSS and Markdown files using Prettier. This ensures consistency in both code and documentation.

• prettier:check - This will check if all the specified files adhere to the formatting rules specified by Prettier. This is especially useful as a pre-commit or CI/CD step to ensure that no non-formatted files get committed or deployed.

• style:check - This will check if all the specified CSS, SCSS files adhere to the formatting rules specified by Stylelint. Only add for front-end projects.

• prepare - This will only run Husky in a non-production environment.

You can adjust the patterns like ./**/*.@(js|jsx|ts|tsx|json|css|scss|md) to fit the specific needs of your project, and which directories or file types you want to include/exclude.

⚙️ Using in your Workflow

Whenever you're about to commit, you can run:

git add .
git commit -m "Set up linting and formatting"
# lint-staged script will run every time you commit

This will ensure that your code is both linted and formatted. If anything had not been set up correctly, you would likely get errors during commit.

🧩 Bonus: VS Code Setup for Auto-Formatting

To make all of this seamless, configure VS Code to format on save and use the following extensions:

• ESLint

• Stylelint

• Prettier - Code formatter

Put the following in .vscode/settings.json in the project (you can also put these settings in your User Preferences file):

{
    "[javascript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "typescript.tsdk": "node_modules/typescript/lib",
    "[typescript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[javascriptreact]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[typescriptreact]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[scss]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "scss.lint.emptyRules": "ignore",
    "stylelint.validate": ["css", "scss"],
    "editor.formatOnSave": true
}

The above set up, will allow the extensions to lint and format on Save.

✅ Final Thoughts

This setup may feel like a lot up front, but once it’s in place, it quietly handles all the repetitive formatting, catches subtle issues and keeps your Git history clean.

It’s not about obsessing over code style. It’s about freeing up mental bandwidth so you can focus on solving real problems, not arguing over trailing commas or indentation.

🤔 What Do You Use?

I’d love to hear how others approach this:

• What’s your go-to setup?

• Any must-disable rules in your projects?

• Do you skip this entirely for small experiments?

Let me know your take. Always curious to hear how other devs keep their code clean.