DEV Community: Kanurkar Prateek

Everything I got wrong building an autonomous X bot

Kanurkar Prateek — Tue, 11 Aug 2026 13:39:50 +0000

Everything I got wrong building an autonomous X bot

It writes a tech post three times a day and publishes without me. The code took an afternoon. The interesting part was the six times testing proved a design I was confident about was wrong.


Running cost	$0.00
Runtime dependencies	0
TypeScript	4,054 lines
Bugs found by testing	6

BuzzEngine watches Hacker News and GitHub Trending, works out what's actually gaining traction, fetches the primary source, writes a post about it, judges its own work, and publishes to X. On a schedule. Without anyone approving anything.

COLLECT ──▶ DEDUPE ──▶ SCORE ──▶ RESEARCH ──▶ DRAFT ──▶ GATE ──▶ PUBLISH
 HN,GitHub   subject +  velocity   fetch the     LLM      LLM +    Buffer
 Reddit, X   URL + text + topic    primary                7 checks  ──▶ X
                                   source                + rules
                                                            │
                                                     fail ──┘
                                                   (try next candidate)

That diagram is the boring part. Every box in it works. What follows is the story of the six times a box looked like it worked and didn't — because that's where all the actual engineering was.

01 · The wall you hit before writing any code

X shut down its free API tier in February 2026. Posting now costs $0.015 a post — or $0.20 if the post contains a link. No subscription, no monthly minimum; you buy credits and they drain.

Three posts a day with links is about $18 a month. Not much, but the brief was zero.

So I proposed putting the link in a self-reply instead: a clean main post at $0.015, link underneath. About 93% cheaper.

That was wrong, and it took saying it out loud to notice. A reply is also a post, and it contains a link. So it bills at $0.20 too — meaning link-in-reply costs $0.215 per story, more than putting the link in the main post.

Lesson: The unit a price applies to is part of the price. I'd optimised the wrong axis for an hour before checking what "post" meant to the biller.

The only genuinely cheap option was omitting links entirely. Which is a content decision disguised as a billing one, and a bad one for a bot whose job is pointing at things.

02 · The way out was someone else's API relationship

The unlock wasn't a cheaper tier. It was noticing that social schedulers hold their own X API access and absorb that cost as part of their product.

Most had closed up. Zapier restored its X integration but now requires your own developer credentials. Make.com killed theirs outright in 2025. IFTTT still works but throttles hard on free.

Buffer's free plan turned out to include the one thing that mattered:

Buffer free plan	Limit
Channels	3
Queued posts	10, refillable
API requests / month	3,000
Cost	$0, permanent

Three posts a day uses about 90 of those 3,000 requests — 3% of the quota. Buffer talks to X; we never touch X's API, never hold X credentials, never see a bill.

There was one scare: Buffer stopped accepting new OAuth app registrations, which kills third-party integrations. But the new GraphQL API uses personal API keys, which is exactly what a personal bot needs. No app registration, no approval queue.

status : sent
link   : https://x.com/i/status/2086783660578029792
error  : None

First real post, published through Buffer, $0 spent.

03 · Two prompts that couldn't both be satisfied

The first version produced posts like this:

Persona-based prompt packaging claiming proven deliverables. Shell language suggests text templates, not runtime agents. The value is in the process documentation, not automation.

The gate kept rejecting drafts for asserting things the source didn't support. I assumed the writer was being careless. It wasn't.

I was handing the writer a headline and a one-line blurb, then instructing it to "say something the headline doesn't." There is no honest way to satisfy both. The only moves available are speculation — which the gate then correctly refused.

The prompts were in direct contradiction and I'd written both.

The fix was a step I'd left out: fetch the actual primary source before writing. A repo's README, an article's body. Suddenly there was real material to be interesting about.

Before research:

Persona-based prompt packaging claiming proven deliverables…

After research:

Docker Sandboxes wrap agents in microVMs so you can safely run --dangerously-skip-permissions. Everyone reads this as security; it's really about removing the approval bottleneck.

Lesson: When a model keeps failing a check, suspect the brief before the model. Two instructions that can't both hold will produce garbage forever.

04 · The judge was reading a redacted copy

