• Generate several drafts per prompt: the same model can write a great script and a weak one from the same prompt, so ToneBench scores five per task.
• Measure your LLM judges before trusting them. On the October 26, 2026 board, GPT-6.1 Sol gave OpenAI’s drafts 4.1 more points than the other LLM judges’ scores predict.
• For writing at scale, try about ten cheap drafts merged by a strong judge, one to three LLM review rounds, and always a human review.

Can you read an AI-generated script out loud without fully cringing? That’s what I wanted to answer with ToneBench, the writing benchmark I presented at the AI Engineer conference in New York in October 2026. Here’s exactly how it works, what it measures, and as many details as possible on how I built it, so that you can hopefully learn from it and improve your next evals. I’ll walk you through the whole benchmark and my best tips for working with LLM judges.

If you don’t know me, I’m Louis-François, CTO and co-founder of Towards AI, where we build AI solutions and train AI engineers.

A board drawn by Claude in Lucid

To make the visuals for this article and its video, I used a really cool tool, Lucid. I asked Claude to analyze the whole benchmark repo and visually build the entire presentation for me, so that I don’t have to do anything. Of course, I also gave it more context and brain-dumped what I wanted to cover.

All of it was made with just a few prompts, Claude Code and the Lucid MCP server. The visuals are really cool, and everything is customizable. I can zoom in, and we can comment on any part to ask for changes, and Claude can reply directly and make them.

Funnily enough, I made this diagram back in 2016, when I was in university. It covers some basic steps of an assembly course. So it’s kind of crazy to me that ten years later, I’m using their agentic tools, with Claude building in Lucid to visualize things and communicate with my team.

And I thought it was the perfect way to show how I built the benchmark and all the steps inside it. There are tons of cool features: you can zoom in on each of the sub-presentations, and Claude created small buttons to go to the next step, and the next one, and the next one. It’s really convenient, and you can customize every single piece of it. You can really do anything with Lucid.

What slop is made of

Quick context if you haven’t seen my release of the benchmark: it’s about helping to stop slop. Slop starts with the overused words we all know, like “delve” or “seamlessly.” But the other parts are, in fact, much worse.

Worse than the slop words, slop text is usually too general. It says “most teams,” “most projects.” Unfortunately, I’m even guilty of doing that on LinkedIn myself, but to be fair, that’s the LinkedIn meta. I’ve learned from it, and I really try to be as specific as possible now.

Even worse than sloppy words and being general, a lot of the time, generated text says nothing. It’s just a bunch of nice words with hype, all stitched together. It’s really annoying to read and work with, especially when a teammate sends you a sloppy artifact they haven’t even reread.

Worse than saying nothing, it repeats itself a lot. If you work with Claude a lot, you know it repeats itself. You just want the outcome, to know what it did, but it keeps repeating the same thing multiple times.

Even worse, it hallucinates, as you know, so you can’t fully trust what it generates. And lastly, the worst thing for me: it has the wrong tone, or no tone at all. It talks like everyone, or like no one. It definitely doesn’t talk like me.

So the whole goal of ToneBench is to try to measure this sloppy writing, this creative writing: to measure if an AI system can sound like me, like my video scripts, like my writing style.

Everything on this board was built with Claude Code, but it all shows what’s actually implemented in ToneBench.

Setting up Lucid in Claude Code

If you want to replicate this setup, it’s really easy to do with Claude Code, in your repo. I just asked Claude to install it, but you only need the claude mcp add command to add Lucid:

claude mcp add --transport http lucid https://mcp.lucid.app/mcp

Then type /mcp, pick Lucid, open your browser, sign in, and that's it. Lucid's guide to the Lucid MCP server has the details.

From there, Claude can manage everything in Lucid for you and build these visuals easily. And of course, you can use it in ChatGPT, Cursor and a bunch of other tools, since it’s just an MCP server that all of them can connect to.

Just to test it, I asked it to find my oldest document on Lucid, and it was the 2016 diagram you saw above.

From there, I asked Claude to build the whole thing. I iterated on an artifact, a web page Claude builds that I review and comment on, with access to Lucid and the script, so that I could get all the different parts clearly designed. I commented on it directly, just like you could with your team in Lucid, but here with Claude.

So it’s direct iteration with Lucid and Claude artifacts, with Claude reading my comments and doing multiple rounds to improve the visuals.

How ToneBench works

