Commercial content creation and production have been subsumed by the tsunami that is generative AI. For writers and editors in this space, it hasn’t really been a case of “If you don’t use AI you’ll get left behind,” but rather, “You’re coming with us whether you like it or not.” (Thanks, big tech.)
Obviously, writing and editing processes have changed accordingly, with companies now expecting writers and editors to use AI as part of their workflows. This also means that expectations of delivery timeframes have changed: writers are expected to churn out far more work in far less time, at the same high standards as before.
For a technical writing company, this raises an obvious question: If we needed to produce more content more rapidly, how effectively can (and should) we use agentic AI to edit technical articles?
A few caveats upfront:
I’m not a fan of using AI. Quite the opposite. And yet, I find myself bumping up against it no matter which way I turn to get away from it in this fast-paced digital world. “No ethical existence under capitalism,” I mutter sadly to myself as I plug prompts into Claude.
I believe there is still room for ethical creation under capitalism. For this reason, (and this may sound ironic and/or hypocritical, given the subject matter here), I don’t use AI to write my articles. I’ve done my best to be as objective as I can about the end result of this task.
With that said, the point of this article was to determine to what extent the most advanced Anthropic model could function as an agentic editor on a technical, code-heavy piece of long-form writing.
The initial idea was to perform this task with Fable; I didn’t get very far with that, however, before the US government unceremoniously restricted foreign access to the model one day after release. After that, it made sense to move one rung down to the next model available on Claude Code: Opus 4.8.
Pre-conceived notions #
My opinion based on previous experience is that AI-generated writing is bland and devoid of personality, capable of saying a lot of nothing very confidently. (Like a politician, really.) If you ask it to take on a certain tone or capture a specific character’s voice, it will quickly run out of unique ways to construct sentences.
A quick demo on that point: I asked Sonnet 4.6 to write me a manifesto on why food is more important than anything else, in the voice of Son Goku. But even when taking on the distinctive verbal mannerisms of a character whose entire dialogue Claude has access to, the “AI-isms” cannot help but creep in. (That’s not a coincidence. That’s just predictable.)
And it doesn’t matter how comprehensive or precise your prompt is: eventually, the output will default back to that now-familiar clipped rhythm and self-aggrandising tone that makes you want to pull your eyeballs out and toss them at the screen.
This was definitely the case with models prior to Fable. I’d argue that, to an extent, it’s still the case with writing generated by Fable. Although it doesn’t contain the same language patterns symptomatic of writing generated by less advanced models, there are still certain beats that, over time, would likely start being flagged as new “AI tells”. One sample isn’t enough for me to tell, but where Opus and prior had “It’s not X, it’s Y” and a mic-drop cadence, Fable might end up being identifiable by a very rigidly academic tone. Because ultimately, when it comes to writing, AI can only draw from a limited data set. Humans can generate thoughts beyond that ceiling; LLMs can only work under it.
Editing with Opus 4.8 #
I began with an article explaining how to use Better Auth with for Bryntum Gantt Charts. I started by asking Claude Code to flag structural flaws, grammatical flaws, and logical issues, as well as instructions that were unclear, inaccurate, or not contextualised for the reader.
I started with this request because these are the first issues we look for during a developmental edit. Does the piece make sense as a whole? Is there a clear introduction, middle, and conclusion? Is there consistent signposting for the reader? Are there points that are introduced but never concluded? Is there a steady flow of logic that runs through the text? By addressing these concerns, we can ensure that a piece of writing has both substance and sense.
The reason I asked Claude to identify issues and not make the corrections itself is simply that I didn’t trust it to make good choices. I also wanted to see if it would identify the issues I was looking for, whether it would flag any false negatives, or whether it would simply list a few surface-level features.
What Claude flagged
I will admit (begrudgingly) that Opus performed better than I’d wanted it to. It identified the following sets of issues:
1. Potential issues with the code
In this case, having Claude on hand would be useful for a technical editor who, for whatever reason, isn’t able to run the code themselves.
Verdict: These corrections can’t be taken as gospel truth (it’s Hallucination Hell in 2026, trust nothing and nobody), but they can be flagged for QA.
2. Structural issues
This was a solid list of flags, and it picked up most of the issues I myself had identified (inconsistent “demo” terminology) and some I hadn’t (.webm files). But the most important issue was the hefty integrations paragraph; it was the first thing that jumped out at me when I first read the piece.
The original looked like this:
Writer's Version
The Bryntum React Gantt is a performant and fully customizable JavaScript component for building project management apps. If you don't want the project data it displays to be public, you need authentication in front of it. For JavaScript apps, you can use Better Auth, a comprehensive, free, and open-source authentication framework for TypeScript.
In this guide, we'll show you some of Better Auth's authentication features by building three small apps that each protect a Bryntum React Gantt chart in a different way:
- An email and password login
- A signup restricted to one email domain, for internal company Gantt charts
- A private Gantt chart shared with an invite list of email addresses, where invitees sign in with a one-time code sent to their email (no password needed)
All three use the same stack: a React frontend built with Vite, an Express backend, and SQLite for storage. We chose this stack to keep it simple. Better Auth has integrations across the JavaScript ecosystem, including Next.js, Nuxt, SvelteKit, TanStack Start, Hono, Fastify, NestJS, and React Native. On the database side, it supports PostgreSQL, MySQL, MS SQL, and SQLite directly, plus adapters for Drizzle, Prisma, and MongoDB, and many community adapters. The same applies to authentication methods: the demos use email and password and email OTP, but Better Auth also supports social sign-in with Google, GitHub, Apple, and dozens of other providers, and has plugins for passkeys, magic links, two-factor authentication, phone number OTP, single sign-on (SSO), JWT, bearer tokens, and more. Because it runs inside your own app, user accounts and sessions live in your own database.
Note:Better Auth runs in a JavaScript or TypeScript backend. If your existing backend uses another language, you can run a small Node.js auth server between your frontend and backend that handles only authentication.
We needed to distil that list of features into something digestible for the reader. I asked Claude to fix the issue by breaking down the wall of text and shifting information to further down the article where possible, and then set about doing that myself.
Here are the two versions so you can compare:
Claude Edit
The Bryntum React Gantt is a fast, fully customizable JavaScript component for building project management apps. But a Gantt chart usually displays real project data — schedules, teams, deadlines — and that's rarely something you want public. To keep it private, you need authentication in front of it.
That's where Better Auth comes in: a comprehensive, free, and open-source authentication framework for TypeScript and JavaScript apps.
In this guide, we'll explore Better Auth's features by building three small apps, each protecting a Bryntum React Gantt chart in a different way:
Email and password login— the classic starting point** Domain-restricted signup**— only people with your company's email domain can register, ideal for internal Gantt charts** Invite-only access with one-time codes**— a private chart shared with a list of email addresses, where invitees sign in using a code sent to their inbox (no password required)
All three share the same stack, chosen to keep things simple: a React frontend built with Vite, an Express backend, and SQLite for storage.
None of those choices lock you in, though. Better Auth works across the JavaScript ecosystem — Next.js, Nuxt, SvelteKit, Hono, Fastify, NestJS, React Native, and more. It connects directly to PostgreSQL, MySQL, MS SQL, and SQLite, with adapters for Drizzle, Prisma, and MongoDB. And while our demos use email/password and email OTP, you can just as easily add social sign-in (Google, GitHub, Apple, and dozens more) or plugins for passkeys, magic links, two-factor auth, SSO, and JWT. Because it all runs inside your own app, your user accounts and sessions live in your own database.
Note:Better Auth needs a JavaScript or TypeScript backend. If yours uses another language, you can run a small Node.js auth server between your frontend and backend to handle authentication alone.
My Edit
Project management tools live and die by trust. When you build a Gantt chart to coordinate your team's work, you need to be sure that only the right people can access it, whether that's your entire company, a specific team, or a handful of external collaborators. Authentication is what makes that possible, but bolting it onto an existing app is rarely a straightforward task.
The Bryntum React Gantt is a performant and fully customizable JavaScript component that takes the hardest part of building a project management interface off your plate. Drag-and-drop task management, dependency tracking, critical path calculation, resource allocation, and Microsoft Project import/export – these are months of engineering work that Bryntum handles out of the box. But once you have a powerful project view up and running, protecting it with the right authentication strategy is the next critical step.
For JavaScript apps, we use Better Auth, a free and open-source TypeScript authentication framework that keeps user data in your own database rather than a third-party service. It integrates across the stack you're most likely already using: Frameworks: Next.js, Nuxt, SvelteKit, TanStack Start, Hono, Fastify, NestJS, React NativeDatabases: PostgreSQL, MySQL, MS SQL, and SQLite directly; Drizzle, Prisma, and MongoDB via adaptersAuth methods: Email/password, email OTP, social sign-in (Google, GitHub, Apple, and more), passkeys, magic links, two-factor authentication, SSO, and JWT
In this guide, we'll show you some of Better Auth's authentication features by building three small demo apps, each of which protects a Bryntum React Gantt chart in a different way:
| Demo app | Use case | Method |
|---|---|---|
| 1 | General user access | Email and password login |
| 2 | Internal company charts | Signup restricted to one email domain |
| 3 | External collaborators | Invite-only access via one-time email code |
All three apps use the same stack, which we kept simple: a React frontend built with Vite, an Express backend, and SQLite for storage.
By the end, you'll understand how to gate a Bryntum Gantt chart behind a session check, restrict signups by email domain, and implement a passwordless invite flow using one-time codes. Each demo builds on the last, so you can read straight through or jump to the app that fits your situation.
Verdict: Claude was helpful with flagging issues. Fixing the issues, not so much. It did a little bit of formatting, added some linking words, and generally lubricated an otherwise unyielding introduction. But it didn’t really succeed in giving the introduction a sense of relevance to the reader beyond just “Here’s an article and here’s what to expect in it.” And of course, the wall of integrations remained solidly intact; I had to unbrick it myself.
I mean, of course, you could then spend the next twenty minutes prompting and re-prompting to get it exactly right – but at that point, you really could just spend that energy writing it yourself.
3. Logical & contextual issues
Some of these weren’t concerns so much as matters of judgement (e.g. the “@gmail.com” example was the writer’s choice). Others, like #8–11, for instance, simply needed a line or two explaining to the reader why they would need to make certain choices.
Verdict: Once again, this is a good place to use Claude; it could identify points at which even a technical reader might get a little lost.
4. Clarity & unclear instructions
More useful issues identified here regarding what may stump a technical reader. That said…
The verdict: I feel that unclear or ambiguous phrasing is something that can and should be picked up during close reading. If you rely solely on an AI to pick up for you, you are very likely going to miss something (or several somethings).
5. Grammar & style
Grammar is the one place I’ve never trusted AI to perform well – it constantly messes up concord and subject agreement. It also plays fast and loose with punctuation and spelling rules. This is also a huge reason why I’ll never just unleash Claude Code on a piece of writing without me micromanaging the hell out of it.
With that said, this was a decent list, if an incomplete one. For instance, Claude didn’t bring up the repetition of an article (“a an”) during the first iteration, but it did flag the issue when I asked it to do a second pass.
Where Claude was properly useful to me
Here’s the thing, though: All that is just stuff that I can do myself. (And where I’m unfamiliar with the technicalities, I can ask the writer or a developer for context.)
The workflow aspect was really where Claude Code became useful to me, largely because I was working with github and markdown, as opposed to a rich-text word processor. Instead, having Visual Studio Code open allowed me to make direct edits to the markdown myself while instructing Claude Code to interact with the repo.
Far less painful a process than it would have been going back and forth between the terminal and a document.
The final verdict #
Claude Code was neither useless nor essential in the editing process.
Strengths: If you’re working on a repo, Claude Code significantly alleviates the pain of admin. It’s also good at picking out issues you need to fix and giving you ideas for how to go about doing it.
Weaknesses: Its edits are lacklustre and its writing is weak. If you want to take your articles from passable to powerful, you’ve got to do the work yourself.
When you’d need it: If you’re working in a dev environment, it’s nifty. If you’re a regular content writer, skip it.
Personally, I’d keep going without it. But if you’re a technical writing company that has to write and edit thousands of words' worth of articles at short notice, then you may want to consider integrating agentic AI into your workflow as an “issue-flagger”.
Keep the humans, though. You’ll need them more.