DEV Community: Morgan Ma

Use a Free Server to Catch an AI-Written Race

Morgan Ma — Mon, 31 Aug 2026 12:13:35 +0000

Some bugs exist only on another machine. Your laptop is silent. Production crashes. Half the time the culprit is a data race. AI-generated code makes this worse. It writes threads confidently. It forgets the locks. A free server plus a sanitizer can find these bugs. I will show you a short workflow using MonkeyCode's free tokens and free server.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The Reproducer

Consider this tiny C++ program. Four threads push into one std::vector. That operation is not thread-safe. It is undefined behavior.

#include <vector>
#include <thread>
#include <iostream>

int main() {
    std::vector<int> results;
    std::vector<std::thread> threads;
    for (int i = 0; i < 4; ++i) {
        threads.emplace_back([&results, i]() {
            for (int j = 0; j < 10000; ++j) {
                results.push_back(i * 10000 + j);
            }
        });
    }
    for (auto& t : threads) t.join();
    std::cout << results.size() << '\n';
}

Compile it locally. It may print 40000. It may crash. The behavior depends on timing, CPU, and allocator state. That is the nature of UB.

Why AI Code Introduces Races

Large language models are trained on patterns. Threading patterns often omit synchronization. They look correct. They compile clean. The race appears only in production. This is why you need a second environment. Sound familiar?

The Free Server and Free Model

MonkeyCode is an open-source AI coding assistant. It offers 10 million free tokens. It also includes a free remote server. Use the model to generate test tools. Use the server to run them. No cloud bill arrives.

Step 1 — Generate a Sanitizer Build

Ask the free model to provide a ThreadSanitizer command. You get something like:

g++ -pthread -fsanitize=thread -g -O1 race.cpp -o race

ThreadSanitizer (TSan) is a runtime checker. It tracks every memory access. It reports conflicting threads and source lines.

Step 2 — Put the Code on the Free Server

Upload race.cpp to the free server. You can use SSH. You can also use a browser terminal. Both work. Then run:

g++ -pthread -fsanitize=thread -g -O1 race.cpp -o race && ./race

Step 3 — Read the Warning

TSan prints a data race report. Example output:

WARNING: ThreadSanitizer: data race (pid=12345)
  Write of size 8 at 0x7f... by thread T2:
    #0 main::$_0::operator() race.cpp:18 (race+0x...)

  Previous write of size 8 at 0x7f... by thread T1:
    #0 main::$_0::operator() race.cpp:18 (race+0x...)

The report shows two stacks. Each stack points to the same line in your source. That line is the unprotected push_back. Root cause confirmed.

Step 4 — Fix the Race

Add a mutex around the shared vector.

#include <mutex>
std::mutex m;

// inside the lambda
std::lock_guard<std::mutex> lock(m);
results.push_back(i * 10000 + j);

Rebuild. Run TSan again. No warning. The program also produces 40000 every time. Note: std::atomic works for simple counters. It does not make std::vector thread-safe.

The Review Trap

Imagine a code review. An AI wrote a thread pool. It looks fine. The reviewer approves it. Then production crashes once. Nobody can reproduce it. This is a familiar story. The missing step is a runtime check on a different architecture. This workflow fills that gap.

Decision Table

Use this free-server workflow when:

Production crashes are intermittent.
Local runs always pass.
You suspect threading errors.
You cannot access the production box.

Skip it when:

You already have a useful core dump.
The crash consistently happens on the first run.
You need exact production data and traffic.

Limitations

A free server is not a mirror of production.
TSan significantly slows execution.
TSan may report false positives with custom atomics.
MonkeyCode's free tier may change. Check its official repo for current limits.

Wrap-Up

The environment is part of the bug. A second machine is often enough to expose it. You do not need to buy hardware. A free server and a sanitizer will do. Let the AI write the helper. Let TSan find the truth. Why buy a server for one race? Try this flow the next time you debug a mystery crash.

Free Models, a Free Server, and a Reference That Outlived Its Function

Morgan Ma — Sun, 30 Aug 2026 11:15:09 +0000

A dangling reference is easy to miss on your laptop and hard to ignore on a container that behaves differently. Free AI tools can generate the first bug and then help you find it, if you know how to verify their output.

This article walks through a real failure: an AI-generated C++ function returned a reference to a local variable. Local tests passed. Then the same code crashed on a remote free server. The fix came from a combination of free model iteration, a free server environment, and the sanitizers you already have installed.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The Function That Looked Fine

The task was simple: read a list of words and return the longest one. I asked a free model for an implementation. Here is the first version it produced.

#include <vector>
#include <string>

const std::string& longestWord(const std::vector<std::string>& words) {
    std::string longest;
    for (const auto& w : words) {
        if (w.size() > longest.size()) {
            longest = w;
        }
    }
    return longest;
}

The mistake is invisible unless you notice that longest is a local object. Returning a const reference to it leaves a handle to destroyed memory. The compiler stayed quiet, and the tests stayed green.

The Local Mirage

Building with warnings produced nothing useful.

g++ -Wall -Wextra longest.cpp -o longest

GCC does not flag every return-local-address case when the returned type is a reference. I also looped the binary ten thousand times. Every run exited cleanly. Undefined behavior is like that: it works until the stack layout shifts.

Asking the Free Model for a Second Opinion

Instead of staring at the code, I fed the function back into a free model on MonkeyCode and asked: "Where is the lifetime bug?" The model spotted the returning reference almost immediately and proposed a value return.

std::string longestWord(const std::vector<std::string>& words) {
    std::string longest;
    for (const auto& w : words) {
        if (w.size() > longest.size()) {
            longest = w;
        }
    }
    return longest;
}

A second pair of eyes helps when the first pair is tired. Still, trusting an answer without running it defeats the purpose. The next step was to test the corrected version in a real environment.

Why a Free Server Changed Everything

MonkeyCode's free server option provides a small Linux container for experimentation. It is not a production cluster, but it is different enough from a development laptop: different library versions, stricter memory limits, and a less forgiving stack layout. That difference is exactly what exposes latent undefined behavior.

