DEV Community: Ilya Nixan

We Replaced Headless LibreOffice with a Single Rust Binary for DOCX PDF

Ilya Nixan — Tue, 11 Aug 2026 14:14:56 +0000

We had a document pipeline in production that turned DOCX templates into PDFs. It ran on headless LibreOffice. It worked, most of the time, and every time it didn't, it failed in a way that was somebody's whole afternoon.

So we wrote our own: dxpdf, a single Rust binary that parses OOXML directly and renders with Skia. No Microsoft Office. No LibreOffice. No cloud API. This is the story of why we did that, what the architecture looks like, and the benchmark result that surprised us.

It's open source. Repo.

TL;DR

Headless LibreOffice is a great renderer and a miserable production dependency: it serializes conversions per profile, spawns processes that hang, needs per-worker profile directories, and quietly changes its output between versions.
We replaced it with a Rust binary that parses OOXML → lays it out in a unit-typed engine → rasterizes/draws with Skia → writes PDF.
On an M3 Max it converts a 3-page doc in 170 ms and a 171-page doc in 420 ms — and the counter-intuitive part is that font resolution, not document size, dominates the cost.
It's not a full LibreOffice replacement: 74 OOXML features are fully implemented, 11 partial, 12 not yet supported. We'll list the gaps.

What headless LibreOffice actually costs you

First, credit where it's due: LibreOffice's format coverage is enormous. It has absorbed decades of edge cases from real-world .doc/.docx/.odt files, and for a one-off "convert this file" it's genuinely hard to beat. If you run it interactively, none of the below applies.

Running it headless, in production, under load is a different animal:

It serializes. A soffice instance is effectively single-conversion-at-a-time. To get concurrency you run N instances, and now you're a process supervisor.
Per-instance profile directories. Each instance wants its own -env:UserInstallation profile dir. Share one and you get lock contention and corrupted profiles; don't share and you're managing a pool of temp dirs and cleaning them up when workers die mid-conversion.
It hangs. A malformed input, a missing font, a particular embedded object — and the process sits there forever instead of erroring. You end up wrapping every call in a timeout-and-kill, then reaping zombie soffice children.
Output drift. The same input produces a slightly different PDF across LibreOffice versions — reflowed lines, shifted tables, changed font substitution. If your output is contractual or diffed, "upgrade the base image" becomes a visual-regression event.
It's heavy. Dragging a full office suite into a container image for one job is hundreds of megabytes and a slow cold start.

None of these are bugs, exactly. They're what it means to run an interactive desktop application as a stateless service.

What we actually needed

Written as requirements, not complaints:

Deterministic output — same bytes in, same bytes out, forever.
Real concurrency — no profile-dir dance, no per-conversion process to babysit.
Predictable latency — a tail we can reason about.
A small artifact — one binary in a scratch-ish container.
Data stays on the box — no cloud conversion API.

We looked at the alternatives before writing code, because writing a document renderer is not a decision you make lightly. Other soffice wrappers inherit all of the above. Cloud APIs mean the document leaves your infrastructure and you pay per page. The Chromium/HTML route (render DOCX → HTML → print-to-PDF) loses fidelity on exactly the DOCX features that matter — pagination, headers/footers, section breaks. If our documents were simple enough for the HTML route, we'd have taken it. They weren't.

The architecture

dxpdf is a pipeline:

DOCX (OOXML) ──▶ parser ──▶ unit-typed layout engine ──▶ Skia ──▶ PDF
                                     │
                        HarfBuzz (shaping) · ICU4X (i18n)

A few decisions worth calling out:

We parse OOXML directly. A .docx is a zip of XML (WordprocessingML). We read it and build our own document model rather than driving an office app to do it. That's the whole reason the output is deterministic — there's no interactive application state in the loop.

The layout engine is unit-typed. OOXML mixes units freely: twips (1/1440 inch) for most measurements, EMUs (1/914400 inch) for DrawingML, half-points for font sizes, plus the pixels and points you eventually render into. The single most common way a document renderer goes wrong is a silent unit mismatch — a value in twips added to a value in points, and nobody notices until a margin is off by a factor of 20. So units are types. You cannot add a Twip to a Point; the compiler stops you. This one constraint has caught more layout bugs at compile time than any test suite could.