Back to the board: what does ToneBench do and measure, exactly? It’s really simple. We take a task, which here means writing a script in my voice. We ask the model to do it, then we judge it, give it a score, and add it to the leaderboard.

We do that for every single model, and we don’t have just one task, but ten different writing tasks. As the board shows, each model writes five drafts per task (more on that very soon), rated by four judges: Claude Opus 5.5, GPT-6.1 Sol, GLM 5.3 Flash and Jev 1.13 (the panel as of the October 26, 2026 board).

I added Jev recently, and I could do a whole video on Jev. If you’re interested, let me know. Then we average the scores, calculate a Writing Score, and publish it on the website. I’ll go through this whole process from left to right, step by step, and share exactly what we implemented and how.

Obviously, I won’t share the exact prompts and tasks, because otherwise the benchmark would just get contaminated, and models could train on it. I don’t want that. But I’ll share as much as possible so that you can replicate the same setup.

To talk about scale: with ten tasks and five drafts each, every model has fifty drafts, which means two hundred judgments with four judges. That’s a lot of tokens, since each task is a long script, some of them about twenty minutes of reading. For the 141 configurations on the October 26, 2026 board, it adds up to about 1.6 billion tokens, in and out.

How a model writes one script

So what does the model that writes the script see? It gets my entire voice guide: how I write, how I talk, examples from my different scripts, and tons of tips on what I like and don’t like. Same thing for the storytelling guide, which is as detailed as possible on how to write properly: active sentences, keeping emotion throughout the text and letting it evolve, having a story end to end, all this stuff.

It also gets all the directions on what to generate and how: a full brief, and a full research document with citations to use, which we also use to measure the hallucination part.

Then all of this is fed to the model, and five drafts are generated and rated.

Why five drafts

We generate five drafts to measure intra-model variability. This is one thing Claude wouldn’t have suggested. Based on my background doing evals on tons of AI systems before this, I decided to measure the variability between generations from the same model and the same prompt, just to see if they generate the same thing.

And as you can see, they don’t, at all. Grok 4.7, for example, has a very big variance between generations, meaning it can generate a really bad script and a really good script totally at random. Compare that to Claude Opus 5.5, which is really consistent.

That’s not because of how our judges rate. It’s purely generation quality, because I also optimized our four judges so that this doesn’t happen. In any case, it’s really good to measure this variability for the same task repeated, just to see if it’s consistent, especially when you pick a final model for production.

How one draft gets its score

From there, we generate the five drafts. Here’s how we rate them, and what the judges base the final rating on. The prompt is quite big: around 20,000 words.

In short, we have eight different metrics with different rules, and each metric has tons of examples of what we’re looking for: what a good result looks like, what a bad result looks like. The judge also has access to the draft we just generated, so that it can judge it, plus further examples so that we can best guide it and calibrate it on real past scripts that we have.

Then our judges pick a score for each metric. First, the LLM judges identify quotes that best represent the current script. Then they give it a score and explain why the score fits. We do that for all eight metrics, plus two scores computed in code: the length, where we count the words to know if the draft respects what we asked for, and a slop score that uses EQ-Bench ‘s slop lists and our own slop scoring method.

Lastly, we calculate a weighted sum of all these metrics based on importance. The judges’ slop rating is folded into that slop score, so the Writing Score weighs nine metrics in the end. That’s for one judge. We then average all our judges, and do the same for our five different drafts.

The Tone & Voice ladder

To come up with the score, we actually have six main categories, and inside each one, a rating. We’ve seen that this worked best compared with binary scoring, probably because of the subjectivity of the task, and compared with using only categories or only percentages.

I don’t fully know why, but we measured everything, and this is the best middle ground we found for consistency and reliability, across our judges and across multiple generations rated. The judge first picks a main category, with tons of details on what each category is and examples of it, and then it picks a rating, again based on examples of what an 85 is on this task.

Honestly, I’ll keep growing it with more examples so that it’s even more reliable.

You definitely want to work hard on this part, which we call the rubric, because if your LLM judges are biased, the whole benchmark is biased, and thus useless.

Can we trust the judges?

I also measured whether our judges can be trusted at all, and this is what we found. The further out a point is, the more that judge favors that lab’s drafts. Take GPT-6.1 Sol, the green line: when it rates OpenAI models, it really favors them, by far. Likewise for Anthropic’s judge. And as you can see, which makes sense, Anthropic’s judge looks harsh on OpenAI’s drafts, and OpenAI’s judge looks harsh on Anthropic’s. That’s partly because the chart compares every judge with the other LLM judges, so when one is generous with its own lab, the others look harsh on it. And some models are more biased than others as judges.