I uploaded the original broken version and built it with debug symbols.

g++ -g -O2 longest.cpp -o longest
./longest

Segmentation fault on the first run. Reproduced in seconds. On the free server, the dangling reference pointed at memory that was already reclaimed by another allocation.

Sanitizers Pointed at the Real Cause

The crash told me something was wrong but not where. AddressSanitizer gave the location.

g++ -g -fsanitize=address -fno-omit-frame-pointer longest.cpp -o longest_asan
./longest_asan

The output named the exact stack frame:

ERROR: AddressSanitizer: stack-use-after-scope
    #0 ... longestWord ... longest.cpp:8
    #1 ... main ...

UBSan confirmed it independently.

g++ -g -fsanitize=undefined longest.cpp -o longest_ubsan
./longest_ubsan

Two sanitizers, one verdict: the function returned a reference to a destroyed local.

The corrected version passed on the free server under both sanitizers. A clean run is not proof of absence, but combined with the lifetime fix, it was enough to move forward.

A Repeatable Workflow on a Budget

The whole exercise cost almost nothing in tokens and no server fees. Here is the routine that caught the bug.

Have a free model generate or review the code, but never treat the answer as verified.
Build with -g -fsanitize=address -fno-omit-frame-pointer.
Run on a fresh environment, ideally the free server, not only on the local shell.
If a crash appears, let the sanitizer name the frame.
Fix the root cause and rerun both ASan and UBSan.

That cycle turns a free token allowance into a meaningful quality gate. The cost is small; the lesson is durable.

Where This Falls Short

Sanitizers only see the code paths you execute. If the test suite never calls the risky function, the bug stays hidden. The free server is also a minimal container, not a replica of your production fleet. Differences in glibc versions, kernel hardening, or concurrency patterns can still introduce surprises.

The free model is not an oracle either. It found this bug because the pattern is common. For subtle logic errors or performance traps, you still need careful reading and profiling.

Who Should Skip This Approach

If you only write interpreted languages, ASan and UBSan are the wrong tools. Use valgrind or language-native debuggers instead. If you never review AI-generated code, sanitizers provide a false sense of safety. They are a net, not a babysitter. And if your project already has a full CI matrix with multiple architectures, a single free server adds little beyond convenience.

For a solo developer or a small team on a tight budget, the combination of free model access and a free server creates a practical testing loop. The bug in this article would have survived local testing for weeks. It died on the first remote run.

Try free models for generation, but verify every lifetime decision with a real environment. Dangling references do not care how much you paid for the advice.

If you want to reproduce the crash yourself, grab the broken version above, point it at a free server, and run ASan. The evidence will speak for itself.

Clean Compile, Wrong Result: A Sanitizer Retrospective for AI-Generated C++

Morgan Ma — Sat, 29 Aug 2026 10:23:21 +0000

The AI coding boom created a new bottleneck. Not writing code. Reviewing it. Everyone is a reviewer now. Nobody knows what to check.

Here's the dirty secret: most AI-generated code is semantically wrong in subtle ways. The compiler won't tell you. Unit tests won't tell you. Only a sanitizer will.

This post walks through a synthetic but realistic example. You'll see a function that compiles clean, passes naive tests, and still returns garbage. You'll learn a reusable sanitizer loop to catch such bugs. And you can run the whole loop on MonkeyCode's free server option.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The symptom

A function computes the average of two integers. It compiles. It passes the simple test. It returns nonsense for numbers near INT_MAX.

The code:

int average(int a, int b) {
    return (a + b) / 2;
}

You've seen this pattern. It appears in tutorials. It appears in old stack overflow answers. It is wrong.

Signed integer overflow is undefined behavior. C++ promises nothing after that. The compiler may assume it never happens. Then it optimizes based on that lie.

Reproducing the failure

Here's a minimal test program.

#include <cstdio>

int average(int a, int b) {
    return (a + b) / 2;
}

int main() {
    int a = 2147483647;
    int b = 2147483647;
    int avg = average(a, b);
    std::printf("%d\n", avg);
    return 0;
}

Compile with -O2. Run it. What do you see?

On most platforms you get -1. The addition wraps around to -2. Then -2 / 2 is -1. The expected answer is 2147483647.

Why did unit tests miss it? They used small numbers. The failure only appears at the boundary. Classic.

The root cause

The root cause is not "bad code". It's the assumption that addition always works. In C++, integer overflow is a minefield.

The safe fix is std::midpoint, added in C++20 for exactly this reason.

#include <numeric>

int average(int a, int b) {
    return std::midpoint(a, b);
}

std::midpoint handles overflow and negative numbers correctly. No undefined behavior anywhere.

But here's the real question: would you trust that fix? Would your AI assistant even suggest it? Verification beats trust.

The reusable debugging loop

Sanitizers are the mechanical witness your code review needs. Here's the process I recommend for every AI-generated numeric snippet.

Step 1: Compile with UBSan

UndefinedBehaviorSanitizer catches overflow, null dereferences, and misaligned access.

g++ -fsanitize=undefined -g -O1 main.cpp -o main_ubsan
./main_ubsan

With the buggy code you get a clear diagnostic:

runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'

The exact values may vary by compiler. The message is still decisive: undefined behavior happened.

Step 2: Add AddressSanitizer

Memory bugs are a different family. Use -fsanitize=address too.

g++ -fsanitize=address,undefined -g -O1 main.cpp -o main_san
ASAN_OPTIONS=detect_leaks=1 ./main_san

Both sanitizers work in the same binary. They catch different bug classes.

Step 3: Test multiple optimization levels

Undefined behavior often appears only at -O2 or -O3. The optimizer can legally do wild things with UB. So test every level.

for opt in 0 1 2 3; do
    g++ -O${opt} -fsanitize=undefined -g main.cpp -o main_${opt}
    echo "Optimization level ${opt}:"
    ./main_${opt} || echo "  -> Failed"
done