Skia does the drawing. The same rendering engine behind Chrome and Flutter. We get battle-tested text and vector rasterization instead of reimplementing it.

HarfBuzz shapes, ICU4X internationalizes. Text shaping (turning a string + font into positioned glyphs) is HarfBuzz. Line breaking, bidi, and locale data are ICU4X, with the locale data shipped as a single trimmed blob via icu_provider_blob so there's no external ICU dependency to install.

The honest coverage gate

dxpdf is not LibreOffice. As of 0.5.0: 74 OOXML features fully implemented, 11 partial, 12 not yet supported.

The fully-supported set covers what most template-to-PDF pipelines actually use: paragraphs and runs, styles, tables, headers/footers, sections and page setup, lists and numbering, images, fields (dates, page numbers), fonts with bold/italic synthesis. The partial and unsupported set is where you should check your own documents before adopting — some advanced DrawingML, certain field types, and a handful of legacy constructs aren't there yet.

We'd rather you hit "unsupported feature: X" with a clear error than get a subtly wrong PDF. If your documents live entirely in the supported set, dxpdf is a drop-in. If they don't, the gap list tells you exactly what to test.

Two things dxpdf does that headless LibreOffice doesn't

Coverage isn't a one-way street. There are places we deliberately went past what a headless LibreOffice export gives you:

Colour emoji in a headless Linux container. Export a document with 🎉 or 🚀 through headless LibreOffice on a typical Linux server and you usually get monochrome outlines — or missing glyphs — because colour-emoji font formats (COLR/CPAL, CBDT/CBLC) aren't reliably handled without a desktop's font stack. dxpdf renders full-colour emoji through Skia + HarfBuzz whether or not there's a display, so the same document looks identical on your laptop and on a headless build agent.
Mixed page formats in a single document. OOXML lets every section carry its own w:pgSz — so one DOCX can be portrait A4 for the body and a landscape A3 for a single wide table. Headless LibreOffice tends to flatten that to one page size and orientation for the whole export. dxpdf honours per-section page setup, so a mixed-format DOCX comes out as a PDF with genuinely different page sizes and orientations, page by page.

Performance — and the surprise

Benchmarked on an Apple M3 Max, 30 runs, 5 warmup runs discarded:

Document	Size	Time
3 pages	34 KB	170 ms
9 pages	1.3 MB	55 ms
171 pages	14 MB	420 ms

Look at the first two rows. The 9-page, 1.3 MB document converts in 55 ms, but the 3-page, 34 KB one takes 170 ms — three times longer for a document a fraction of the size. That's not a typo, and it points at the real cost model.

Font resolution, not document size, decides what a conversion costs. Resolving a font the OS has to find and load runs 120–185 ms; a font that's embedded in the document or already cached is about 4 ms. The 3-page document referenced fonts we had to go find on the system; the 9-page one used embedded/cached fonts, so it skipped the expensive part almost entirely. The 171-page document is dominated by actual layout work, which is why it scales with content the way you'd expect.

The practical takeaway if you run this at scale: embed your fonts, or warm a font cache. Do that and small-document latency collapses from ~170 ms to tens of milliseconds. It's the highest-leverage knob, and it's invisible until you measure per-stage instead of per-document.

Operating it

The contrast with the old pipeline is the point:

One binary. Ships as a CLI, a Python package on PyPI, and a Debian .deb. The container is a binary, not an office suite.
Concurrency is just processes/threads. No profile directories, no pool, no lock file.
Determinism. Same input → same output bytes, across runs and across machines. Diffing generated PDFs in CI actually works.
Failure is an error, not a hang. Unsupported input returns a clear error instead of a wedged process you have to time out and kill.

What's new in 0.5.0

0.5.0 was our internationalization release, and it's a good illustration of the "we control the whole stack" upside:

