On my NextJS projects, I typically use the next-intl module for localization.

Next-intl requires a folder with JSON files for each supported locale, e.g. en.json, es.json, fr.json etc. This script generates those files automatically starting from the en.json file, using the Gemini API to translate the text.

import {promises as fs} from 'fs';
import path from 'path';

const supportedLocales = ['en', 'es', 'fr', 'de', 'it', 'ja']; // Edit this list as needed

const googleGenAI = new GoogleGenAI({apiKey: process.env.GOOGLE_API_KEY});

function errorAndExit(message: string): never {
  console.error(message);
  process.exit(1);
}

function findJsonInText(text: string): any | null {
  const jsonStart = text.indexOf('{');
  const jsonEnd = text.lastIndexOf('}');
  if (jsonStart === -1 || jsonEnd === -1 || jsonEnd <= jsonStart) {
    return null;
  }
  const jsonString = text.substring(jsonStart, jsonEnd + 1);
  try {
    return JSON.parse(jsonString);
  } catch (e) {
    console.error('Failed to parse JSON:', e);
    return null;
  }
}

async function translateWithAi(text: string, targetLocale: string): Promise<any> {
  const prompt = `Create the i18n from english to ${targetLocale}. Output only the new JSON, no commentary.\n${text}`;
  const response = await googleGenAI.models.generateContent({
    model: 'gemini-2.5-flash',  // 'gemini-2.5-pro' if you feel like trying a more powerful model
    contents: prompt,
    config: {}
  });
  if (!response.candidates || response.candidates.length === 0 || !response.candidates[0].content) {
    throw new Error('No translation candidates received from Gemini API');
  }
  const parts = response.candidates[0].content.parts;
  if (!parts || parts.length === 0) return errorAndExit('No translation parts received from Gemini API');
  const responseText = parts.map(part => part.text).join('');
  const translatedJson = findJsonInText(responseText);
  if (!translatedJson) {
    throw new Error('Failed to extract JSON from Gemini response');
  }
  return translatedJson;
}

export async function updateI18n(messagesDir: string) {
  try {
    const sourceFile = path.join(messagesDir, 'en.json');
    const sourceContent = await fs.readFile(sourceFile, 'utf-8');
    console.log('sourceContent:', sourceContent);
    const sourceJson = JSON.parse(sourceContent);
    const targetLocales = supportedLocales.filter(locale => locale !== 'en');
    for (const locale of targetLocales) {
      console.log(`Generating translation for locale: ${locale}`);
      const translatedJson = await translateWithAi(JSON.stringify(sourceJson), locale);
      const targetFile = path.join(messagesDir, `${locale}.json`);
      await fs.writeFile(targetFile, JSON.stringify(translatedJson, null, 2));
      console.log(`Successfully wrote translations to ${targetFile}`);
    }
  } catch (error) {
    console.error('Failed to update i18n files:', error);
  }
}

const args = process.argv.slice(2);
if (args.length < 1) return errorAndExit('Usage: tsx update-i18n.ts <messagesDir>');
const messagesDir = args[0];
updateI18n(messagesDir);

To run it, pass your GOOGLE_API_KEY in the environment and run the script with the path to your messages directory:

GOOGLE_API_KEY="your_api_key" tsx update-i18n.ts ./path/to/messages/folder

TL;DR

• Vibe coding is fine for prototypes. When projects get complicated, vibing doesn't work
• Unvibe is a Python Test Runner that quickly generates many alternative implementations for functions and classes you annotate with @ai, and re-runs your unit-tests until it finds a correct implementation.
• So you "Vibe the unit-tests", and then search a correct implementation.
• This scales to larger projects and applies to existing code bases, as long as they are decently unit-tested.

A different way to generate code with LLMs

In my daily work as consultant, I'm often dealing with large pre-existing code bases.

I use GitHub Copilot a lot. It's now basically indispensable, but I use it mostly for generating boilerplate code, or figuring out how to use a library. As the code gets more logically nested though, Copilot crumbles under the weight of complexity. It doesn't know how things should fit together in the project.

Other AI tools like Cursor or Devon, are pretty good at generating quickly working prototypes, but they are not great at dealing with large existing codebases, and they have a very low success rate for my kind of daily work. You find yourself in an endless loop of prompt tweaking, and at that point, I'd rather write the code myself with the occasional help of Copilot.

Professional coders know what code they want, we can define it with unit-tests, we don't want to endlessly tweak the prompt. Also, we want it to work in the larger context of the project, not just in isolation.

In this article I am going to introduce a pretty new approach (at least in literature), and a Python library that implements it: a tool that generates code from unit-tests.