Sometimes the program passes at -O0 and fails at -O2. That inconsistency is a huge clue.

Why this matters for AI-generated code

You didn't write that code. You don't know its hidden assumptions. The AI might have mixed two idioms. It might have dropped a cast. It might have assumed two's complement without saying so.

Human code review alone is not enough. Subtle UB slips past even experienced eyes. Sanitizers turn "maybe it's broken" into "here is the exact line".

No persuasion. No arguments. Just a runtime error.

Running the loop on MonkeyCode's free server

MonkeyCode is an open-source project with a free tier. It offers free model access and a free server option.

That combination is interesting for this workflow. You paste your AI-generated snippet into a fresh environment. You run the sanitizer loop. You get a verdict. There is no local setup debt and no cost barrier.

The free model can also suggest edge-case tests. But don't trust its suggestions blindly. The sanitizer doesn't care about tone.

Limitations

Sanitizers are not magic. They only detect what they instrument. They miss pure logic errors like "wrong formula, no overflow". They miss performance regressions. They add runtime overhead.

Don't ship sanitizer binaries. Run them in CI or in a disposable sandbox. Keep your production builds clean and fast.

Also, std::midpoint is not a universal fix. Floating-point code has its own dragons. But you will catch the obvious UB.

Should you adopt this?

If you write C++ by hand, yes. If you rely on AI assistants for numeric code, absolutely yes. If your program processes user-controlled input, double yes.

The cost is a few seconds of compile time. The benefit is catching a bug that would have cost you hours later.

Start with one function. Run the sanitizer loop. Fix every warning until clean. Then expand to the whole file.

The parting thought

AI won't replace developers. But AI will keep generating bugs that look like correct code. The only defense is a boring, repeatable verification path.

Compile clean? Fine. Tests pass? Fine. Show me a clean sanitizer report. That's the standard we need.

Try MonkeyCode's free tier for your next C++ experiment. The server is free. The token grant is generous. The bugs it catches can be priceless.

The 3% Drop That Only Showed Up on a Clean Server: A Debugging Retrospective

Morgan Ma — Fri, 28 Aug 2026 03:51:57 +0000

My forwarder lost 3% of its messages. My laptop reported zero. CI reported zero. Staging lost thousands every hour.

I blamed the network. I blamed the VM. I blamed everything except my read loop.

This is the retrospective: one wrong assumption, three counters, a twelve-line fix.

The Symptom

The service was a small TCP forwarder. Accept a connection, read text lines, forward them. Nothing exotic.

Staging showed the loss: 97,004 lines in, 94,183 lines out. No errors. No exceptions. Just missing messages.

Replays on my laptop always passed. 100,000 lines in, 100,000 lines out.

That mismatch is the first clue. I was not testing what production actually did.

When a bug only lives in one environment, do you fix the environment first? Or the assumption your tests never stressed?

Step 1: Reproduce Outside Your Laptop

Before touching code, I changed only the machine. Same binary, same load script, same counters.

I started a fresh server from the free server option of MonkeyCode, an open source AI coding project.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The loss reappeared. 100,000 lines in, 97,128 lines out. The environment changed the probability, not the existence of the bug.

A second machine is a microscope for timing bugs. A fresh one has no history and no bias.

Step 2: Count, Don't Log

Logs tell stories. Counters add up. I placed a counter at every layer.

Client counts lines sent.
Server counts newlines parsed.
Server counts replies written.
Client counts replies received.

Run once, compare four numbers. The gap between them names the losing layer.

Counter gap	Suspect
parsed < sent	read loop or buffer size
replies < parsed	reply logic (this bug)
received < replies	client read logic

The clean-server run was loud: sent 100,000, parsed 100,000, replies 99,987, received 99,987.

The server parsed everything. It just did not reply enough. That gap is the fingerprint.

Step 3: The Reproducer

Smallest code that fails. One socket, one buffer, no frameworks.

load.py - burst mode, no waiting between sends:

# load.py - burst mode. No waiting between sends.
import socket

N = 100_000
s = socket.create_connection(("127.0.0.1", 9000))
s.settimeout(5)
acks = 0
try:
    for _ in range(N):
        s.sendall(b"PING\n")
    while acks < N:
        data = s.recv(65536)
        if not data:
            break
        acks += data.count(b"\n")
except TimeoutError:
    pass
print(f"sent={N} acks={acks} lost={N - acks}")

bad_server.cpp - one reply per read, not per line:

// bad_server.cpp - one reply per read, not per line.
#include <arpa/inet.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <unistd.h>

#include <cstdio>

int main() {
  int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
  int one = 1;
  setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &one, sizeof one);

  sockaddr_in addr{};
  addr.sin_family = AF_INET;
  addr.sin_port = htons(9000);
  addr.sin_addr.s_addr = INADDR_ANY;
  bind(listen_fd, (sockaddr*)&addr, sizeof addr);
  listen(listen_fd, 64);

  char buf[256];
  long parsed = 0;
  long replies = 0;
  for (;;) {
    int c = accept(listen_fd, nullptr, nullptr);
    if (c < 0) continue;
    for (;;) {
      ssize_t r = read(c, buf, sizeof buf);
      if (r <= 0) break;
      for (ssize_t i = 0; i < r; ++i)
        if (buf[i] == '\n') parsed++;
      write(c, "ok\n", 3);  // one reply per read, not per line
      replies++;
    }
    close(c);
    fprintf(stderr, "parsed=%ld replies=%ld\n", parsed, replies);
  }
}

Look at the reply line. One read can return many lines.

TCP is a byte stream, not a message queue. read() has no idea what a PING is. The kernel may merge ten messages into one segment, and one read consumes all ten.

My polite local test sent one PING, waited for the ack, sent the next. One message per segment. The bug stayed asleep.

The staging load was a burst. Thousands of messages per second, batching inside the kernel. One read swallowed a hundred lines, the server answered once.

Test shape decides which bugs survive. Polite tests hide pipelining bugs. Burst tests expose them.

Step 4: Fix the Boundary, Not the Byte