GLM is quite good, and you really want to be near this black line, which means you wouldn’t be biased at all. Same thing for Claude, which is actually decently good. It obviously prefers its own lab, but not that much compared with the others.

Jev is quite weird as well: it prefers Alibaba’s drafts over others, and it also doesn’t seem to like OpenAI’s. I also recently tested adding Gemini as a judge, but it clearly preferred Google’s models, about as much as GPT-6.1 Sol prefers OpenAI’s, so I didn’t end up adding it.

I’m always looking to improve this whole system. Right now, I’m also always measuring whether adding more judges makes sense and helps the results or not.

Keeping the judges honest

To make it even more trustworthy, we add human time. We first did around a thousand ratings comparing two small excerpts and saying which one we prefer, so that our judges have some idea of our preferences.

But I think that wasn’t enough. So instead, we did 240 detailed human ratings, metric by metric, with all the details of what we think, and we used these 240 human ratings to calibrate the judges. So we measure whether the LLM judges rate the way we do.

And from there, I try to use this calibration to further update the benchmark.

How I’d write with AI today

Now for the part that may be the most interesting to a lot of you: how can you use this benchmark to write better? This is something I’m currently experimenting with. But from what I’ve seen, and based on what we discussed about intra-model variability, “worse” models generate very different scripts from one generation to the next, even with the same prompt.

So instead of using the best model on the benchmark, currently Claude Opus 5.5, to generate one draft at extra high effort, I would use a worse, smaller model like GLM-5.3 Flash, generate ten different drafts, and then pick and merge the best of each draft with a very powerful judge to create the final result.

This seems to be much better, because GLM-5.3 Flash is quite close to Opus 5.5, but it costs far less to run. So even if you generate ten drafts and use a judge to merge them, it’s way less expensive than generating one draft in one shot with Opus. On the October 26, 2026 board, GLM-5.3 Flash scores 81.8 for about $0.02 a draft, against 85.8 for about $1.00 a draft for Opus 5.5 at extra high effort.

And to give it the best input possible: as much detail as you can, tons of examples, exact examples of your voice and of what you want the generations to look like and not look like. If you can, even full past pieces, like past newsletter issues or past LinkedIn posts, whatever you want to generate.

Lastly, we also recommend one to three rounds of LLM judge review, not more. In my case, when I produce a draft, I use the LLM judge we have on the benchmark, run it once to give feedback to the writer, the writer improves the draft, and that’s it.

I just do one round, otherwise it spirals into sloppiness. And I’ve seen this to be extremely helpful for generation. All of this can be in one prompt: you ask the current LLM to spawn a subagent that judges and reviews the draft based on a review prompt you give it. It could be the exact same input prompt, and you just ask for a proper review with feedback, and then it rewrites once.

And ideally, you obviously want a human review, because this is where you add your own personal insights. You want it to be relatable, from humans to humans. People like to connect with someone specific, so it needs to be consistent across your posts, your videos, your content. And fortunately or unfortunately, Claude can’t do that part for you.

My notes and backlog, on the same board

So that’s the whole benchmark. It’s also how I used Lucid to explain how the benchmark works to my team, and here in this article. I also use it to note everything, and obviously, I didn’t design it. I wouldn’t have the patience to add Post-its and nice-looking stuff like this, but Claude did it for me. I really like that a tool I’ve been using for ten years can now help me automatically, just with Claude, integrated into my current setup. It’s amazing.

If you want to try Lucid and its agentic tools and MCP server, start at lucid.co. And if you want more insights on how to improve your AI writing, or more on the methodology behind the benchmark, it’s all on the ToneBench website and its methodology page.

A small warning before you pick a model

This benchmark really measures my own voice. If a model does well on it, it can probably adapt to your tone as well, if you prompt it as well as I did. So it’s really important to write a very good, detailed prompt. It’s the most important part. The benchmark is just a signal to:

1. use the top three models of the benchmark,
2. try them on your task,
3. and run your own evals with LLM judges, using the insights we just discussed, to measure them on your task.

I hope this was useful. If you want more details on any part, please let me know. I’d be happy to do a follow-up video with even more insights on LLM judges and how I made them more reliable, or anything you want to know about evals, this benchmark, or AI engineering in general.