My basic intuition was this: shouldn't we be able to drastically speed up the generation of valid programs, while ensuring correctness, by using unit-tests as reward function for a search in the space of possible programs?

I looked in the academic literature, it's not new: it's reminiscent of the approach used in DeepMind FunSearch, AlphaProof, AlphaGeometry and other experiments like TiCoder: see Research Chapter for pointers to relevant papers. Writing correct code is akin to solving a mathematical theorem. We are basically proving a theorem using Python unit-tests instead of Lean or Coq as an evaluator.

For people that are not familiar with Test-Driven development, read here about TDD and Unit-Tests.

How it works

I've implemented this idea in a Python library called Unvibe. It implements a variant of Monte Carlo Tree Search that invokes an LLM to generate code for the functions and classes in your code that you have decorated with @ai.

Unvibe supports most of the popular LLMs: Ollama, OpenAI, Claude, Gemini, DeepSeek.

Unvibe uses the LLM to generate a few alternatives, and runs your unit-tests as a test runner (like pytest or unittest). It then feeds back the errors returned by failing unit-test to the LLMs, in a loop that maximizes the number of unit-test assertions passed. This is done in a sort of tree search, that tries to balance exploitation and exploration.

As explained in the DeepMind FunSearch paper, having a rich score function is key for the success of the approach: You can define your tests by inheriting the usual unittests.TestCase class, but if you use unvibe.TestCase instead you get a more precise scoring function (basically we count up the number of assertions passed rather than just the number of tests passed).

It turns out that this approach works very well in practice, even in large existing code bases, provided that the project is decently unit-tested. This is now part of my daily workflow:

1. Use Copilot to generate boilerplate code

2. Define the complicated functions/classes I know Copilot can't handle

3. Define unit-tests for those complicated functions/classes (quick-typing with GitHub Copilot)

4. Use Unvibe to generate valid code that pass those unit-tests

It also happens quite often that Unvibe find solutions that pass most of the tests but not 100%: often it turns out some of my unit-tests were misconceived, and it helps figure out what I really wanted.

Example: how to use unvibe

1. pip install unvibe
2. Decorate the functions/classes you want to generate with @ai. Type annotations and proper comments will help the LLM figure out what you want. For example

# list.py
from unvibe import ai


@ai
def lisp(expr: str):
    """A simple lisp interpreter implemented in plain Python"""
    pass

Now let's define a few unit-tests to specify the behaviour of the function. Here Copilot can help us come up quickly with a few test cases. As you can see, we are looking to implement a Lisp interpreter that supports basic python functions (e.g. range) and returns python-compatible lists.

This simple Lisp interpreter is a good example because it's the sort of function that LLMs (even reasoning models) cannot generate from scratch, but they can get there with Unvibe:

# test_lisp.py
import unvibe
from lisp import lisp


# Here you can instead inherit unvibe.TestCase, to get a more granular scoring function
class LispInterpreterTestClass(unvibe.TestCase):
    def test_calculator(self):
        self.assertEqual(lisp("(+ 1 2)"), 3)
        self.assertEqual(lisp("(* 2 3)"), 6)

    def test_nested(self):
        self.assertEqual(lisp("(* 2 (+ 1 2))"), 6)
        self.assertEqual(lisp("(* (+ 1 2) (+ 3 4))"), 21)

    def test_list(self):
        self.assertEqual(lisp("(list 1 2 3)"), [1, 2, 3])

    def test_call_python_functions(self):
        self.assertEqual(lisp("(list (range 3)"), [0, 1, 2])
        self.assertEqual(lisp("(sum (list 1 2 3)"), 6)

3) Now run unvibe and let it search for a valid implementation that passes all the tests:

$ python -m unvibe lisp.py test_lisp.py

Unvibe will run until it reaches a maximum number of iterations or until it finds a solution that passes all the tests, in which case it will stop early. The output will be written to a local file unvibe_lisp_<timestamp>.py:

# Unvibe Execution output.
# This implementation passed all tests
# Score: 1.0
# Passed assertions: 7/7 