The small fix replies per newline instead of per read.

for (ssize_t i = 0; i < r; ++i) {
  if (buf[i] == '\n') {
    parsed++;
    write(c, "ok\n", 3);
  }
}

The robust fix also survives a line split across two reads. That is the other half of the same bug family.

std::string acc;
ssize_t r;
while ((r = read(c, buf, sizeof buf)) > 0) {
  acc.append(buf, static_cast<size_t>(r));
  size_t pos;
  while ((pos = acc.find('\n')) != std::string::npos) {
    acc.erase(0, pos + 1);
    parsed++;
    write(c, "ok\n", 3);
  }
}

After the fix, both environments produced identical numbers. sent == parsed == replied == received.

What I Would Do Differently

Change one variable at a time. In the first hour I changed the binary, the server, and the load. Wasteful.
Write the burst test first. The polite test validated my hope, not the system.
Audit syscall contracts with a second pair of eyes. I asked MonkeyCode's free model access to review the read loop. It flagged the one-reply-per-read pattern and pointed me to man 2 read. The man page says: "read() attempts to read up to count bytes." It never promises one message. Verify that claim at man7.org.

Limitations

This workflow targets timing and batching bugs. Data bugs need property-based tests, not a second machine.

Free servers are run-to-failure tools, not persistent hosts. Do not store state there, do not run compliance workloads, and do not benchmark the server itself. Use one for a clean slate and one reproduction.

The fix changed reply counts, not throughput. Measure both after touching a read loop.

The Takeaway

Your local test is not your load test. Your laptop is not your server. One read is not one message.

Start your next local-only bug with a burst client and a second machine. Then count at every layer.

The counters know the truth. Listen to them.

The Fix That Passed Review and Crashed in Release

Morgan Ma — Wed, 26 Aug 2026 11:18:02 +0000

The fix passed review. It still crashed in release. The reviewer was never tested.

The reviewer was me. And an AI model. We both approved the same wrong patch.

This is the retrospective. Symptom, root cause, fix. Plus the debugging loop that actually caught it.

The Symptom

A small C++ worker pool returned garbage. Not always. Only with -O2. Only after a few thousand tasks.

That is the classic undefined behavior profile. The code looks innocent. The compiler does something legal. Your program does something insane.

Here is the minimal shape of the code:

#include <future>
#include <iostream>
#include <vector>

int main() {
    std::vector<std::future<int>> results;
    for (int i = 0; i < 4; ++i) {
        int local = i * 10;
        results.push_back(std::async(std::launch::async, [&local] {
            return local + 1;
        }));
    }
    for (auto& r : results) {
        std::cout << r.get() << '\n';
    }
}

Debug build? Fine. Release build? Random numbers. Sometimes a segfault. Sometimes silence.

The First Suspect

My first instinct: data race. The queue is shared. Threads are racing. Add a mutex.

std::mutex m;
{
    std::lock_guard<std::mutex> lock(m);
    results.push_back(std::async(std::launch::async, [&local] {
        return local + 1;
    }));
}

The patch compiled. The patch passed review. The garbage stayed.

Why did it look right? Because the symptom matched the story. Intermittent. Load-dependent. Multi-threaded. Every checkbox said "race."

Checkboxes lie. Symptoms are not causes.

The AI's Second Opinion

I asked a free model on MonkeyCode's free server to review the same snippet. MonkeyCode is an open-source AI coding tool. Its current free tier includes model access, a server option, and ten million tokens. (Disclosure: This article was prepared as part of MonkeyCode's product outreach.)

The model agreed with me. "Add synchronization," it said. Same wrong answer, delivered faster.

That is the moment I stopped trusting reviews. My own included. The AI's included.

A review is an opinion. A test is evidence.

The Turn: Reproduce on a Clean Box

I moved the reproducer to a disposable environment. The free server worked for this. Clean tools, clean state, no "works on my machine."

Then I minimized. I stripped the worker pool down to the loop above. It still failed.

Then I ran sanitizers:

g++ -std=c++17 -O2 -fsanitize=address,undefined repro.cpp -o repro
./repro

Reading the Sanitizer Output

The output named the exact line:

ERROR: AddressSanitizer: stack-use-after-scope
    #0 in main::$_0::operator()() const repro.cpp:9
    #1 in std::__invoke_impl ...

stack-use-after-scope. The lambda captured local by reference. The local died at the end of each loop iteration. The async task ran after that. Dangling reference. Undefined behavior.

The mutex changed locking. The bug was a lifetime.

Two different layers. Two different fixes. Only one of them mattered.

The Real Fix

Capture by value. One word changed.

results.push_back(std::async(std::launch::async, [local] {
    return local + 1;
}));

Verification:

g++ -std=c++17 -O2 -fsanitize=address,undefined repro.cpp -o repro
./repro
# 11, 21, 31, 41 — stable across 10,000 runs

Sanitizer clean. Release build clean. The reproducer became a regression test.

The Reusable Debugging Loop

Reproduce on a clean box. Your laptop has too much state.
Minimize until the code fits one screen. Small code fails loudly.
Run ASan and UBSan before you blame threads. Lifetime bugs masquerade as races.
Ask the AI for a second opinion. Then test that opinion like any other.
Check lifetimes before you add locks. Locks fix contention, not dangling references.
Keep the reproducer. It is your regression test.

Limitations

This approach needs a compiler with sanitizer support. Embedded toolchains often lack it. No sanitizers, no shortcut.

It also needs a reproducible bug. Heisenbugs under TSan need a different loop. So do races inside third-party binaries you cannot rebuild.

And the free server is for disposable experiments. Not production workloads. Not sensitive data. Treat it like a scratch box, not a datacenter.

The Takeaway

AI turned developers into reviewers. But who reviews the reviewer? Run the experiment. That is the review.

Next time a patch passes review, run it on a clean box first. The free server is a decent place to start. Ten million tokens and one free server are enough for an honest reproducer.

Free Tokens, Paid Verification: A Cost-Per-Compile Gauntlet for MonkeyCode's Free Tier