What is ToneBench?

ToneBench is my writing benchmark at benchmark.towardsai.com. It measures whether a model can write a full YouTube script in my voice. As of the October 26, 2026 board, it ranks 141 configurations on 10 tasks, with five drafts each.

How do the LLM judges score one draft in ToneBench?

Each LLM judge quotes the draft first, picks one of six levels, then a score inside that level, and explains the score in one sentence, for eight metrics. Code adds the length and part of the slop score, and a weighted sum gives the Writing Score.

Why does ToneBench generate five drafts per task?

To measure intra-model variability. On the October 26, 2026 board, Grok 4.7 (high) ranked 28th with its best drafts and 62nd with its worst, while Claude Opus 5.5 (xhigh) stayed first or second whichever drafts you take.

Are LLM judges biased toward their own lab’s models?

Yes, measurably. On the October 26, 2026 board, GPT-6.1 Sol gave OpenAI’s drafts 4.1 extra points and Claude Opus 5.5 gave Anthropic’s 2.2, compared with what the other LLM judges’ scores predict. Averaging four judges from four makers means each preference reaches the Writing Score at a quarter of its size.

What is Jev, the fourth ToneBench judge?

Jev 1.13, from TypeSafe, is a typed judge: it writes no text and answers each metric by choosing among five described quality levels, with a probability for each. Its maker has no model on the board.

Which model should I use to write with AI?

Test the top three models of the benchmark on your own task. On the October 26, 2026 board, Claude Opus 5.5 at extra high effort scored 85.8 for about $1.00 a draft, and GLM-5.3 Flash scored 81.8 for about $0.02, which is why I would merge about ten cheap drafts with a strong judge.

How do I connect Lucid to Claude Code?

Run claude mcp add with the http transport and Lucid’s server URL, https://mcp.lucid.app/mcp, then type /mcp in Claude Code, pick Lucid and sign in through your browser. The same MCP server also works in ChatGPT, Cursor and other MCP clients.

How I Built An AI Writing Benchmark With LLM Judges was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Fable is making our work worse.

Or have we just collectively accepted that better models need less review?

I have been noticing this everywhere: people who delegate technical work to AI (especially AI engineers) seem to produce worse outputs on everything else. Even something like the descriptions in a GitHub repo. The code is fine, great even. It’s everything around it that is slipping.

The results are bland and general. No personality, no life.

On the other hand, the less “technical” people I work closely with have improved in both quality AND productivity.

I don’t yet know exactly why, but here’s my attempt to put it all together…

AI engineers (or just “AI enthusiasts”) are obviously more tech-forward. They adopt Claude Code, Codex, Fable, and similar tools earlier than everyone else.

They use them more. They are, in theory, better at them. They also know models hallucinate and why. They understand prompting, context, grounding, evaluation, agents, the intrinsic limitations of language models, and all the reasons we should not blindly trust an output.

But for anything beyond code, like writing, social media, presentations, educational content, research, even how ideas are structured and explained, the drop in quality from the most technical people is hard to miss. It was a hunch I’d had for some time, and it became obvious around the Fable launch.

I am not fully sure about the causation here. Maybe we have simply become much better at spotting AI slop. Maybe the internet has become so saturated with the same language and structures that anything resembling them immediately feels generated even if it’s not.

But I increasingly find myself quitting X or LinkedIn because of it. I also spend much more time actually editing the pieces people send me for review, whether from my team, clients, or friends.

And I don’t think it’s just my bubble. Just spend 30 minutes on LinkedIn in one sitting, and you’ll get what I mean.

To be honest, there’s nothing really surprising here. We all expected models to replace us on many tasks, one after another. We even hope they do, at least for the boring tasks we hate.

The thing is, a lot of us also fear “losing value” or becoming irrelevant. Watching it actually start to happen hurts. And it will keep happening if we stay on this “brain rot” trajectory: every generation automates more of our work, and the Fable tier was a big jump, especially for those of us who use it most.

So my analysis is that the problem may not be that people are bad at using AI. It may be almost the opposite. The better we get at delegating work to these systems, the easier it becomes to delegate things we probably should not.

The contrast with the non-technical side of the teams I work with is what sold me on this. Most of them don’t use Fable nearly as much, and if anything, they are moving towards more manual review. Towards where they can actually provide value (and the AI cannot, yet). “Non-technicals” might still use AI somewhere in the process, but they are much less likely to trust that the output is better just because it sounds complete. Especially not the final output they send their boss or post online.