Then the gate started rejecting accurate posts. It flagged "858 stars" as an unsupported claim — a number sitting right there in the source material.

Because I'd built the two prompts separately, and the gate's version of the material was missing the engagement figures the writer had been given.

The gate was doing its job perfectly. It was judging against a strictly smaller context than the writer had, so genuinely-sourced facts looked invented. Three candidates rejected in a row; the run produced nothing and logged no error.

Both stages now build their material from one shared function. Not because it's tidier — because it makes the mismatch structurally impossible rather than merely unlikely.

Lesson: If one component checks another's work, they must see identical inputs. A verifier with less context than the thing it verifies invents failures.

05 · Binning good work over four characters

A run rejected all three candidates:

gate rejected  too long: 326/280
gate rejected  too long: 284/280
gate rejected  too long: 307/280
run complete — outcome: skipped

One of those missed by four characters.

Length was in the same bucket as fabrication: hard fail, discard, move on. But "slightly too long" is a mechanical problem — exactly what the editor's revision path exists for.

Rules are now split by whether a rewrite can fix them:

	Examples	Action
Fatal	Invented facts, duplicates, blocked terms	Reject before spending a model call
Fixable	Too long, stray hashtag, wall of prose	Send back to the editor, then re-check

The next run showed it working: "33 characters too long" → the editor cut hedges, kept the argument, and the re-check passed. That post published.

06 · HTTP 200, and nothing inside it

The bot runs on Kimi K2.5 through Azure. Early on, calls came back successful and empty:

HTTP 200
content          : ""
reasoning_content: "The user wants me to say OK. This is a very sim…"
finish_reason    : length

Reasoning models spend the token budget on an internal scratchpad before writing anything. Run out mid-thought and you get a valid 200 with an empty answer. One request produced 21,568 characters of reasoning and no output.

Three layers up, that surfaced as no JSON value found in model output — an error pointing nowhere near the cause.

The adapter now detects the exact shape (empty content + finish_reason: length) and says what actually happened, naming the fix. The guard fired on its very first real run, which is the only reason I found the next bug.

Lesson: A successful status code is not a successful outcome. Check the shape of what came back, and make the error message name the cause, not the symptom.

07 · A URL is not a subject

The account posted about the same repository twice.

Dedupe existed — canonical URL matching, fuzzy title similarity, a 45-day memory. It just answers a narrower question than the one that matters. Different repo from the same lab? Passes. Second Docker announcement that week? Passes. Same story from a different outlet? Passes.

I tried fixing it with judgement first: show the editor the last ten posts, tell it to reject repetition. Then I replayed a near-duplicate against real history.

It approved. Scores of 7–9 across the board, flagging nothing.

Repetition lost to seven positive criteria. One instruction among many is not a constraint.

So candidates now carry subject keys, and anything matching one used in the last seven days is dropped before a model ever sees it:

github.com/labX/agent          ──▶  repo:labx/agent
                               ──▶  org:labx

docker.com/blog/thing          ──▶  site:docker.com

news.ycombinator.com  ──▶  arstechnica.com/x  ──▶  site:arstechnica.com

The subtlety is granularity. Keying on the domain would make github.com a subject and block every repository on earth. Aggregators — GitHub, HN, Reddit, X — are containers, not subjects, so they resolve to the linked article's domain instead.

Verified against the real failure:

✅ vercel/ai-sdk                    kept — genuinely new subject
🚫 PrimeIntellect-ai/prime-agent    already posted
🚫 PrimeIntellect-ai/other-thing    different repo, same org
🚫 Docker ships another feature     different story, same company

Lesson: Deterministic rules don't drift, don't get talked round, and cost nothing to run. Use judgement for taste; use code for anything you can define.

08 · Attaching an image can be a downgrade

Images seemed like a straightforward win. They aren't, for a reason specific to the platform: X gives attached media precedence over the link card.

When a post carries a link, X already renders the page's og:image — with the headline and domain attached, for free. Upload that same image and you replace that card with a bare picture. Strictly worse.

So the rule became: only attach an image the card wouldn't already show.

Source	Attached
GitHub repo	nothing — the card already shows it
Product page with a screenshot	the screenshot