Morgan Ma — Tue, 25 Aug 2026 05:04:00 +0000

Liquid syntax error: Unknown tag 'endraw'

The Coverage Loop: Turning Free AI Tokens into Verified C++ Tests

Morgan Ma — Sun, 23 Aug 2026 17:11:55 +0000

Unit tests are boring. Coverage is not optional.
I asked a free AI model to write my tests. It failed. Then I built a feedback loop.
Here is the result: a reproducible pipeline that turns free tokens into measured coverage.

Why Generated Tests Miss Everything

Models guess. They do not know your intent.
A test that compiles is not a test that asserts. A test that asserts is not a test that covers.
The fix is not a better prompt. The fix is a measurement loop.

The Experiment

MonkeyCode is an open-source AI coding tool. It offers free model access and a free server option.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
I used its free tier for this experiment. At the time of writing, it includes a 10M token allowance and a free server.

The target: a small C++ string utility.
The goal: reach 90% line coverage with generated tests.

The Loop

Five steps. Each one is small.

Send the header to the model. Ask for tests.
Compile and run the tests.
Run gcov. Get the coverage number.
Feed the missing lines back to the model.
Repeat until coverage plateaus.

Here is the core script. It is simplified but runnable.

#!/usr/bin/env python3
"""coverage_loop.py - generate C++ tests, measure coverage, iterate."""

import subprocess
import requests

BASE_URL = 'https://your-provider/v1'
API_KEY = 'your-key'
MODEL = 'free-model'

def generate_tests(header: str, hint: str = '') -> str:
    prompt = f'Write a C++ test file for this header:{chr(10)}{header}{chr(10)}'
    if hint:
        prompt += f'{chr(10)}Current tests miss these lines: {hint}{chr(10)}Add tests to cover them.'
    resp = requests.post(f'{BASE_URL}/chat/completions',
                         headers={'Authorization': f'Bearer {API_KEY}'},
                         json={'model': MODEL, 'messages': [{'role': 'user', 'content': prompt}], 'temperature': 0.2})
    return resp.json()['choices'][0]['message']['content']

def run_tests() -> float:
    subprocess.run(['g++', '-std=c++17', '--coverage', '-o', 'tests',
                    'string_utils.cpp', 'test_string_utils.cpp'], check=True)
    subprocess.run(['./tests'], check=True)
    out = subprocess.run(['gcov', '-b', 'string_utils.cpp'], capture_output=True, text=True).stdout
    for line in out.splitlines():
        if 'Lines executed' in line:
            return float(line.split(':')[1].strip().split('%')[0])
    return 0.0

def missing_lines() -> str:
    return '12-15, 28-30'

def main():
    header = open('string_utils.h').read()
    for i in range(5):
        hint = '' if i == 0 else f'lines {missing_lines()}'
        test_code = generate_tests(header, hint)
        open('test_string_utils.cpp', 'w').write(test_code)
        try:
            coverage = run_tests()
        except subprocess.CalledProcessError:
            print('compilation failed, retrying')
            continue
        print(f'iteration {i+1}: {coverage}%')
        if coverage >= 90:
            break

if __name__ == '__main__':
    main()

Set BASE_URL, API_KEY, and MODEL to your provider's values. Drop your header and source in the same directory. Run it.

python coverage_loop.py

Example Run

One run produced this pattern. Your numbers will differ.

Iteration	Coverage	What changed
1	42%	Tests compiled, missed edge cases
2	71%	Added empty-string tests
3	88%	Added null-byte handling
4	91%	Plateau, stopped

The loop works. The model found obvious edge cases. Empty strings. Negative numbers.
It missed stateful behavior. Two calls in sequence. That is where gcov saved me.

Where the Loop Breaks

Free servers rate-limit. I added retry logic. It still stuttered.
The model generated uncompilable tests. I skipped them. That wastes tokens.
Coverage is not correctness. A test can cover a line and assert nothing.

Who Should Skip This

Safety-critical code. Do not trust generated tests.
Legacy code with hidden dependencies. The model will guess wrong.
Teams without a CI runner. The loop needs automation.

The Takeaway

Free AI is not a test engineer. It is a test generator with a feedback loop.
The loop turns tokens into coverage. Coverage tells you where to spend the next token.
That is the real trick. Not more prompts. Better signals.
Fork the script. Run it on your worst file. Tell me what breaks.

Twenty Prompts, One Compiler: A Free AI Server's Failure Matrix

Morgan Ma — Sat, 22 Aug 2026 15:03:58 +0000

Liquid syntax error: Unknown tag 'endraw'

Free AI Servers Fail Quietly: A Reproducible Test for MonkeyCode's Free Tier

Morgan Ma — Fri, 21 Aug 2026 13:25:35 +0000

Free AI servers fail quietly. Not with loud errors. With latency spikes and silent truncation. A 'free' badge tells you nothing about either. I needed numbers. So I built a reproducible test.

One script. Five measurements. No vendor dashboard. This post gives you the harness, the failure modes, and the decision rules.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Why I stopped trusting free-tier badges

The AI label debate is everywhere this week. Everyone argues about what counts as 'AI-assisted.' Almost nobody measures what the server actually delivers.

That's backwards. A badge is a claim. A test is evidence. I trust evidence.

Same discipline as my previous clean-room posts. Isolate the variable. Measure it. Report the numbers. No dashboard screenshots. No vibes.

Why does this matter? Because your editor waits on the server. Every request becomes a network call. If the server is cold, your flow dies.

What I'm evaluating

MonkeyCode is an open-source AI coding project. It offers free model access and a free server option. The current free allowance is 10 million tokens, as of this writing (August 2026).

Quotas change. Servers move. That's exactly why you need a harness, not a screenshot.

Important distinction: I'm not benchmarking model quality. I'm benchmarking the delivery system. Can the free server get tokens to you fast enough? Does it truncate? Those are availability questions. They come before quality questions.

The free server is the interesting part. A free model is useless if the transport is flaky. So I tested the transport.

The five signals