I would bet most popular authors already use AI somewhere in their writing workflow, and their new books aren’t worse. If anything, they are more researched, more accurate, deeper.

So why are LinkedIn, X, technical courses, tutorials and articles so bland?

Because we, technical people, are lazy. We code to automate stuff. I started coding during my first internship to avoid copy-pasting the same line, with small variations, thousands of times into an Excel spreadsheet.

Unfortunately, though, we can’t automate quality. We know that. We still rely on Fable end-to-end to create things other humans are supposed to find valuable and interesting. Sure, maybe one day we all send generated messages that another agent summarizes and replies to on our behalf, and none of this matters. But until that happens, which I hope never does, I want to consume content that someone made. That someone poured thoughts and emotions into. Where they added real, relatable experiences. Real mistakes. Real problems they solved. Something Fable cannot do, even when prompted well. At least not without a human in the loop, especially to kickstart it and to finalize it.

The final editing round of our upcoming book made this painfully concrete. We started with a very clear plan. Tons of examples, code, experiences, project work. Fed everything to Fable and worked with it to produce an initial draft (with tons of iterations). After burning through token limits more times than I want to admit, the result was still… unreadable. We spent a week fine-tuning the first chapter to what we liked, then carefully regenerated everything based on that feedback. Yet, it still wasn’t nearly as good as we’d hoped for. After 2 AI engineer reviews, 3 human-writing-specific reviews, and my own comments and additions, we are starting to see something more promising. 18 days later. On just the very first chapter.

We tried everything with Fable, and even Astra. Extremely specific instructions on how we connect ideas, the layer below language. Tangible definitions of the ‘human essence’ we were after. And yet… the output is always almost there. Technically right, awkwardly phrased. (This is the reason I’ve been working on a creative writing benchmark for the last 4 months; more on this soon… 😉)

Most of us already know the rule: AI does 80% of the work; the last 20% comes from us.

The problem is that I don’t think we (the more technical people) are actually doing it.

As the models get better, they also get much better at making the 80% look like 100%. The output is complete, well structured, confident, usually technically right, and close enough that it becomes very easy to stop there. Especially when we just skim it. It seems fine.

But “looks finished” and “is good” are two very different things. Any writer will tell you: getting to 80% is the easy part. The last 20% takes most of the time, and for creative work, you never fully get there. You just have to push yourself to ship it anyway. 80% is where the real work begins. And 80% is exactly where the model drops you off.

That last 20% is usually where the actual value was supposed to come from: what you noticed, what you learned from doing the work, what you disagree with, what you think is worth leaving out, why this example over the other one.

And you can’t get that back by spending more tokens on the task.

AI engineers may be particularly vulnerable to this because we are getting so good at automating the first 80%. The better the model gets at giving us something that feels complete, the easier it becomes to forget that completing the output is never the same as completing the work.

That last 20% is what readers pay for, with their time and their attention. Attention is, after all, all you need. The catch: it takes both the LLM’s attention and yours to make something worth anyone else’s.

So keep the 20% for yourself. The part where you sweat a little. Where you consciously bring something new into the world. I think this will remain true even with Fable 8, GPT-9, or whatever comes next. If you bring no input and no personality to a piece or a product, why would anyone read it or use it? They can generate the exact same thing themselves.

And, to be clear, I do not believe we are doomed. There is hope. Calculators didn’t make us dumber. Computers either (debatable, I know). We just have to keep putting in the effort to think. That part cannot be outsourced to models or bought with more output tokens, especially the part that comes from our own voice and experiences.

So no, Fable is not making our work worse. We are, every time we ship the 80% and call it done.

I’ll leave you with a very appropriate quote from Jean Baudrillard:

“We live in a world where there is more and more information, and less and less meaning.”

Please, keep the meaning in what you produce and share.

More Tokens Won’t Replace Your Point of View was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Writing the code is rarely the hardest part of AI engineering. The hard part is knowing whether you are solving the right problem.

A chatbot rarely stops to say, “I do not know enough about your system to answer that.” It may confidently recommend a new framework, a different model, fine-tuning, a team of agents, or all of them at once. When you are the only AI engineer on your team, that confidence can sound a lot like expertise.

That is why I am genuinely excited to make this announcement today: we are launching the Towards AI Mentorship for AI engineers.