Then the first test attached gray.png. Body images arrive in document order, and page furniture comes first — logos, banners, background textures. They're now filtered and ranked, using dimensions in the filename as the signal: a 2320×1205 screenshot is content, a 1110×326 strip is decoration.

09 · What "quality bar" actually meant

The last change came from a question I didn't have a good answer to at first: why not just post whatever it finds?

So I read back every rejection. Four of five were invented facts — benchmark scores that don't exist, a timeframe the source never gave, a draft saying "We built" about someone else's repository. One was mechanical.

None were "not funny enough." The gate had never been fussy about taste — but the threshold was, because a single number governed all seven criteria. An honest, unremarkable post got binned for scoring 6 on humour.

Criterion	Floor	Why
Accuracy	8	Publishes under a real name
Funny, interesting, memorable, human, clear, concise	5	A flat post costs nothing

Two bars, not one. A merely-decent post publishes. A fabrication never does — and never trades against "we need something today."

Lesson: "Quality" isn't one number. Separate the failures that cost something from the ones that are just disappointing.

10 · What it writes now

Docker built a cage so AI agents can run 'YOLO mode' safely. That's the actual name for --dangerously-skip-permissions.

Your bot gets root on a fake computer where it can delete files freely. We gave robots autonomy, then immediately grounded them.

Published · understandable 9 · accurate 9 · human 8

Someone built a staffing agency for AI coding tools. Hire a frontend wizard or Reddit ninja through an app. Each agent has a personality and KPIs.

We finally automated the jobs, then immediately recreated the corporate structure to manage them.

Published · found on GitHub Trending

The formatting matters more than it looks. Early drafts came out as one block of prose, which reads as machine-written regardless of how good the observation is. Posts are now 2–4 short beats separated by blank lines — enforced in code, because the break before the last line is what makes a punchline land.

11 · The throughline

Six bugs, and five of them share a shape: a design that was reasonable in the abstract and wrong against reality. None were caught by reading the code. All were caught by running it and looking hard at the output.

What I'd carry to the next one:

Test the boring thing first. The pricing model, the response shape, the identifier you invented. That's where the assumptions hide.
Prefer code to prompts for anything definable. Dedupe, length, banned phrases, structure — all started as instructions and all worked properly only once they became rules.
A verifier needs the verified's full context. Otherwise it manufactures failures and you debug the wrong component.
Fail closed on the thing that costs something. If the gate errors, the post is rejected. Silence is cheap; a fabrication under your name isn't.
An error message should name the cause. "No JSON found" sent me three layers from the actual problem.

The bot has been running since. It publishes up to three times a day, skips days when there's nothing worth saying, and hasn't yet posted anything I'd want to delete.

That last part is the gate doing its job — which mostly means refusing to publish things a more eager system happily would.

Stack: TypeScript with zero runtime dependencies · GitHub Actions · Buffer free tier
Sources: Hacker News, GitHub Trending, Reddit, X
Model: provider-agnostic — Anthropic, OpenAI, Gemini, or any OpenAI-compatible endpoint

I replayed 5 years of git history into SigNoz. It silently drops any span older than 15 days.

Kanurkar Prateek — Wed, 15 Jul 2026 11:58:08 +0000

The plan was simple: turn every pull request in
SigNoz's own repo into a trace, so I could
ask "how long do PRs really wait for review?" with a p95 instead of a vibe.

Then I sent seven spans. All seven came back 200 partialSuccess:{}. Four of
them existed. Nothing logged an error. No metric moved.

This is the three hours I spent finding out why, the one-line change that fixed
it, and the bot that made my first dashboard a lie. If you have ever wondered
whether your spans are actually arriving: go look. Don't trust the 200.

The setup

Self-hosted SigNoz v0.131.0 on AKS, collector v0.144.5. Pull the PR history from
GitHub's GraphQL API, turn each PR into a trace, push it over OTLP with real
historical timestamps.

The span model is the whole trick. Every span's duration is a real wait:

PR #123 (first commit → merge)
├── authoring              first commit → PR opened
├── awaiting first review  opened → first review     ← the human latency
├── review round 1 by alice (CHANGES_REQUESTED)
└── awaiting merge         last approval → merged