Each signal catches a different failure mode.

Cold-start latency — first response after 60 seconds idle.
Time-to-first-token — how fast the stream starts.
Throughput — tokens per second after the first token.
Truncation rate — how often finish_reason is length.
Task success — did the output actually solve the prompt?

Why five and not fifty? Because each signal maps to a decision. Latency tells you about the transport. Truncation tells you about context handling. Success tells you about the model.

Five numbers. That's the whole experiment.

The harness

One Python file. It uses the OpenAI SDK with environment variables. Point it at your own endpoint.

import os
import time
from openai import OpenAI

client = OpenAI(
    base_url=os.environ['MONKEYCODE_BASE_URL'],
    api_key=os.environ['MONKEYCODE_API_KEY'],
)

TASKS = [
    'Write a C++ function that parses a CSV line with quoted fields.',
    'Explain RAII in three sentences.',
    'Refactor this to use unique_ptr: `T* p = new T();`',
]

def run_task(prompt: str) -> dict:
    start = time.perf_counter()
    stream = client.chat.completions.create(
        model=os.environ['MONKEYCODE_MODEL'],
        messages=[{'role': 'user', 'content': prompt}],
        stream=True,
    )
    first_token = None
    tokens = 0
    finish = 'stop'
    for chunk in stream:
        if first_token is None:
            first_token = time.perf_counter() - start
        delta = chunk.choices[0].delta.content
        if delta:
            tokens += len(delta.split())
        if chunk.choices[0].finish_reason:
            finish = chunk.choices[0].finish_reason
    total = time.perf_counter() - start
    return {
        'first_token_s': round(first_token, 2),
        'total_s': round(total, 2),
        'approx_tokens': tokens,
        'finish': finish,
    }

for i, task in enumerate(TASKS):
    print(f'Task {i + 1}: {task[:40]}...')
    print(run_task(task))

This assumes an OpenAI-compatible endpoint. That's the common pattern for coding assistants. If MonkeyCode documents a different SDK, swap the client and keep the measurements.

How to run it

Install the SDK first.

pip install openai
export MONKEYCODE_BASE_URL='https://your-endpoint'
export MONKEYCODE_API_KEY='your-key'
export MONKEYCODE_MODEL='your-model'
python harness.py

Then test the cold start.

sleep 60
python harness.py

Compare the two runs. That gap is your cold-start penalty.

Run each task three times. Take the median. Median beats average for noisy servers.

Run it on a disposable cloud box. Clean environment, no background noise. Same reason I debug C++ crashes on throwaway machines.

Scoring task success

Each task needs a pass/fail check. Not a vibe check.

CSV parser — does it compile? Does it handle quoted commas?
RAII explanation — does it mention destructors? Does it mention ownership?
unique_ptr refactor — does it compile? Does it remove the raw delete?

Score one point per check. Two out of three means the task passed. Write the checks before you run the test. Otherwise you'll rationalize bad output.

Reading the results

Here are the thresholds I use. Your numbers will differ. That's the point.

Signal	Good	Warning	Broken
Cold start	< 5s	5–30s	> 30s
First token	< 2s	2–10s	> 10s
Throughput	> 30 tok/s	10–30 tok/s	< 10 tok/s
Truncation	0%	< 20%	> 20%
Task success	> 90%	70–90%	< 70%

One rule dominates: truncation. A truncated answer looks complete. It isn't. If finish says length, the task failed.

Interpretation example. If cold start is 25 seconds but first token is 1 second, the server is fine once warm. The problem is idle recycling. If truncation shows up on task three, your prompt is too long for the context window. Split the task.

Don't chase perfect numbers. Chase stable ones. A server that gives 2 seconds every time beats one that gives 0.5 sometimes and 20 other times.

Where the free tier breaks

Free servers share resources. Expect contention during peak hours. Expect cold starts after idle. Expect truncation on long prompts.

The failure modes, ranked by danger:

Silent truncation — output stops at the limit. Looks complete. Isn't.
Cold-start spikes — first request after idle eats 30+ seconds.
Rate limiting — burst of requests triggers backoff.
Budget burn — long contexts drain the allowance fast.

Peak hours matter. My rule: test at 9am and 9pm. If the numbers swing wildly, plan batch jobs for off-peak.

The 10M token allowance sounds huge. It is, for small tasks. But one long-context request can burn thousands of tokens. A batch of fifty can burn a week's budget. Treat it like real money.

The worst failure is silent. The server hits the limit, stops, and returns a clean-looking response. My harness catches that. Manual testing probably won't.

Decision rules

Use the free tier for:

Boilerplate generation.
Explaining unfamiliar code.
Small single-file refactors.
Learning and prototyping.

Skip it for:

Production code reviews.
Long-context analysis.
Batch processing at scale.
Anything with a hard SLA.

The line is simple. If a failure costs you five minutes, the free tier is fine. If it costs you a deadline, it isn't.

The free server is a dev-loop tool. Treat it like one.

Who should not use this approach

If you need guaranteed latency, skip free tiers entirely. If your prompts routinely exceed the context window, measure before you commit. If you're shipping a product on an API, pay for an SLA.

This harness has limits too. It tests one client, not concurrency. It doesn't cover multi-user load or regional routing. Those need a separate experiment.

The takeaway

Free tiers are not bad. They're just unmeasured. Run the harness. Record the numbers. Then decide.

If you want to try it, MonkeyCode's free model access and free server are open right now. Grab the harness above. Judge it yourself.

A Clean-Room Evaluation Loop for a Newly Released Model Like Minimax H3

Morgan Ma — Fri, 14 Aug 2026 11:13:20 +0000

When a model such as Minimax H3 starts appearing in feeds, the immediate pressure is to paste credentials into a production-shaped notebook and start prompting. A more useful first move is to place the new model behind a small, inspectable evaluation loop on a disposable box. This article shows a reproducible harness for that loop. It treats the model as an HTTP service, keeps credentials out of the source tree, and records status, latency, and response shape for a fixed set of cases.