UAX #14 line breaking for space-less scripts — Thai, Lao, Khmer, Burmese — where you can't just break on spaces.
UAX #9 bidirectional text with rule L4 mirroring for Arabic and Hebrew.
HarfBuzz shaping for cursive-joining scripts (Arabic, Syriac, N'Ko, Mongolian, Adlam).
CLDR-driven localization: region-aware decimal separators, localized DATE/TIME fields, spelled-out numbers in English, German, French, and Spanish.
Font synthesis for bold/oblique, pagination fixes, Windows CI, Debian packaging.
And our first external contribution — Russian numbering formats and list-label fixes. That one made our week.

Full notes: dxpdf 0.5.0.

FAQ

How do I convert DOCX to PDF without LibreOffice?
Use a library or binary that parses OOXML and renders directly. dxpdf is one: a standalone Rust binary (also a Python package and .deb) that turns DOCX into PDF with no Office or LibreOffice dependency.

Why is headless LibreOffice unreliable at scale?
It's an interactive desktop app running as a service. It serializes conversions per profile, needs managed profile directories, can hang on bad input, and changes its output between versions — all manageable, none free.

Is dxpdf production-ready?
For documents inside its supported feature set, yes — it's what we run. Check the coverage gate (74 full / 11 partial / 12 unsupported OOXML features) against your own templates first.

Does dxpdf need Microsoft Office installed?
No. It parses the OOXML directly. No Office, no LibreOffice, no cloud service.

How fast is it?
On an M3 Max, 170 ms for a 3-page doc and 420 ms for 171 pages. Small-document time is dominated by font resolution — embed fonts or warm a cache and it drops to tens of ms.

Can I use it from Python?
Yes, it's published on PyPI in addition to the CLI and Debian package.

dxpdf is open source — if you've ever fought a soffice pipeline at 3am, we'd love for you to try it, star it, or file the one DOCX feature you need next. And if you build systems like this — Rust, rendering, or Flutter — that's what we do at nerdy.pro.

How to Review AI-Generated Flutter Code (Before It Breaks Production)

Ilya Nixan — Tue, 28 Jul 2026 06:30:00 +0000

Every unsupervised AI agent we've reviewed that wrote Flutter code made the same seven mistakes.

These aren't typos or stylistic differences. They're structural failures that compound—bad state management plus missing tests plus hardcoded colors means the codebase becomes expensive to theme, hard to test, and impossible to maintain at scale.

Here's a small one to set the tone: a developer asked an agent to implement a GET request to an external service in a Dart project. The agent's solution was to shell out to curl via Process.run and parse the stdout.

Not package:http. Not dio. Not even dart:io's own HttpClient. A subprocess call to a CLI tool, inside a language that's had first-class HTTP clients since Dart 1.0.

That one is worth sitting with, because it's not really a Flutter problem — it's the whole pattern in miniature. The agent wasn't "wrong" that curl can make a GET request. It optimized for "this pattern appears constantly in training data" over "this is the idiomatic way to do it in the language I'm currently writing." Bash and curl show up in approximately every tutorial, README, and Stack Overflow answer ever written. package:http shows up in Dart-specific docs. Given no other constraint, the agent reached for the statistically dominant pattern, not the contextually correct one.

The seven gaps below are the same failure mode, just less obvious than "shells out to curl." Here's what we found, with real code examples and the fixes that work.

1. Recomputing Derived State

The Problem: Agents recalculate the same values across multiple locations instead of maintaining one source of truth.

Imagine a checkout flow where the cart total is computed three separate ways:

In the checkout page: (items.sum + tax) - discount
In the footer: items.sum - discount + tax
In the order summary: (items.sum - discount) * (1 + taxRate)

Different calculations. Same semantic meaning. One will break first.

The Fix: Derive values once in the state layer using streams. Let all widgets read from that single source:

// Instead of computing at call sites:
final total = items.fold(0, (sum, item) => sum + item.price);

// Compute once, derive everywhere:
final totalStream = itemsStream.map((items) {
  final subtotal = items.fold(0, (sum, item) => sum + item.price);
  final tax = subtotal * taxRate;
  final withDiscount = subtotal - appliedDiscount;
  return withDiscount + tax;
});

The principle: if it can be computed from state, it is not state.

Every recomputation is a sync bug waiting to happen.

2. Missing Tests and Benchmarks

The Problem: "It ships the feature and stops. No widget tests, no goldens, no benchmark."

Agents don't write tests because they can't run them in isolation. They generate code, you integrate it, and only then do you see:

Buttons don't disable while submitting (no state test)
Error messages don't clear when the user retypes (no widget test)
Layout overflows at 320pt wide (no golden test)
Frame rate drops from 60fps to 12fps on a real device (no benchmark)

Tests become feedback loops the agent can iterate against. Golden files provide visual regression detection—catching overflow, dark-mode contrast failures, and text truncation at 200% scale automatically.

The Fix: Write tests first, then tests become the specification:

group('SearchPage', () {
  testWidgets('shows spinner while loading', (tester) async {
    await tester.pumpWidget(SearchPage(state: const SearchState.loading()));
    expect(find.byType(CircularProgressIndicator), findsOneWidget);
  });

  testWidgets('shows error and allows retry', (tester) async {
    final state = SearchState.failed(error: AppError.network);
    await tester.pumpWidget(SearchPage(state: state));
    expect(find.text('Network error'), findsOneWidget);
    await tester.tap(find.byIcon(Icons.refresh));
    expect(find.byType(CircularProgressIndicator), findsOneWidget);
  });

  testWidgets('respects 200% text scale', (tester) async {
    tester.binding.window.textScaleFactorTestValue = 2.0;
    addTearDown(tester.binding.window.clearTextScaleFactorTestValue);
    await tester.pumpWidget(SearchPage(state: const SearchState.idle()));
    // No overflows
    expect(find.byType(OverflowBox), findsNothing);
  });
});

3. Flag Pyramids Instead of State Machines

The Problem: Agents use loose parallel boolean fields and branch over them, creating unmaintainable conditionals.

bool _isLoading = false;
String? _error;
List<Hit> _items = [];

// This represents 8 possible combinations, 4 of which are invalid
if (_isLoading) return CircularProgressIndicator();
if (_error != null) return Text(_error!);
if (_items.isEmpty) return Text('No results');
return ListView(children: _items.map(...).toList());

The UI code doesn't express the actual state machine. It's guessing based on flag combinations. And if loading completes before you clear the error, the UI gets confused.

The Fix: Use sealed state hierarchies. Express all valid states explicitly:

sealed class SearchState {}
final class Idle extends SearchState {}
final class Loading extends SearchState {}
final class Success extends SearchState { final List<Hit> items; }
final class Failed extends SearchState { final AppError error; }
final class Empty extends SearchState {}

// The UI is now explicit:
return switch (state) {
  Idle() => SearchHint(),
  Loading() => AppSpinner(),
  Failed(:final error) => AppErrorView(error),
  Empty() => EmptyResultsPlaceholder(),
  Success(:final items) => SearchResultsList(items),
};

No invalid combinations. No pyramids of if-statements. The compiler enforces exhaustiveness.

Quick question: have you caught the flag-pyramid anti-pattern in a PR before? That's usually the first place AI-generated Flutter code goes wrong — four more gaps below.

4. Design Tokens in constants.dart

The Problem: Agents create constant files and hardcode values at every call site instead of using ThemeData.

// constants.dart
const primaryColor = Color(0xFF1F77D2);
const lightGrey = Color(0xFFF5F5F5);
const baseTextSize = 16.0;

// Usage everywhere:
Text('Hello', style: TextStyle(color: Color(0xFF1F77D2), fontSize: 16))
Container(color: Color(0xFFF5F5F5))

This cascades into four problems:

Dark mode requires 200+ ternaries: color: isDark ? darkGrey : lightGrey at every call site
Design rebrands are massive diffs: Change primary color → change 300 files
Accessibility breaks: Hardcoded 16pt breaks at 200% text scale
Theme overrides stop working: Nothing asks Theme.of(context)

The Fix: Express the design system once in ThemeData, TextTheme, and component themes:

MaterialApp(
  theme: ThemeData(
    colorScheme: ColorScheme.fromSeed(seedColor: Color(0xFF1F77D2)),
    textTheme: TextTheme(
      bodyMedium: TextStyle(fontSize: 16),
      titleLarge: TextStyle(fontSize: 28, fontWeight: FontWeight.bold),
    ),
  ),
  darkTheme: ThemeData(
    colorScheme: ColorScheme.fromSeed(
      seedColor: Color(0xFF1F77D2),
      brightness: Brightness.dark,
    ),
  ),
);

// Usage: widgets ask the theme
Text('Hello', style: Theme.of(context).textTheme.bodyMedium)
Container(color: Theme.of(context).colorScheme.surface)

Rebrand once. Every widget updates automatically.

5. Each Screen Has Its Own UX Vocabulary

The Problem: 40 defensible screens that collectively feel like "40 tutorials stitched together."

A user loads the home screen and sees CircularProgressIndicator. They navigate to the feed and see a custom shimmer skeleton. They check their profile and see a branded loading animation.

Each is correct. Together, they're incoherent.

Same pattern with errors:

Home: SnackBar
Feed: inline error text
Profile: AlertDialog
Settings: modal bottom sheet

And destructive actions:

Delete account → AlertDialog
Remove item → bottom sheet confirmation
Leave group → inline text with undo button

The Invisible Failures:
The agent can't see these because it doesn't render frames:

Overflow at 320pt (narrow phone in landscape)
Tap targets under 44/48dp (fails accessibility)
Keyboard covering input fields (no onscreen detection)
Text truncation at 200% scale (readability)
Content under notches or behind home indicators (safe area)
Contrast failures in dark mode (WCAG A/AA)

The Fix: Decide your interaction vocabulary once. How do loading / errors / confirmations / validation feedback / empty states work? Implement that pattern everywhere. Test on real devices:

// Define once:
class AppLoadingOverlay extends StatelessWidget {
  const AppLoadingOverlay({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) => Center(
    child: CircularProgressIndicator(
      valueColor: AlwaysStoppedAnimation(
        Theme.of(context).colorScheme.primary,
      ),
    ),
  );
}

class AppErrorView extends StatelessWidget {
  final AppError error;
  final VoidCallback? onRetry;

  const AppErrorView({required this.error, this.onRetry, Key? key})
    : super(key: key);

  @override
  Widget build(BuildContext context) => Center(
    child: Column(
      mainAxisAlignment: MainAxisAlignment.center,
      children: [
        Icon(Icons.error_outline, size: 56, color: Colors.red),
        SizedBox(height: 16),
        Text(error.displayMessage, textAlign: TextAlign.center),
        if (onRetry != null) ...[
          SizedBox(height: 24),
          ElevatedButton(onPressed: onRetry, child: Text('Retry')),
        ]
      ],
    ),
  );
}

// Use everywhere: home, feed, profile
return switch (state) {
  Loading() => AppLoadingOverlay(),
  Failed(:final error) => AppErrorView(error: error, onRetry: onRetry),
  // ...
};

6. String Concatenation Instead of Localization

The Problem: Agents bake English assumptions into the code.

Text('$count items');  // Output: "1 items" (grammatically wrong)

Text('$count ${count == 1 ? "item" : "items"}');
// Wrong for Russian (4 plural forms), Arabic (6 forms), Polish (3 forms)

Text('Hello, ' + name + '!');  // English word order locked in

Text('${d.day}.${d.month}.${d.year}');  // US date format; wrong for most of world

Text('\$${amount.toStringAsFixed(2)}');
// $ before number (US), but euros go after: "10 €", Arabic: "﷼ ١٠"

None of these are internationalization—they're English with variables.

The Fix: Use ARB files with gen_l10n and intl package:

# l10n.yaml
arb-dir: lib/l10n
template-arb-file: app_en.arb
output-localization-file: app_localizations.dart

// lib/l10n/app_en.arb
{
  "unreadMessages": "{count, plural, =0{No new messages} one{{count} message} other{{count} messages}}"
}

// lib/l10n/app_ru.arb
{
  "unreadMessages": "{count, plural, =0{Нет новых сообщений} =1{{count} сообщение} few{{count} сообщения} other{{count} сообщений}}"
}

Text(l10n.unreadMessages(count))

// Use NumberFormat for currency
Text(NumberFormat.currency(locale: 'en_US').format(amount))

// Use DateFormat for dates
Text(DateFormat.yMd(l10n.localeName).format(date))

// Use EdgeInsetsDirectional for RTL
Padding(
  padding: EdgeInsetsDirectional.only(start: 16),
  child: Text('Hello'),
)

One source of truth for each language. Plurals, gender, word order—all handled by ICU.

7. Uniform Simplification (in the Wrong Places)

The Problem: Agents flatten complexity uniformly—collapsing load-bearing logic while over-abstracting trivial code.

Over-simplified (dangerous):

try {
  await api.charge(order);
} catch (_) {
  setState(() => error = 'Payment failed');
}

This swallows three completely different failures:

Network timeout (retry is safe)
Declined card (user's problem, don't retry)
Idempotency conflict (retry will double-charge)

All three are now identical. Retry logic is broken.

Over-abstracted (waste):

// 14-parameter widget for 5 button styles
class AppButton extends StatelessWidget {
  final String label;
  final VoidCallback onPressed;
  final Color? backgroundColor;
  final Color? foregroundColor;
  final EdgeInsets? padding;
  final double? borderRadius;
  final double? elevation;
  final bool isLoading;
  final bool isEnabled;
  // ... 5 more parameters

  const AppButton({
    required this.label,
    required this.onPressed,
    this.backgroundColor,
    // ...
  });
}

// vs. five concrete widgets
class PrimaryButton extends StatelessWidget { ... }
class SecondaryButton extends StatelessWidget { ... }
class TertiaryButton extends StatelessWidget { ... }

The generic version is harder to use and reason about.

The Fix: Complexity is a budget. Spend it on genuinely hard domains:

Load-bearing (explicit, verbose):

Payments and financial transactions
Offline sync and conflict resolution
Authentication and token refresh
Idempotency and deduplication
Error handling with recovery strategies

Trivial (collapse aggressively):

Five similar list tiles → one widget
Settings screen with 10 toggles → no abstraction
Button variants → concrete subclasses, not parameters
Utility functions → don't create BaseRepository

// Explicit payment error handling
sealed class PaymentError {}
final class NetworkTimeout extends PaymentError {}
final class CardDeclined extends PaymentError { final String reason; }
final class IdempotencyConflict extends PaymentError {}

try {
  await api.charge(order, idempotencyKey: uuid);
} on PaymentError catch (e) {
  switch (e) {
    case NetworkTimeout() => _retryPayment();
    case CardDeclined(:final reason) => _showCardError(reason);
    case IdempotencyConflict() => _confirmChargeAlready();
  }
}

// Trivial UI: no abstraction needed
ListView(
  children: [
    SettingsTile('Notifications', isEnabled: notificationsOn, onChange: ...),
    SettingsTile('Dark Mode', isEnabled: darkModeOn, onChange: ...),
    SettingsTile('Analytics', isEnabled: analyticsOn, onChange: ...),
  ],
)

💡 The core principle: Complexity is a budget. Spend it on genuinely hard domains — payments, offline sync, auth, idempotency. Collapse aggressively everywhere else.

Why Flutter Amplifies These Issues

Four reasons why Flutter makes these problems louder than in other frameworks:

UI is code: No stylesheet layer to enforce consistency. No centralized theme your linter can verify.
Everything compiles: No compiler error for "you should use Theme.of(context) here." Hardcoded colors feel fine until day 50.
Agent cannot see frames: No visibility into whether the layout actually renders at 320pt, whether text is readable at 200% scale, or whether the keyboard covers the input.
Outdated training data: Models confidently generate deprecated APIs (RaisedButton, WillPopScope, MaterialStateProperty).

The Core Insight: Orchestration vs. Unsupervised Agents

Every one of these failures shows up in every language.

Flutter just makes them louder.

The difference is orchestration:

Set invariants first: Theme, state model, localization, folder structure, error taxonomy—decide before anyone (human or agent) writes code.
Build feedback loops: Strict linting (no hardcoded colors), test coverage enforcement, frame-time budgets, CI checks.
Review decisions, not lines: Verify state consistency, theme usage, derivation sources, localization—not individual diffs.
Open the app: Test on real devices at 200% text scale, dark mode, throttled network, both languages.

When AI agents operate inside a codebase with strong invariants and feedback loops, they move fast. When they create codebases from scratch without those constraints, they move fast in the wrong direction.

Familiar beats clever essentially always. And the only way that agent speed becomes an asset instead of a liability is through structural constraints decided before coding begins.

Key Takeaways

Derive once, read everywhere — if it can be computed from state, it isn't state.
Tests are the spec — write them first so they become a feedback loop, not an afterthought.
Model states explicitly — sealed classes over boolean flags; let the compiler catch invalid combinations.
Centralize the design system — ThemeData once, not hardcoded values at 200 call sites.
Pick one interaction vocabulary — loading, errors, confirmations should feel identical across every screen.
Localize from day one — ARB files and ICU plurals, not string concatenation.
Treat complexity as a budget — spend it on payments/auth/sync, collapse everything trivial.

Discussion: What's the #1 AI-generated code smell you've caught in review? Drop it in the comments — collecting the worst offenders for a follow-up post.

Want the full deep-dive with more examples? Read the complete article on nerdy.pro.