Because the durations are real, SigNoz's built-in aggregations do the analysis
for free. I didn't have to build any of it.

Gotcha #1: the endpoint that lies

My SigNoz LoadBalancer has a public IP, so I pointed the exporter at it. 200 OK. Zero traces.

That 200 is the React app. SigNoz's UI serves index.html for any unmatched
path, so /v1/traces returns a cheerful 200 text/html. So does
/this/is/not/real/xyz123:

$ curl -s -o /dev/null -w "%{http_code} %{content_type}\n" \
    -X POST http://<lb-ip>:8080/v1/traces
200 text/html; charset=utf-8

An exporter pointed there gets a success response for every batch, forever,
while dropping every span. The real ingest ports (4317/4318) live on
signoz-otel-collector, which is ClusterIP and isn't exposed at all.
Check the content-type, not the status code.

Gotcha #2: the wall at exactly 15 days

Port-forwarding to the real collector, I sent probes at different ages and
checked what survived:

span age	HTTP response	in ClickHouse?
1d, 5d, 14d, 14.9d	`200 partialSuccess:{}`	yes
15.1d, 16d, 20d	`200 partialSuccess:{}`	no

A hard wall at exactly 15.0 days. The same 200 on both sides of it.

The wrong theory (that fit perfectly)

SigNoz's traces table has a TTL:

TTL toDateTime(timestamp) + toIntervalSecond(1296000)

1296000 seconds is 15 days. It's evaluated against the span's own timestamp
rather than ingest time, so a 2021 span is expired the moment it lands. The
numbers matched exactly. Case closed.

It was wrong. I raised retention to six years and confirmed it in ClickHouse
(toIntervalSecond(189216000)). The wall didn't move. Still exactly 15 days.

Two numbers were both 15 for unrelated reasons and I'd assumed causation. What
killed the theory was bisecting the pipeline: writing a 730-day-old row
directly into ClickHouse, bypassing the collector.

INSERT INTO signoz_traces.signoz_index_v3
  (timestamp, trace_id, span_id, name, duration_nano, `resource_string_service$$name`)
VALUES (now() - INTERVAL 730 DAY, 'aa00...', '1122...', 'direct-730d', 1000000, 'direct-test');

It persisted. ClickHouse was happy to store a two-year-old span. The database
was never the problem.

The actual answer

The collector logged nothing. Its refused/dropped metrics were zero. The
pipeline had no filter processor. OpAMP reported "Config has not changed".

The answer was in the source —
clickhouse_exporter.go:144:

maxAllowedDataAgeDays: 15,

Hardcoded. And in
clickhouse_exporter_v3.go:414:

ts := uint64(span.StartTimestamp())
if ts < uint64(oldestAllowedTs) {
    s.logger.Debug("skipping span outside allowed time window", ...)
    continue
}

Two things make this invisible. It logs at Debug, and the collector runs at
Info. And it's a bare continue, so no metric increments and
send_failed_spans stays at zero, because as far as the exporter is concerned
nothing failed. The span dies in the one gap where nothing is counted: after
accepted, before written.

Then I found the part that makes this more than a gotcha. The logs exporter
has the identical constant, but
exposes it:

defaultMaxAllowedDataAgeDays int = 15
MaxAllowedDataAgeDays *int `mapstructure:"max_allowed_data_age_days"`

You can backfill logs older than 15 days. You cannot backfill traces. Same
constant, same purpose, one configurable and one not.

That asymmetry is an unfinished job, and the history says so. In January 2026
someone filed
#750 describing
exactly this, for logs. Their words: "Collector metrics indicate success, but
no data appears in SigNoz/ClickHouse." They found it the same way I did, by
turning on debug logging and reading the source.

It was fixed the next day.
PR #746 added
max_allowed_data_age_days in +20/−4 across six files. Every one of them
sat under clickhouselogsexporter/. The traces exporter, with the same hardcoded
15, wasn't touched.

So the maintainers already agree the limit should be configurable. They merged
that position six months ago. Traces just never got the same twenty lines. As of
v0.144.6, released the day before I went looking, it still hasn't.