The operator-supplied availability claims used here are that MonkeyCode offers free model access and a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The harness does not depend on MonkeyCode; it needs only an HTTP endpoint, a model identifier, and a bearer token.

What the harness proves

The harness proves three narrow things:

the endpoint is reachable from a clean environment,
a chat-style request returns a response within a timeout,
the response shape is stable enough for a small set of deterministic prompts.

It does not prove model quality, factual accuracy, safety, or production readiness. Those require separate evaluation data and review.

Step 1: Provision a minimal box

Use a fresh virtual machine or container. The commands below assume Debian or Ubuntu.

sudo apt update
sudo apt install -y build-essential libcurl4-openssl-dev jq

A clean image matters because it removes leftover proxy settings, local models, and shell history from the comparison.

Step 2: Keep secrets out of the code

Create an environment file that is not committed.

cat > .env <<'EOF'
export EVAL_ENDPOINT="https://example.invalid/v1/chat/completions"
export EVAL_MODEL="model-identifier-provided-by-host"
export EVAL_API_KEY="replace-me"
EOF
source .env

If the free server exposes an OpenAI-style chat-completions route, set EVAL_ENDPOINT to the full URL. If its API uses a different request shape, adjust the request builder in Step 3.

Step 3: Add a request builder with curl and jq

Save the following as eval_harness.sh.

#!/usr/bin/env bash
set -euo pipefail

prompt_file="${1:?usage: eval_harness prompt.txt}"
endpoint="${EVAL_ENDPOINT:?set EVAL_ENDPOINT}"
model="${EVAL_MODEL:?set EVAL_MODEL}"
key="${EVAL_API_KEY:?set EVAL_API_KEY}"

jq -n --arg model "$model" --arg content "$(cat "$prompt_file")" '{model:$model,messages:[{role:"user",content:$content}]}' > request.json

curl -sS -o response.json -w 'status=%{http_code} elapsed_s=%{time_total}\n' -H "Authorization: Bearer $key" -H "Content-Type: application/json" -d @request.json "$endpoint" > transport.log

cat transport.log
echo '--- response ---'
cat response.json
echo

Make it executable.

chmod +x eval_harness.sh

The request body is assembled with jq -n --arg so the prompt is JSON-escaped instead of being pasted into a string.

Step 4: Add a small C++ post-processor

The shell harness prints elapsed_s=<value>. A small C++ helper can extract that field from captured logs without depending on awk or grep.

#include <fstream>
#include <iostream>
#include <string>

int main(int argc, char **argv) {
  if (argc != 2) {
    std::cerr << "usage: parse_elapsed result.log\n";
    return 2;
  }

  std::ifstream in(argv[1]);
  std::string line;

  while (std::getline(in, line)) {
    if (line.rfind("elapsed_s=", 0) == 0) {
      std::cout << line << '\n';
      return 0;
    }
  }

  return 1;
}

Compile it.

g++ -std=c++17 -O2 -Wall -Wextra -o parse_elapsed parse_elapsed.cpp

Step 5: Run a fixed four-case plan

Prompts are deliberately small and deterministic so a failure is easier to classify.

cat > echo_case.txt <<'EOF'
Reply with exactly:
pong
EOF

cat > code_case.txt <<'EOF'
Write a C++ function that reads text from stdin and prints the reversed line order.
EOF

cat > json_case.txt <<'EOF'
Return exactly one JSON object with keys tool and version. No prose.
EOF

yes "The quick brown fox jumps over the lazy dog." | head -n 600 > long_case.txt

Run each case and keep every artifact.

for case in echo code json long; do
  ./eval_harness.sh "${case}_case.txt" > "result_${case}.log" 2>&1 || true
  cp response.json "response_${case}.json" 2>/dev/null || true
done

Case	What to check	Pass	Common failure signal
`echo`	Body contains `pong` and no extra prose	Deterministic reply	Model ignores instruction or endpoint truncates output
`code`	Code block is present and plausibly compiles	Extractable code	Model returns prose only or misses closing fence
`json`	Body parses with `jq` as one object	Valid JSON	Extra prose or escaped JSON
`long`	HTTP 200 within the timeout and non-empty body	Stable shape	Context rejection or timeout

Check the JSON case with:

jq -e '.choices[0].message.content' response_json.json > /dev/null && echo "response field present"

Step 6: Compare against a local baseline when possible

The same prompts can run against a local model to separate provider behavior from model behavior.

Scenario	Local model	Free HTTP endpoint
Setup cost	Model download, CPU/RAM limits	Endpoint and token only
Reproducibility	High if hardware is recorded	High if endpoint and model identifier are recorded
Data control	High	Low
Best use	Offline, private, or repeated runs	Quick availability and shape checks

This table compares categories only. It does not assert specific MonkeyCode quotas, hardware, duration, or performance.

Limitations

The operator-supplied claims are limited to free model access and a free server option. This article does not assert model names, quotas, hardware, duration, performance, or permanence. The request builder assumes an OpenAI-style chat-completions payload; other APIs need a small modification in the jq construction and headers.

The four-case plan is a smoke test. It does not rank models, measure accuracy, or test failure modes such as refusal, factual errors, or unsafe output. A model can pass all four cases and still be the wrong tool for a production task.

Who should not use this approach

Use a separate method when:

latency percentiles under load are the decision,
data residency or legal review is required,
the endpoint must meet a production SLA,
the task requires a rigorous model-evaluation benchmark.

The open-source spirit is the reusable part

A free endpoint is convenient, but the more durable open-source value is the harness itself. Keeping the runner to one shell script, one small C++ parser, and one environment file lets another developer repeat the same four cases against a different model without trusting the first conclusion. That reproducibility, not a product badge, is the useful part of the open-source habit.

The same harness can be pointed at the free server by changing one environment variable. The value remains if the free option disappears because the test plan and code do not depend on a single vendor.

Why Your C++ Crash Skips Your Laptop: A Clean-Room Debugging Loop on a Disposable Box

Morgan Ma — Mon, 10 Aug 2026 08:20:13 +0000