It is the support system I wish more engineers had while they were learning, changing careers, or trying to ship a serious AI product on a deadline. Instead of making every important decision alone, you get a senior AI engineering team behind your project and your career.

Watch the full announcement here:

Why we built the Towards AI Mentorship

Companies do not hire our team because their developers cannot code. They bring us in because someone needs to challenge the architecture, find the real bottleneck, and tell them when the confident answer is solving the wrong problem.

That second opinion matters. Should the product use retrieval, fine-tuning, a workflow, or an agent? Is the evaluation measuring something users actually care about? Is a framework helping, or is it hiding the failure? Could a simpler system perform better with less cost and latency?

Inside a funded company, those questions can involve several engineers, managers, and a consulting budget. A solo engineer often has a deadline, a chatbot that agrees with almost everything, and the hope that a decision will hold up in production.

We wanted to make the kind of guidance companies normally hire us for available to individual engineers.

One mentorship, two things you are building

You are building two things at once:

1. The AI project you are building.
2. The career you are building it for.

You need both. A strong project without a clear explanation can disappear in a crowded portfolio. A polished resume cannot compensate for shallow technical decisions. We help you build better systems and make the judgment behind them visible.

The project side: senior AI engineers on call

Members receive two live sessions every week for architecture reviews, implementation questions, project feedback, and technical problem solving. The sessions rotate across time zones and are recorded.

You also get direct asynchronous access to our AI engineering team. You can bring the problem that is blocking you now: a retrieval pipeline that keeps missing the right evidence, an agent that will not stop looping, an evaluation that rewards polished nonsense, a deployment tradeoff, or a framework decision you no longer trust.

We help you identify the actual problem, compare the tradeoffs, and understand the decision well enough to own it afterward. A tool recommendation without that judgment would leave you stuck again at the next fork.

Members also receive production resources built from our work. The first production blueprint walks through the agent setup and practices our team uses, including the judgment calls and wrong turns that do not fit into a clean demo.

The program also includes monthly live events with founders, hiring leaders, senior engineers, and guests from the field. These sessions are meant to expose members to how experienced builders make decisions, not just show another finished result.

The career side: feedback from people who hire

The second half of the mentorship focuses on the career behind the project.

We review resumes, LinkedIn profiles, repositories, project descriptions, and portfolios. The feedback comes from senior AI engineers and managers who know what hiring teams notice, what they discard, and what evidence makes a candidate easier to trust.

That support also includes a members-only community, a weekly curated AI job digest, and opportunities for standout members to work alongside our production team through internships. The goal is to help you present stronger evidence, get closer to real work, and stop guessing what your application is missing. The program does not promise employment.

Who this is for

We built the mentorship for people who are capable of building, but do not have enough experienced AI engineering support around them:

• The only AI person at a company.
• The freelancer whose client assumes a whole team is behind the work.
• The software developer moving into AI engineering.
• The junior AI engineer making production decisions for the first time.
• The graduate student with courses completed, projects started, and no clear bridge into the industry.

You do not need a perfect question every week. The core still arrives during a quiet month, and you can lean in harder when a launch or career move makes the questions urgent.

If you are starting from zero and cannot yet write Python, begin with the foundations first. The mentorship becomes much more useful when you can already build enough to encounter real decisions and bring them to the team.

What is included

The current mentorship includes:

• Two live sessions every week for architecture, projects, resumes, and career questions.
• Direct asynchronous access to the AI engineering team.
• A members-only community for discussion, networking, and peer support.
• Production resources and blueprints based on real engineering work.
• Monthly live events with industry leaders.
• A weekly curated AI job digest.
• Internship opportunities for standout members.
• The LLM Fundamentals and Beginner Python courses from day one, plus discounts on larger and upcoming courses.

The price is $99 per month or $899 per year. The monthly plan can be cancelled at any time, and the yearly plan includes a 30-day money-back guarantee. The official page remains the source of truth if the offer changes.

Your AI career does not have to be a solo project

I have spent the past six and a half years building AI systems, teaching engineers, and seeing the same pattern repeat: smart people lose weeks because they do not have someone experienced enough to challenge the first plausible answer.

This launch matters to me because it lets our 15+ engineers and mentors offer that second opinion to the person who would otherwise have to choose and hope.

If that person is you, join the Towards AI Mentorship. Bring the project on your desk, the role you want next, and the decisions you do not want to make alone.

The Towards AI Mentorship for AI Engineers was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.