def lisp(exp):
    def tokenize(exp):
        return exp.replace('(', ' ( ').replace(')', ' ) ').split()

    def parse(tokens):
        if len(tokens) == 0:
            raise SyntaxError('Unexpected EOF')
        token = tokens.pop(0)
        if token == '(':
            L = []
            while tokens[0] != ')':
                L.append(parse(tokens))
            tokens.pop(0)  # Remove ')'
            return L
        elif token == ')':
            raise SyntaxError('Unexpected )')
        else:
            try:
                return int(token)
            except ValueError:
                return token

    def evaluate(x):
        if isinstance(x, list):
            op = x[0]
            args = x[1:]
            if op == '+':
                return sum(evaluate(arg) for arg in args)
            elif op == '*':
                result = 1
                for arg in args:
                    result *= evaluate(arg)
                return result
            elif op == 'list':
                return [evaluate(arg) for arg in args]
            else:
                # Call Python functions
                return globals()[op](*[evaluate(arg) for arg in args])
        return x

    tokens = tokenize(exp)
    return evaluate(parse(tokens))

As you can see, Unvibe has found a valid implementation. At this point, in my typical workflow, I would now add more tests and eventually let Unvibe find other solutions.

Configuration

For more details, se the 🐙 GitHub Project page.

To configure unvibe, create in your project folder a .unvibe.toml file with the following example configuration. You can use your local Ollama or an OpenAI, Anthropic, Gemini or DeepSeek API key.

I've found that the latest Claude works well for generating complex code, and it's also one of the cheapest and with the largest context. I've seen also all my benchmark tests pass with qwen2.5-coder:7b running locally on my Macbook via Ollama, but in general larger models are better (> 20B params). So probably, you don't want to run the LLM locally for this use, unless you have a solid GPU. To prevent the same code to be generated multiple times, you can use a cache provider. By default unvibe uses a cash on disk to prevent the same code to be generated multiple times.

# .unvibe.toml

[ai]
provider = "claude"  # or "ollama", "openai", "gemini"
api_key = "sk-..."
model = "claude-3-5-haiku-20241022" # try also 'claude-3-7-sonnet-20250219'
max_tokens = 5000

#[ai]
#provider = "ollama"
#host = "http://localhost:11434"
#host = "http://host.docker.internal:11434" # if running from Docker
#model = "qwen2.5-coder:7b"  # try also "llama3.2:latest", "deepseek-r1:7b"

[search]
initial_spread = 10     # How many random tries to make at depth=0.
random_spread = 2       # How many random tries to make before selecting the best move.
max_depth = 30          # Maximum depth of the search tree.
max_temperature = 1     # Tries random temperature, up to this value.
max_minutes = 60        # Stop after 60 minutes of search.
                        # Some models perform better at lower temps, in general
                        # Higher temperature = more exploration.
cache = true            # Caches AI responses to a local file to speed up re-runs and
                        # save money.

Which models work best

The models that I've found work best, are either small coding models (~7B params), or large generic models (>20B params).

My favourite for models for Unvibe are:

• qwen2.5-coder:7b: It's available on Ollama, it runs great on my Macbook M2, and it's very good at coding.
• Claude Haiku: probably the cheapest model that is good at coding.
• Claude Sonnet 3.7: probably the best coding model

Reasoning models can help sometimes, but in practice they are slower. I prefer to try my luck with small models on my Mac and then switch to Sonnet 3.7 if I don't get good results. As a future improvement it would be nice to support multiple models, and have Unvibe swap between them if the score plateaus.

Sandboxing

By default, Unvibe runs the tests on your local machine. This is very risky, because you're running code generated by an LLM: it may try anything. In practice, most of the projects I work on, run on Docker, so I let Unvibe run wild inside a Docker container, where it can't do any harm. This is the recommended way to run Unvibe. Another practical solution is to create a new user with limited permissions on your machine, and run Unvibe as that user.

Search algorithm

There are multiple approaches to search the space of possible programs. With Unvibe I tried to strike for something that works in practice without requiring a GPU cluster. The idea was that it should be practical to run it only using a Macbook and Ollama.

DeepMind's FunSearch, which was designed to find mathematical discoveries via program search, uses a variation of Genetic programming with LLMs. It splits the code generation attempts into Islands of clusters, and let the clusters evolve (via partial code substitution), and then samples from the clusters with higher scores. They basically sample from the clusters with probability = Softmax of the scores (corrected by some temperature).

FunSearch is supposed to work on large datacenters. For Unvibe instead I use currently a much simpler tree search: We start with a random initial tree spread, attempting different LLM temperatures and then, we pick the most promising nodes and try again. This is much more suitable for running on a Macbook. So you end up with a search tree that looks like this:

This is a live UI I'm working on, to explore the Search tree as it progresses. Likely coming in Unvibe v2. You can already give it a try by passing the parameter -d.

TODO

I will extend unvibe with more features soon, and I'm actively looking people to help write Typescript/Java/C#/etc. versions. Some features I'm working on:

• HTML based UI to explore the search graph and look at the reward function rise. Some is already implemented: for nested code it's nice to see in real-time if the LLM is making progress.
• Support multiple LLMs, and have Unvibe swap between them if the score plateaus.
• Support for other programming languages
• Integration with Pytest

Research

Similar approaches have been explored in various research papers from DeepMind and Microsoft Research:

• FunSearch: Mathematical discoveries from program search with large language models (Nature)

• Gold-medalist Performance in Solving Olympiad Geometry with AlphaGeometry2 (Arxiv)

• AI achieves silver-medal standard solving International Mathematical Olympiad problems (DeepMind)

• LLM-based Test-driven Interactive Code Generation: User Study and Empirical Evaluation (Axiv)

v4 is out! with Cuda support, new GUI, and many languages now supported 🇺🇸 🇬🇧 🇪🇸 🇫🇷 🇮🇳 🇮🇹 🇯🇵 🇧🇷 🇨🇳!

Thanks to a lot of people spontaneously contributing Pull Requests, we have made a lot of improvements to Audiblez, my little tool to convert ebooks into audiobooks has grown incredibly. Turns out that people really want to use this thing! Finally, it works on CUDA too. I get ~500 chars/sec on Google Colab T4, which is about 6 minutes to convert "Moby Dick" to audiobook.

In v4.0 you'll find:

• Multi-platform GUI based on wxWidgets
• Other languages than english finally work great: voices vary in quality and in general English voices are the best, but they are better than most TTS around.
• Moved away ONNX to raw Torch via kokoro python package
• CUDA acceleration is now supported, but Apple Silicon defaults to CPU (no mlx kokoro implementations at the moment)
• Cover image carried over to final audiobook
• Chapter timestamps in the audiobook
• Better support for Windows

Voices Samples

These are some samples of the voices available in Audiblez:

About Audiblez

🐙 Project on GitHub

Audiblez generates .m4b audiobooks from regular .epub e-books, using Kokoro's high-quality speech synthesis.

Kokoro-82M is a recently published text-to-speech model with just 82M params and very natural sounding output. It's released under Apache licence and it was trained on < 100 hours of audio. It currently supports these languages: 🇺🇸 🇬🇧 🇪🇸 🇫🇷 🇮🇳 🇮🇹 🇯🇵 🇧🇷 🇨🇳

On a Google Colab's T4 GPU via Cuda, it takes about 5 minutes to convert "Animal's Farm" by Orwell (which is about 160,000 characters) to audiobook, at a rate of about 600 characters per second.

On my M2 MacBook Pro, on CPU, it takes about 1 hour, at a rate of about 60 characters per second.

How to install the Command Line tool

If you have Python 3 on your computer, you can install it with pip. You also need espeak-ng and ffmpeg installed on your machine:

sudo apt install ffmpeg espeak-ng                   # on Ubuntu/Debian 🐧
pip install audiblez

brew install ffmpeg espeak-ng                       # on Mac 🍏
pip install audiblez

Then you can convert an .epub directly with:

audiblez book.epub -v af_sky

It will first create a bunch of book_chapter_1.wav, book_chapter_2.wav, etc. files in the same directory, and at the end it will produce a book.m4b file with the whole book you can listen with VLC or any audiobook player. It will only produce the .m4b file if you have ffmpeg installed on your machine.

How to run the GUI

The GUI is a simple graphical interface to use audiblez. You need some extra dependencies to run the GUI:

sudo apt install ffmpeg espeak-ng 
sudo apt install libgtk-3-dev        # just for Ubuntu/Debian 🐧, Windows/Mac don't need this

pip install audiblez pillow wxpython

Then you can run the GUI with:

audiblez-ui

Speed

By default the audio is generated using a normal speed, but you can make it up to twice slower or faster by specifying a speed argument between 0.5 to 2.0:

audiblez book.epub -v af_sky -s 1.5

Supported Voices

Use -v option to specify the voice to use. Available voices are listed here. The first letter is the language code and the second is the gender of the speaker e.g. im_nicola is an italian male voice.

How to run on GPU

By default, audiblez runs on CPU. If you pass the option --cuda it will try to use the Cuda device via Torch.

Check out this example: Audiblez running on a Google Colab Notebook with Cuda .

We don't currently support Apple Silicon, as there is not yet a Kokoro implementation in MLX. As soon as it will be available, we will support it.

In the time it would have taken me to learn Hugo or Jekyll, I wrote a simple static site generator in Python. It uses Jinja2 for templating and Markdown for content. It's just HTML and Markdown, and the best part is that you can easily understand how it works and modify it to your needs, since it's only 90 lines of code.