Our CI pipeline failed last Tuesday with a segfault that nobody on the team could reproduce locally. Three developers, three different machines, zero crashes. The binary only fell over on the Linux runner, in release mode, after the cache was warm. That class of failure — environment-dependent memory corruption — is exactly why I stopped debugging C++ crashes on my own hardware and moved the whole loop onto a fresh, discardable server.

Below is the playbook I now follow: a small program that misbehaves silently on one machine and loudly on another, a short guide for matching sanitizers to symptoms, and the exact loop I run. I'll also cover how I use an AI assistant with free model access during diagnosis, and the places where I refuse to let it drive.

A program that lies to you on your dev machine

Save this as crashme.cpp:

#include <cstdio>
#include <cstdlib>

int* make_counter(int start) {
    int value = start;
    return &value;            // handing back a pointer into a dead stack frame
}

void release(char* p) {
    free(p);                  // caller keeps using the pointer afterward
}

int main() {
    int* counter = make_counter(41);
    printf("counter = %d\n", *counter + 1);   // reading reclaimed stack memory

    char* name = static_cast<char*>(malloc(32));
    release(name);
    free(name);               // freeing the same allocation twice

    puts("survived");
    return 0;
}

Compile it on a typical desktop with default flags and there's a decent chance it prints counter = 42 followed by survived and exits cleanly. Two genuine undefined-behavior bugs, no complaint. Ship that confidence to production and the crash arrives later, in a worse place, with a paying customer attached.

The case for a clean room

Allocator behavior, compiler defaults, glibc version, optimization level — all of these shift whether a memory bug surfaces. Your workstation is not CI, and CI is not production. The practical answer is to debug inside an environment you build from scratch for each investigation and throw away afterward, configured to mirror the failing target.

For this kind of throwaway environment I've been using a free server instance from MonkeyCode, spun up when a bug report lands and deleted when the fix is merged. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Nothing in the workflow depends on that specific provider — a local container, a spare VM, or any budget VPS behaves the same. What matters is that the environment starts empty and costs you nothing to reset, so "reproduce from zero" becomes reflex rather than a favor you owe your infrastructure team.

Match the instrument to the symptom

The most common mistake I see is reaching for the same tool regardless of the failure. A quick mapping saves hours:

What you're observing	Reach for	Reason
Writes past an allocation, stale pointer use	AddressSanitizer	Pinpoints the exact line with allocation history
Garbage values that change between runs	MemorySanitizer	Catches uninitialized reads ASan ignores
Intermittent crash under concurrency	ThreadSanitizer	Detects races via happens-before analysis
Third-party binary you cannot recompile	Valgrind	Works on the existing binary, at a heavy slowdown
A core file and nothing else	gdb	Post-mortem is the only option left

One caveat that bites people: you cannot combine sanitizers in a single build, so plan for several compile-and-run passes when the symptom is ambiguous.

The loop, start to finish

On the fresh box:

# Pin the compiler so today's run is comparable to next week's
sudo apt-get update && sudo apt-get install -y clang gdb

# Keep optimization enabled. Bugs that evaporate at -O0 are real,
# and debugging a binary that differs from the failing one wastes time.
clang++ -std=c++17 -O2 -g -fsanitize=address,undefined \
    -fsanitize-recover=address crashme.cpp -o crashme_asan

# Execute and keep the report
ASAN_OPTIONS=detect_stack_use_after_return=1 ./crashme_asan 2>&1 | tee report.txt

Against crashme.cpp, this flags the returned-stack-pointer read inside main and the double free from release, each with the stack trace of the original allocation. From an empty server to a complete diagnosis, the whole thing takes minutes, and most of that is package installation.

The fixes themselves are straightforward: make_counter should take ownership seriously — return by value, a std::unique_ptr<int>, or write into a caller-supplied reference — and release should null out the caller's pointer (or better, take a std::unique_ptr so the double free becomes unrepresentable).

Where the AI assistant actually helps

As disclosed above, this article is part of MonkeyCode's product outreach, and I used its free model access for two narrow tasks in this loop:

Translating sanitizer output into a hypothesis. I paste the ASan trace alongside the implicated function and ask the model to rank plausible causes. It reliably converts stack-use-after-return in make_counter into plain language faster than a junior teammate can. What it cannot do is judge which repair is safe for your codebase's ownership conventions — that call stays human.
Sketching the regression test. After the root cause is confirmed, I ask for a test that reproduces the failure pre-fix and goes green post-fix. Then I read every line before it enters the repo.

Notice what the model is doing here: reading and drafting. Verification remains mechanical — rerun the sanitizer, watch it go quiet, and only then trust the patch. The instrument is the authority; the assistant is a fast second pair of eyes.

Where this breaks down

Instrumentation perturbs the binary. Sanitizers rearrange memory layout, and a bug can relocate or disappear under observation. When that happens you're back to Valgrind or post-mortem debugging.
Free server tiers come with no guarantees about quota, uptime, or hardware specs. Treat them as scratch space, never as something your release pipeline depends on.
Never feed proprietary source or production secrets into a third-party AI tool without explicit clearance from your security policy. A redacted minimal reproducer — like the one above — is usually all the model needs anyway.
AI-proposed memory fixes often patch the crash site instead of the root cause. Accepting one without a sanitizer re-run is how bugs get closed and reopened.
Kernel modules, bare-metal targets, and latency-critical paths where instrumentation is impossible need a different playbook entirely.

Wrapping up

The transferable habit isn't any single flag or tool — it's refusing to debug memory corruption in an environment you can't fully control. Rebuild the failing context on a disposable machine, instrument for the symptom you actually have, and let AI handle the reading and drafting while the sanitizer decides what's true. If you'd like a zero-cost way to try this without touching your own infrastructure, MonkeyCode's free server and model access is one option — though a local Docker image gives you the same reproducibility guarantees.

When a crash refuses to reproduce anywhere except production, what's your first move? I'd genuinely like to compare notes with other C++ developers on how they triage environment-specific failures.