The fix is one line

- maxAllowedDataAgeDays: 15,
+ maxAllowedDataAgeDays: 3650,

I built the patched collector and ran it on my laptop against ClickHouse over a
port-forward, so I never touched the cluster. Then I ran both binaries against
the same database with the same span:

collector	HTTP response	spans stored
stock (`15`)	`200 partialSuccess:{}`	0
patched (`3650`)	`200 partialSuccess:{}`	2

One constant. With Debug on, the stock binary finally admits it:

debug  clickhousetracesexporter/clickhouse_exporter_v3.go:414
       skipping span outside allowed time window

Act two: it stored my data eight times

Patch working, I fired all 91,536 spans. The client was delighted: sent 91536/91536 http=200. The database had 445,038 rows and 52,212 distinct span
IDs — 8.1× duplication.

Writing through a kubectl port-forward is far slower than the in-cluster path
the default timeout assumes. Writes timed out and the exporter did what a good
exporter does: it retried. Retries are at-least-once, so every timed-out batch
rewrote rows that had already landed. The fix was a 180s timeout and turning
retry off, so a timeout becomes a visible gap instead of silent duplication.

My own verify command had called this "all spans accounted for", because it
compared row count to expected instead of distinct span IDs. My verification
tool had the same bug as the thing it was verifying: it trusted a number without
checking what it meant.

The payoff, and the bot

With the patch in, all five and a half years landed: 91,532 of 91,536 spans,
7,345 PRs, 2021-01-07 → 2026-07-15, for about 5 MB. The data was never the
expensive part — the 15 days was.

Then I opened one trace:

PR #9415  "fix(api-monitoring): border being hidden"     145 d
├── awaiting first review                              144.9 d
├── review round 1 by H4ad      APPROVED                    0 m
├── review round 2 by YounixM   APPROVED                  3.8 m
└── awaiting merge                                        1.5 h

The review took four minutes. The wait took five months.

My first headline was "the median PR is reviewed in 1 hour." Real number, real
query, complete nonsense. ellipsis-dev is an AI review bot, the single largest
reviewer in the repo, and it responds instantly:

reviewer	n	p50	p95
bots	1,576	1.85 min	32.8h
humans	4,667	4.76 h	15.33 days

A quarter of the "reviews" weren't people. If you're a human waiting on review,
1.0h is a lie, and it's the number the obvious query hands you.

I also nearly shipped a "slowest reviewer" leaderboard. The top entries had
n=1, n=2, n=3. A p95 over one sample isn't a statistic, and these are real
named people. Worse, the metric is backwards: awaiting first review grouped by
reviewer measures how long the PR waited before that person showed up. They
didn't cause the wait, they ended it. Whoever finally reviewed that 145-day-old
PR rescued it. The leaderboard ranks rescuers as culprits.

Review volume is answerable, because it measures work actually done, so
that's what the panel shows instead.

What I'd tell my past self

200 OK from an OTLP endpoint means "I parsed your protobuf." Nothing more. The only way to know your telemetry arrived is to query it back.
Two equal numbers are not causation. The TTL was 15 days and the wall was 15 days and they were unrelated. Bisecting the pipeline took ten minutes and killed a theory I'd have defended for another hour.
Silent drops hide at Debug. If data vanishes with no errors, turn on debug logging before you read any more source.
Retry is at-least-once. A slow sink doesn't just make things slow, it makes duplicates. Prefer a visible gap.
Look at who is in your data before you trust an aggregate. A quarter of my reviewers were a bot. The p50 wasn't wrong. It was answering a different question than the one I asked.

Conclusion

Backfilling historical traces into SigNoz is impossible out of the box, and
nothing tells you: not the HTTP response, not the logs, not the metrics. It's
one hardcoded constant, and it was already made configurable for logs six
months ago, in twenty lines.

Tools are here:
Signoz-Git-PR-Review-Latency,
including the probe that finds the wall on any OTLP endpoint.

Verified on SigNoz v0.131.0 and signoz-otel-collector v0.144.5; the constant is
unchanged on main and in v0.144.6. Your version may differ — run the probe and
find out.