{/* banner prompt: Retro technical poster with a schematic diagram showing a UI prototype connecting to backend systems, featuring bold typography "FROM PROTOTYPE TO PRODUCT", using a limited-print palette of off-white, orange, and dark teal with halftone textures, 16:9. */}

In my [last post](/blog/2025/05/07-jumpstarting-my-project-ui-with-v0dev-from-cli-tool-to-web-app/), I talked about using v0.dev to jumpstart my trading calculator's UI. I went from a CLI tool to a sleek web interface in hours instead of weeks. Pretty cool, right?

But here's the thing—having a beautiful UI mockup isn't the same as having a working product.

After that initial excitement wore off, I stared at my shiny new frontend and realized I'd only solved about 20% of the problem. Sure, the buttons looked great. But they didn't do anything. The forms were gorgeous, but they couldn't process real trading data. The tables were perfectly styled, but they showed placeholder numbers instead of actual profit and loss calculations.

That's when the real work began. And surprisingly, that's where AI became even more valuable.

## What I Started With vs. What I Needed

Let me paint you a picture of where I was after that first v0.dev sprint:

**What I had:**
- A simple but decent React frontend with modern styling
- Some forms for CSV uploads
- Elegant tables ready to display trading data
- Clean navigation and responsive design
- Zero actual functionality

**What I needed:**
- The frontend to talk to my existing calculation engine
- CSV parsing for different broker formats
- Real data flowing through the UI
- Portfolio saving and loading
- Proper error handling
- A deployment that actually worked

The gap between these two states? That's where most projects die.

## AI as a Finisher, Not Just a Generator

Everyone talks about AI generating code from scratch. Screenshots to UI, prompts to prototypes, ideas to interfaces. That's impressive, but it's not all where AI shines brightest.

AI becomes truly powerful when it helps you finish things.

I used Claude (specifically the `/frontend-design` plugin) to redo the look and feel after the initial v0.dev generation. And I used Codex to write most of the code.

Here's what that looked like in practice.

## The Real Problems AI Helped Me Solve
### Connecting Frontend to Backend