How to use it

The file structure is simple:

/ 
    /build
        ...all the HTML files generated by Cacty
    /static
        ...your CSS, JS, images, etc.
    /templates
        _base.html
        _analytics.html
        index.html
        post.html
        posts.html
    /posts
        first-blog-post.md
        second-post.md
    cacty.py

Cacty reads any file like /templates/x.html and creates a web page called x.html. It will ignore any template file that starts with an underscore _, so you can use it for partial templates. For example /templates/about.html will be a web page, but templates/_footer.html will not. As it's usually done in Django, you can then use {% extends "templates/_base.html" %} in your templates to have a base template and have a consistent look and feel across your site.

To run Cacty, just run python cacty.py -w. Adding -w it will watch for changes in the /templates and /posts directories, and it will run a local http webserver and automatically open your browser at any file change.

That's all you need to know.

Deploy to your server

To deploy your site, just copy the build/ directory to your webserver. I use rsync for that:

#!/bin/sh
rsync -az build claudio.uk:/srv/sites/claudio/

Source code

This is the code for cacty.py:

"""Claudio's static site generator: https://claudio.uk/posts/cacty.html"""
import os, sys, markdown, time, datetime, http.server, socketserver
import markdown.extensions.fenced_code
import markdown.extensions.tables
from jinja2 import Environment, FileSystemLoader, select_autoescape
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler


def build():
    os.system('mkdir -p build/posts')
    jinja = Environment(loader=FileSystemLoader('.'), autoescape=select_autoescape())

    # Build all the markdown files from posts/x.md to build/posts/x.html,
    # using as base template/post.html
    posts = []
    for filename in os.listdir('posts'):
        with open(os.path.join('posts', filename), 'r') as md_file:
            md = markdown.Markdown(extensions=['fenced_code', 'tables', 'meta'])
            output_filename = filename.replace('.md', '.html')
            print(f'building post {output_filename}')
            post_html = md.convert(md_file.read())
            template = jinja.get_template('templates/post.html')
            meta = {k: v[0] for k, v in md.Meta.items()}
            meta['date'] = datetime.datetime.strptime(meta['date'], '%Y-%m-%d')
            if 'draft' in meta and meta['draft'].lower() == 'true': continue
            page_html = template.render(post=dict(html=post_html, **meta))
            with open(os.path.join('build', 'posts', output_filename), 'w') as output_file:
                output_file.write(page_html)
            page_name = filename.replace('.md', '.html')
            posts.append(dict(filename=filename, href=f'posts/{page_name}', **meta))
    posts = sorted(posts, key=lambda post: post['date'], reverse=True)

    # Build all templates/x.html, excluding those starting with an underscore (partials)
    for filename in os.listdir('templates'):
        if filename.split('.')[-1] not in ('html', 'xml') or filename.startswith('_') or filename == 'post.html':
            continue
        template_path = os.path.join('templates', filename)
        with open(template_path, 'r') as template_file:
            print(f'building page {filename}')
            template = jinja.get_template(template_path)
            html = template.render(posts=posts)
            with open(os.path.join('build', filename), 'w') as output_file:
                output_file.write(html)

    # Copy static/ into build/static
    os.system('mkdir -p build/static')
    os.system('cp -r static/* build/static/')
    print('build complete\n')


def watch_files():
    # If any file changes in templates/ posts/ or static/, rebuild the site.
    class Handler(FileSystemEventHandler):
        def __init__(self):
            super().__init__()
            self.last_run = time.time()

        def on_any_event(self, event):
            if time.time() - self.last_run < 1:
                return
            print(f'{event.src_path} changed, rebuilding')
            build()
            self.last_run = time.time()

    event_handler = Handler()
    observer = Observer()
    observer.schedule(event_handler, '.', recursive=True)
    print('watching files')
    observer.start()


def start_http_server():
    class Handler(http.server.SimpleHTTPRequestHandler):
        def __init__(self, *args, **kwargs):
            super().__init__(*args, directory='build', **kwargs)

    try:
        socketserver.TCPServer.allow_reuse_address = True
        with socketserver.TCPServer(("", 8123), Handler) as httpd:
            print("serving at http://localhost:8123")
            httpd.serve_forever()
    except KeyboardInterrupt as exc:
        httpd.shutdown()
        httpd.server_close()
        raise


if __name__ == '__main__':
    build()
    if '-w' in sys.argv:
        watch_files()
        start_http_server()

Dependencies

All the required Python dependencies are:

Jinja2==3.1.4
Markdown==3.7
MarkupSafe==2.1.5
watchdog==4.0.2