The real breakthrough came when I needed to integrate my existing trading calculation engine. I had this solid [CLI library](https://github.com/e-tang/shares-profit-loss-tax) that could crunch numbers, but connecting it to the web frontend? That's where things got messy.

Codex helped me:
- Restructure the backend API to return frontend-friendly JSON
- Fix serialization issues between browser and server
- Handle CSV parsing for different broker formats (especially CommSec uploads)
- Debug date handling across timezone boundaries

This wasn't about generating new code. This was about making existing code work together.

### Making the UI Actually Useful

Using Claude's /frontend-design plugin, I iterated on the visual design while keeping the functional improvements:
- Improved color contrast for financial data
- Better button states and loading indicators
- Responsive layout adjustments
- Fixed footer and documentation pages

### Building Real Product Features

Then came the features that turn a demo into a tool people actually use:

**Portfolio workflows:** Users needed to save their trading data and come back to it later. AI helped me design the data models and implement the persistence layer.

**Append-trades functionality:** Traders get new CSV exports each financial year. They don't want to re-upload everything. Codex helped me build incremental import logic.

**Symbol-level reporting:** The original CLI tool had basic reporting, but the web version needed sortable tables, filtering, and drill-down views.

**Support infrastructure:** Contact forms, file uploads for bug reports, email integration. The boring stuff that makes a product feel professional.

## What Changed Between V1 and the Finished App

Let me show you the before and after:

**Initial AI-generated UI shell:**
- Static React components
- Hardcoded sample data
- No backend integration
- Beautiful but useless

**Finished working product ([Sprolo](https://sprolo.tyosis.com/)):**
- CSV import for multiple broker formats
- Real profit/loss calculations
- Portfolio saving and management
- Incremental trade imports
- Tax-year-aware reporting
- Symbol and trade-level analysis
- Support workflows with file attachments
- Production deployment on Google Cloud

Check out the [GitHub repo](https://github.com/tyolab/Sprolo) if you want to see the code evolution.

## The Support Infrastructure Nobody Talks About

One thing I underestimated: how much work goes into making a product feel professional. It's not just the core functionality.

Users need:
- Help documentation that actually helps
- A way to report bugs without emailing you personally  
- Privacy policies that don't sound like legal gibberish
- Contact forms that work reliably

Codex helped me build all of this. Not because it's technically challenging, but because it's time-consuming and easy to get wrong.

The support flow alone involved:
- Frontend forms with proper validation
- File upload handling for CSV samples
- Server-side email integration  
- Category-based routing (bug reports vs. feature requests)
- Response templates that don't sound like robots

## The Finished Product

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/05/ai-beyond-the-ui-from-v0-prototype-to-a-finished-product/2026-05-08-19-36-30.png)

It's live now at: [Sprolo](https://sprolo.tyosis.com/)

The first post was about starting fast with v0.dev. This follow-up is about finishing properly with AI as your debugging and integration partner. Both matter, but only one ships products that people find useful.

bb40551b41ffad86ea5cebbf900bddbac5dfa3187d081d6be45d3e42dff8f44e

Moving beyond UI generation: using AI to debug, integrate, and ship a real trading profit/loss calculator from prototype to production

How AI helped me turn an AI-generated frontend mockup into a fully functional trading calculator

AI Beyond the UI: From v0 Prototype to a Finished Product

{/* banner prompt: Of course! Based on the blog post's core theme of Docker resolving the chaotic and frustrating .NET build hangs on Linux, here are three creative and engaging prompts for a 16:9 banner image.

---

### Prompt Option 1 (The Sanctuary)

**Prompt:**
A digital art illustration in a cinematic, futuristic style. In the chaotic background, a storm of tangled red wires, glitching code snippets, and faint error messages like `GLIBC_2.38` swirls around a distressed Linux penguin (Tux). In the foreground, a glowing, translucent blue Docker container acts as a perfect shield. Inside the container, the .NET logo is pristine and a set of gears are turning smoothly, representing a successful build. The scene is illuminated by the calm, cool light from the Docker container, pushing back the chaotic red darkness. Aspect ratio 16:9.

**Why it works:** This prompt visually captures the central conflict: the "dependency hell" of Linux (chaos, errors, frustration) versus the clean, isolated, and reliable environment provided by Docker (the sanctuary).

---

### Prompt Option 2 (The Assembly Line)

**Prompt:**
A dynamic vector illustration showing a transformation from left to right. On the left, the .NET logo is stuck in a complex, rusty, and jammed machine made of mismatched parts, with a progress bar frozen at 99%. A frustrated Linux penguin is looking at it with a wrench. On the right, the iconic Docker whale is calmly overseeing a sleek, modern, and efficient assembly line made of Docker containers. This assembly line is smoothly processing the .NET logo, which emerges on the far right as a polished, glowing, and complete application icon. The entire image has a clean, tech-focused aesthetic. Aspect ratio 16:9.

**Why it works:** This prompt visualizes the blog post's narrative of a broken process being fixed. It directly contrasts the "build hang" (jammed machine) with the "reproducible build" (streamlined assembly line), highlighting Docker's role as a workflow optimizer.

---

### Prompt Option 3 (The Breakthrough)

**Prompt:**
Conceptual digital art with dramatic lighting. The .NET logo is depicted as being trapped and frozen inside a complex, dark labyrinth made of glitching, fragmented code representing the Linux environment. A powerful and luminous Docker whale is breaking through the walls of the labyrinth, shattering the digital "ice" and untangling the code with streams of clean, blue data. The breakthrough creates a wave of light that illuminates the path forward. The scene conveys a powerful sense of resolution and freedom from a persistent problem. Aspect ratio 16:9.

**Why it works:** This prompt is more metaphorical and heroic. It portrays the build hang as a formidable obstacle (a labyrinth) and Docker as the powerful solution that provides a "breakthrough," which directly reflects the feeling of solving a long-standing, frustrating technical issue. */}

Microsoft's transformation from a proprietary software giant to an open-source advocate has been remarkable. The release of .NET Core for Linux marked a pivotal moment in cross-platform development. However, despite this progress, developers working with .NET on Linux have encountered persistent challenges that can significantly impact productivity.

## The Promise and Reality of .NET on Linux

When Microsoft announced .NET Core's availability on Linux, it opened doors for developers who had been yearning to use their favorite .NET technologies outside the Windows ecosystem. The framework itself is remarkably solid – applications run smoothly, performance is excellent, and the development experience is largely seamless.

But there's a catch that many developers have discovered the hard way: the build process.

## The Persistent Build Hang Problem

The `dotnet build` command on Linux has a notorious reputation for hanging unexpectedly. This isn't a minor inconvenience – it's a productivity killer that affects development workflows across teams and projects.

### Characteristics of the Problem

The hanging behavior exhibits several frustrating patterns:

- **Unpredictable occurrence**: It works perfectly on one machine but fails consistently on another with seemingly identical configurations
- **Intermittent failures**: The build might succeed several times, then suddenly hang without any code changes
- **Repository dependency**: Sometimes checking out a fresh clone of the same repository resolves the issue temporarily
- **No clear error messages**: The process simply stops responding, providing no actionable feedback

### The Library Dependency Nightmare

The build process is only half the battle. A common scenario unfolds like this: you successfully build your .NET application on your development machine (e.g., running the latest Ubuntu), and everything looks great. You then deploy the compiled artifacts to a production server, which might be running an older but more stable distribution like Debian or CentOS.

When you try to run the application on the target machine, it crashes with errors like these:

```bash
Nov 12 10:47:53 workstation run.sh[290219]: ./[YOUR_APP]: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by ./[YOUR_APP])
Nov 12 10:47:53 workstation run.sh[290219]: ./[YOUR_APP]: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by ./[YOUR_APP])
```

These errors indicate version mismatches between the system's installed libraries and what the .NET runtime expects – a classic Linux dependency hell scenario.

## Why These Issues Persist

A simple Google search for "dotnet build linux hung" reveals the scope of this problem. Results span back at least four years, with countless developers reporting similar experiences across different Linux distributions, .NET versions, and hardware configurations.

The persistence of these issues a couple of underlying factors. The .NET build system performs numerous operations under the hood – package restoration, compilation, linking, and asset generation. Any step in this pipeline can encounter environment-specific issues that cause hanging. Also Linux systems handle process scheduling and resource allocation differently than Windows. The .NET build process might encounter unexpected contention or deadlock scenarios specific to Linux environments. The exact root cause remains elusive. Despite numerous bug reports and community discussions, a definitive, universal solution from the Microsoft .NET team has not materialized. The problem's intermittent and environment-specific nature makes it incredibly difficult to diagnose. Rather than getting stuck trying to solve a mystery that has stumped even the core development team, this guide focuses on a pragmatic and reliable workaround that bypasses the problem entirely.

## Docker as the Solution

While the root causes remain complex, Docker provides a practical workaround that many development teams have adopted successfully.

### Why Docker Works

Docker containers offer several advantages for .NET builds on Linux:

**Consistent Environment**: Every build runs in an identical, controlled environment regardless of the host system's configuration.

**Isolated Dependencies**: Container images include all necessary runtime dependencies at known versions, eliminating library mismatch issues.

**Reproducible Builds**: The same container image produces identical results across different machines and CI/CD environments.

### Setting Up Dockerized .NET Builds

Here's a practical implementation for containerizing your .NET builds:

#### Basic Dockerfile

```dockerfile
# Simple single-stage Dockerfile for building [YOUR_APP] on Ubuntu 22.04
FROM ubuntu:22.04

# Prevent interactive prompts
ENV DEBIAN_FRONTEND=noninteractive

# Install .NET SDK 8.0 for Ubuntu 22.04
RUN apt-get update && apt-get install -y wget ca-certificates \
    && wget https://packages.microsoft.com/config/ubuntu/22.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb \
    && dpkg -i packages-microsoft-prod.deb \
    && rm packages-microsoft-prod.deb \
    && apt-get update \
    && apt-get install -y dotnet-sdk-8.0 \
    && rm -rf /var/lib/apt/lists/*

# Set working directory
WORKDIR /app

# Configure environment
ENV DOTNET_CLI_TELEMETRY_OPTOUT=1 \
    DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1 \
    MSBUILDDISABLENODEREUSE=1

# Copy all project files
COPY . .

# Fix NuGet.Config
RUN printf '%s\n' \
    '<?xml version="1.0" encoding="utf-8"?>' \
    '<configuration>' \
    '  <packageSources>' \
    '    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />' \
    '  </packageSources>' \
    '</configuration>' > NuGet.Config

# Remove global.json to allow any .NET 8 SDK
RUN rm -f global.json

# Restore, build, and publish with runtime identifier
RUN echo "=== RESTORE (with RID) ===" \
    && dotnet restore [YOUR_APP].csproj -r linux-x64 2>&1 | tee restore.log \
    && echo "=== BUILD ===" \
    && dotnet build [YOUR_APP].csproj -c Release --no-restore -r linux-x64 2>&1 | tee build.log \
    && echo "=== PUBLISH ===" \
    && dotnet publish [YOUR_APP].csproj -c Release --no-restore --no-build \
       -o /app/publish \
       -r linux-x64 \
       --self-contained false \
       2>&1 | tee publish.log \
    && echo "=== BUILD COMPLETE ===" \
    && ls -lh /app/publish/

# Set entrypoint
WORKDIR /app/publish
CMD ["/bin/bash"]

```

Remember to replace [YOUR_APP] in the above Dockerfile to your actual project name.


#### Build Script

Create a shell script to streamline the Docker build process:

```bash
#!/bin/bash
#
# Simple Docker build script with better error handling
#

set -e

PROJECT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
cd "$PROJECT_DIR"

echo "=========================================="
echo "Building [YOUR_APP] in Docker "
echo "Target: Ubuntu 22.04"
echo "=========================================="
echo

# Configuration
IMAGE_NAME="[YOUR_APP]-docker"
CONTAINER_NAME="[YOUR_APP]-extract"
OUTPUT_DIR="./bin/Release/net8.0/publish"

# Clean up
echo "Cleaning up previous containers..."
docker rm -f "$CONTAINER_NAME" 2>/dev/null || true

# Build the Docker image
echo
echo "Building Docker image..."
if ! docker build -f Dockerfile -t "$IMAGE_NAME:latest" . 2>&1 | tee docker-build.log; then
    echo
    echo "=========================================="
    echo "BUILD FAILED!"
    echo "Check docker-build.log for details"
    echo "=========================================="
    exit 1
fi

echo
echo "Creating container to extract build..."
docker create --name "$CONTAINER_NAME" "$IMAGE_NAME:latest"

# Create output directory
mkdir -p "$OUTPUT_DIR"

# Copy published files
echo "Extracting build artifacts..."
if docker cp "$CONTAINER_NAME:/app/publish/." "$OUTPUT_DIR/"; then
    echo "Build artifacts extracted successfully"
else
    echo "Warning: Could not extract all artifacts, checking what\'s available..."
    docker run --rm "$IMAGE_NAME:latest" ls -la /app/publish/ || true
fi

# Clean up container
docker rm "$CONTAINER_NAME"

echo
echo "=========================================="
echo "Build process completed!"
echo "=========================================="
echo
if [ -d "$OUTPUT_DIR" ] && [ "$(ls -A $OUTPUT_DIR)" ]; then
    echo "Output directory: $OUTPUT_DIR"
    echo "Files:"
    ls -lh "$OUTPUT_DIR" | head -20
    echo
    echo "Binary file check:"
    file "$OUTPUT_DIR/[YOUR_APP]" 2>/dev/null || echo "[YOUR_APP] binary not found"
    echo
    echo "To test on target workstation:"
    echo "  scp -r $OUTPUT_DIR/* workstation:/apps/[YOUR_APP]/current/"
else
    echo "ERROR: No files in output directory!"
    echo "Check docker-build.log for errors"
    exit 1
fi

```

Again, remember to replace [YOUR_APP] in the above Dockerfile to your actual app name.

{/* ```bash
#!/bin/bash
# build.sh

set -e

echo "Starting Docker build..."

docker build -t your-app:latest .

echo "Extracting build artifacts..."

# Create output directory
mkdir -p ./dist

# Copy build output from container
docker create --name temp-container your-app:latest
docker cp temp-container:/app/publish ./dist/
docker rm temp-container

echo "Build completed successfully!"
```

#### Docker Compose for Development

For more complex scenarios, use Docker Compose:

```yaml
version: '3.8'

services:
  build:
    build: .
    volumes:
      - ./dist:/app/publish
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
    
  runtime:
    image: mcr.microsoft.com/dotnet/aspnet:8.0
    ports:
      - "5000:80"
    volumes:
      - ./dist:/app
    working_dir: /app
    command: dotnet YourProject.dll
    depends_on:
      - build
```

## Implementation Best Practices

### 1. **Multi-Stage Builds**

Use multi-stage Docker builds to optimize image size and build performance:

```dockerfile
# Build stage
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o out

# Runtime stage
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /src/out .
ENTRYPOINT ["dotnet", "YourProject.dll"]
```

### 2. **Layer Optimization**

Structure your Dockerfile to maximize Docker layer caching:

```dockerfile
# Copy and restore dependencies first (changes less frequently)
COPY *.csproj ./
RUN dotnet restore

# Copy source code (changes more frequently)
COPY . .
RUN dotnet build
```

### 3. **Build Arguments for Flexibility**

Use build arguments to customize builds for different environments:

```dockerfile
ARG BUILD_CONFIGURATION=Release
ARG DOTNET_VERSION=8.0

FROM mcr.microsoft.com/dotnet/sdk:${DOTNET_VERSION} AS build
RUN dotnet build -c ${BUILD_CONFIGURATION}
```

## Measuring the Impact

Teams implementing Docker-based builds typically report:

- **Eliminated hanging**: Complete resolution of build hang issues
- **Improved consistency**: Identical builds across development, staging, and production environments
- **Reduced debugging time**: Less time spent troubleshooting environment-specific issues
- **Better CI/CD reliability**: More predictable automated build processes

## Potential Drawbacks and Considerations

While Docker solves the immediate problems, it introduces some complexity:

### **Increased Resource Usage**

Docker containers consume additional memory and disk space. Ensure your development machines have adequate resources.

### **Learning Curve**

Team members unfamiliar with Docker need time to adapt to containerized workflows.

### **Build Time Overhead**

Initial Docker builds can be slower than native builds, though layer caching mitigates this over time.

### **Debugging Challenges**

Debugging applications running inside containers requires additional setup and tooling.

## Alternative Approaches

Before committing to Docker, consider these alternatives:

### **Using Different .NET Versions**

Sometimes switching between LTS and current .NET versions resolves hanging issues:

```bash
# Try different SDK versions
sudo apt install dotnet-sdk-6.0
sudo apt install dotnet-sdk-7.0
```

### **Environment Variables**

Some developers report success with specific environment settings:

```bash
export DOTNET_CLI_TELEMETRY_OPTOUT=1
export DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1
export NUGET_XMLDOC_MODE=skip
```

### **Build Isolation**

Running builds in isolated directories or using different user accounts sometimes helps:

```bash
# Build in temporary directory
mkdir /tmp/build-$(date +%s)
cd /tmp/build-$(date +%s)
git clone your-repo.git
cd your-repo
dotnet build
``` */}

## Looking Forward

The .NET build hanging issue on Linux remains an active concern in the .NET community. Microsoft continues working on improvements, but the complexity of supporting diverse Linux environments means progress is incremental.

Docker provides a pragmatic solution that works today. While it adds complexity to your development workflow, the trade-off between operational overhead and build reliability often favors containerization.

As the .NET ecosystem matures on Linux, we can expect better native support and fewer environment-specific issues. Until then, Docker remains a reliable path forward for teams serious about .NET development on Linux.

## Conclusion

Microsoft's embrace of open source and cross-platform development has created exciting opportunities for .NET developers. However, the reality of cross-platform development includes challenges that require practical solutions.

The persistent build hanging issues on Linux demonstrate that even mature frameworks can struggle with platform-specific complexities. Docker offers a proven workaround that many teams have adopted successfully, trading some additional complexity for significantly improved reliability.

Whether this Docker-based approach will remain necessary long-term remains to be seen. For now, it provides a stable foundation for .NET development on Linux, allowing teams to focus on building great applications rather than fighting build system issues.

If you're experiencing similar challenges with .NET builds on Linux, consider implementing a Docker-based workflow. While it may seem like overkill initially, the improved consistency and reliability often justify the additional setup complexity.

---

Do you have similar experience? Share your comments below.

320e7b744ccc39f7c0ff72a382e896737ceb0b5cd8969c9b0974d2ae0fff33f0

Comprehensive guide to resolving .NET Core build hangs and library dependency errors on Linux using Docker containerization for consistent builds.

Learn how Docker containers solve persistent .NET build hanging issues on Linux distributions.

Solving the .NET Build Hang on Linux with Docker


{/*
Prompt for for banner image generation:
Digital art, blog banner with a 16:9 aspect ratio. A glowing, stylized Windows error dialog box with the message "Windows cannot access \\smb-host\folder" is floating in a dark, abstract digital space with broken network lines, symbolizing a connection failure. The mood is frustrating but tech-focused.
*/}

## The Problem

I was building a bond yield calculator that needed to display complex mathematical formulas on the web. The page was supposed to render beautiful LaTeX-style equations using MathJax, but instead, visitors saw raw LaTeX code: literal dollar signs, backslashes, and `\frac` commands sprawled across the screen.

The formula that should have appeared as an elegant fraction looked like this instead:

<br />


$$ \text{Yield (\%)} = \frac{\text{Annual Coupon} + \frac{(\text{Face Value} - \text{Price})}{\text{Years to Maturity}}}{\frac{\text{Face Value} + \text{Price}}{2}} \times 100 $$


However, what actually showed up was:

```
[\ \text{Yield (\%)} = \dfrac{\text{Annual Coupon} + \frac{(\text{Face Value} - \text{Price})}{\text{Years to Maturity}}}{\frac{\text{Face Value} + \text{Price}}{2}} \times 100 \]
```

Not exactly user-friendly for someone trying to understand bond mathematics.

To debug this, it is common that we check the following:
1. Ensure the MathJax library is correctly loaded in the HTML `<head>`.
2. Verify the MathJax configuration for delimiters matches the LaTeX syntax used.
3. Confirm that the LaTeX code itself is valid and properly escaped.

It would be easy but time-consuming to manually check each of these steps. Instead, I decided to enlist the help of AI. Why waste time when an AI coding assistant might quickly identify the issue?

## The Contestants

I decided to test three leading AI coding assistants on this real-world debugging challenge:

1. **Google Gemini** - The AI that originally generated the problematic code
2. **OpenAI Codex** - The engine behind GitHub Copilot
3. **Claude Code** - Anthropic's CLI-based coding assistant

Each AI was given the same task: fix the MathJax rendering so formulas display properly.

## Round 1: Google Gemini

**Status: Failed (in a few attempts)**

Gemini was the first AI I turned to. Here's how our interaction unfolded:

### Attempt 1: Simplifying the Configuration

Gemini's first move was to simplify the MathJax configuration. The original code had a complex, custom script to find and render the formulas. Gemini replaced it with a more standard, simple configuration.

**The change:**
```diff
-    <script>
-        window.MathJax = {
-            tex: {
-                inlineMath: [["\$", "\$"]],
-                displayMath: [["\\[", "\\]"]],
-                processEscapes: true
-            },
-            options: {
-                renderActions: {
-                    find_script_mathtex: [10, (doc) => {
-                        for (const node of document.querySelectorAll('script[type^="math/tex"]')) {
-                            const display = !!node.type.match(/; *mode=display/);
-                            const math = new doc.options.MathItem(node.textContent, doc.inputJax[0], display);
-                            const text = document.createTextNode('');
-                            node.parentNode.replaceChild(text, node);
-                            math.start = {node: text, delim: '', n: 0};
-                            math.end = {node: text, delim: '', n: 0};
-                            doc.math.push(math);
-                        }
-                    }, '']
-                }
-            }
-        };
-    </script>
+    <script>
+        window.MathJax = {
+            tex: {
+                inlineMath: [['$', '$'], ['\$', '\$']],
+                displayMath: [['$$', '$$'], ['\\[', '\\]']]
+            }
+        };
+    </script>
```

**The result:** The formula was still not rendering.

### Attempt 2: Reverting and Adapting

Since the simple configuration didn't work, Gemini hypothesized that the original complex configuration was there for a reason. It reverted the configuration and, noticing that the script was designed to find formulas in `<script>` tags, it moved the LaTeX formula from a `<p>` tag into a `<script type="math/tex">` tag.

**The change:**
```diff
-                    <p class="mb-0">
-                        \[
-                        \text{Yield (\%)} = ...
-                        \]
-                    </p>
+                    <script type="math/tex; mode=display">
+                        \text{Yield (\%)} = ...
+                    </script>
```

**The result:** Still no good, and the formula was now completely blank. The custom script was removing the formula but failing to render it.

{/* ### Attempt 3: Back to Basics

Realizing that the custom script was the root of the problem, Gemini took a final stab at it. It removed the custom script again, went back to the simple configuration from the first attempt, and also removed the `{% raw %}` tags that were wrapping the formula, just in case they were causing a subtle issue.

**The final (and working) changes:**
1.  A simple, standard MathJax configuration.
2.  The formula placed directly in a `<p>` tag with `\[ ... \]` delimiters.
3.  No `{% raw %}` tags.

**The result:** Success! The formula finally rendered correctly.

While Gemini eventually found the solution, it took three attempts and a bit of back-and-forth. It felt more like a process of elimination than a direct diagnosis of the problem. */}


## Round 2: OpenAI Codex

**Status: Failed**

Codex took a different approach. Here is what we actually changed while trying to debug MathJax together:

### Attempt 1: Swap `defer` for `async`

Codex thought the math wasn't rendering because the MathJax script was waiting too long to execute. It asked me to replace `defer` with `async` so the browser would execute the script as soon as it downloaded.

**The change:**
```diff
-    <script defer src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"
+    <script async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"
             integrity="sha384-ypRjVNaE7p/Csq3wBECfp0o3lsRoiQFYbUrxWm8m6PHcbVBykedkOSi0PFo8SYK0"
             crossorigin="anonymous"></script>
```

**Result:** The script now loaded earlier, but MathJax still refused to typeset anything.

### Attempt 2: Rewrite the configuration

When the timing tweak failed, Codex proposed a brand-new configuration object with more explicit loader instructions and different delimiters, hoping MathJax would finally detect the LaTeX.

**The change:**
```diff
-        window.MathJax = {
-            tex: {
-                inlineMath: [["\$", "\$"]],
-                displayMath: [["\\[", "\\]"]],
-                processEscapes: true
-            },
-            options: {
-                renderActions: {
-                    find_script_mathtex: [10, (doc) => {
-                        // custom DOM walk removed for brevity
-                    }, '']
-                }
-            }
-        };
+        window.MathJax = {
+            loader: {load: ['input/tex', 'output/chtml']},
+            tex: {
+                inlineMath: [['$', '$'], ['\$', '\$']],
+                displayMath: [['$$', '$$'], ['\\[', '\\]']]
+            },
+            startup: {
+                typeset: true,
+                ready: () => {
+                    window.MathJax.startup.defaultReady();
+                }
+            }
+        };
```

**Result:** Still nothing. The page loaded faster, but the formulas stayed as plain text.

### Attempt 3: Force a manual re-typeset

Codex doubled down by asking me to trigger `MathJax.typesetPromise()` after the page rendered, just in case the automatic startup hook was being skipped.

**The change:**
```diff
@@
     document.addEventListener('DOMContentLoaded', () => {
-        // earlier script simply relied on MathJax startup
+        if (window.MathJax && window.MathJax.typesetPromise) {
+            window.MathJax.typesetPromise();
+        }
     });
```

**Result:** No helper message, no console errors—and still no rendered math.

While the suggestions were technically reasonable, none solved the rendering issue. Codex kept nudging configuration tweaks rather than diagnosing the real problem: how the MathJax library was being loaded and initialized in the first place.

## Round 3: Claude Code

**Status: Success**

Claude Code took a methodical approach:

1. **First attempt**: Changed the LaTeX delimiters from `\[` and `\]` to `$$`, and replaced `\dfrac` with `\frac` for consistency
2. **When I reported it still wasn't working**: Claude immediately identified the real issue

Here's what Claude Code changed in the script loading:

**Before:**
```html
<script defer src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"
        integrity="sha384-ypRjVNaE7p/Csq3wBECfp0o3lsRoiQFYbUrxWm8m6PHcbVBykedkOSi0PFo8SYK0"
        crossorigin="anonymous"></script>
```

**After:**
```html
<script src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-mml-chtml.js"></script>
```

The fix was elegant and precise:
- Removed the `defer` attribute that was causing timing issues
- Removed the integrity check that might have been blocking the script
- Added a proper startup configuration to ensure MathJax initializes correctly

**Result**: The formula now renders beautifully as an actual mathematical expression.

## Why Claude Code Won

Three key differences set Claude Code apart:

### 1. **Iterative Problem-Solving**
When the first solution didn't work, Claude didn't just offer more guesses. It recognized that the problem was deeper than syntax and immediately pivoted to examining the script loading mechanism.

### 2. **Root Cause Analysis**
Instead of suggesting configuration tweaks, Claude identified that the `defer` attribute and integrity constraints were preventing MathJax from loading properly. This showed actual understanding of how browser script loading works.

### 3. **Minimal, Focused Changes**
Claude made only the necessary changes. No over-engineering, no adding unnecessary complexity—just removing the attributes that were causing the problem.

## The Broader Lesson

This wasn't just about fixing a MathJax related bug. It revealed something important about AI coding assistants:

**Confidence ≠ Correctness**

All three AIs responded with confidence. Gemini defended its original implementation. Codex offered multiple "solutions." But only Claude Code actually fixed the problem.

The difference? Claude Code demonstrated:
- Better diagnostic reasoning
- Willingness to change approach when initial solutions failed
- Understanding of browser behavior, not just code syntax

## Practical Takeaways for Developers

1. **Don't trust the first AI-generated solution** - Even if it looks correct, test it thoroughly
2. **Choose AI tools that iterate** - The best AI assistants adapt when things don't work
3. **Value diagnosis over guessing** - An AI that understands *why* something is broken is more valuable than one that just suggests fixes
4. **Test with real scenarios** - This bug only revealed itself in actual browser rendering

## The Technical Details

For those interested, the core issue was:

1. The `defer` attribute delayed MathJax loading until after DOM parsing
2. The integrity hash might have been outdated or mismatched
3. The MathJax configuration needed to be loaded *before* the library, and the library needed to load *synchronously* to properly initialize

Claude Code recognized that the solution wasn't in the configuration—it was in how the script was loaded.

## Conclusion

In the battle of AI coding assistants, Claude Code didn't just win—it was the only one that actually solved the problem. While Gemini and Codex offered plausible-sounding advice, Claude Code demonstrated genuine debugging capability.

For developers building production applications, this distinction matters. You need an AI assistant that can not only write code but also troubleshoot real problems when things inevitably go wrong.

**Winner**: Claude Code
**Lesson Learned**: In AI-assisted development, actual problem-solving beats confident suggestions every time.


## Further Reading

For further reading, check out this article on [how to use Math Equations and LaTex Expressions in MDX Documents with Next.js](/blog/2025/01-31-using-math-equations-and-latex-expressions-in-mdx-documents-with-nextjs/).


<ContactFooter />


ddd20bfd638fdcc80ff6544ee659784646ec5e697709f50e6282ba952141344d

When mathematical formulas refuse to render on a web page, which AI coding assistant can actually solve the problem? I tested Google Gemini, OpenAI Codex, and Claude Code on the same MathJax bug. The results surprised me.

A real-world comparison of Google Gemini, OpenAI Codex, and Claude Code in debugging a MathJax rendering issue. Spoiler: only one AI actually fixed it.

Tag: Development

Tag: Development

AI Beyond the UI: From v0 Prototype to a Finished Product

Solving the .NET Build Hang on Linux with Docker

From Broken Fractions to Beautiful Formulas: Claude Code Trumpeted the Game!