DEV Community: pickuma

How We Use AI Without Letting It Hallucinate Into Reviews

pickuma — Mon, 22 Jun 2026 03:10:58 +0000

An LLM will tell you, in confident prose, that a tool has a free tier it does not have, a price that changed eight months ago, and an integration that was never shipped. None of those are typos. They are the model filling a gap in its training data with the most plausible-looking token, and plausible is exactly the problem: a hallucinated spec reads identically to a correct one. If you publish reviews, that failure mode is not a curiosity. It is the thing that gets a reader to sign up for the wrong plan.

We use AI to write here, and we say so on every article that an LLM touched. So the honest question is not whether we use it — it's what we do to keep it from inventing facts. This is the workflow.

The one rule: AI never sources its own facts

The single decision that prevents most hallucinations is structural, not clever. We separate two jobs that LLMs are wrongly assumed to do together: generating prose and establishing facts. The model is allowed to do the first. It is never allowed to do the second.

Concretely, that means every load-bearing claim in a review — a price, a tier limit, a launch date, whether feature X exists — comes from a source we opened ourselves, not from the model's memory. The pricing page. The changelog. The docs. The actual product, in a trial account. We paste those facts into a notes document first, with the URL and the date we checked it, and only then does the model get to write around them.

The prompt we hand the model is the inverse of how most people use these tools. Instead of "tell me about Tool X's pricing," it's "here are the four pricing facts, verified today; write the comparison paragraph using only these and flag anything you'd normally add that isn't here." That last clause matters. It turns the model's instinct to embellish into a list of things for a human to go verify, rather than a list of things that quietly ship.

The most dangerous hallucinations are the boring ones. A fabricated "revolutionary new architecture" is easy to catch because it sounds like marketing. A fabricated "$12/month Pro tier" looks like every other true sentence on the page. We treat any unsourced number — price, limit, percentage, date — as guilty until a primary source proves it.

A related discipline: we don't let the model cite. If a draft comes back with "according to a 2024 study" or "users report," that phrase gets cut unless we can produce the study or the actual thread. Models generate citations the same way they generate everything else — by pattern — and a confidently formatted fake reference is worse than no reference, because it borrows the authority of a real one.

What the model is actually good for

Saying "we don't trust it with facts" can read as "we don't really use it," which isn't true. The model does a lot of work; it just does the kind of work where being wrong is visible and cheap to fix.

It restructures. Hand it a messy set of verified notes and it produces a clean section order faster than we would. It catches the second "however" in a paragraph. It rewrites a sentence we've stared at too long. It generates the three FAQ questions a reader probably has, which we then answer ourselves from sources. It drafts the comparison-table skeleton so we're filling cells instead of building markup.

None of those tasks require the model to know a single true fact about the outside world. They're transformations of text we already verified, or structural suggestions a human signs off on instantly. That's the sweet spot: the model's output is checkable at a glance, and a wrong answer costs us ten seconds, not a reader's trust.

The place we keep the source-of-truth — the verified facts, the dated URLs, the "do not let the model touch this" list — needs to be a real document, not a chat scrollback. We run it in a structured workspace so each claim has a checkbox, a source link, and a last-checked date that an editor can sort by.

The check before publish, and the check after

Before a review goes out, it gets a pass whose only job is to find unsourced claims. The reviewer isn't reading for style; they're reading every factual sentence and asking "where did this come from?" If the answer isn't in the notes doc, the sentence doesn't ship. This is deliberately a separate pass from the editing pass — bundling them is how a smooth, well-written, factually invented paragraph slips through, because good prose lulls you into trusting the content.

Do this on anything you publish with AI help, even outside reviews: read once for quality, then read again only for claims, tracing each to a source. The second read feels redundant right up until it isn't. The two failure modes — bad writing and confident fiction — hide from each other.

The after-publish problem is different and sneakier. A review can be 100% accurate the day it ships and wrong three months later because the tool changed its pricing. No amount of pre-publish discipline catches that. So the dated source links aren't just for the initial check — they're a recheck schedule. When a fact's last-checked date gets old, or when a tool announces a change, we re-open the primary source and update the article, and we log it in the changelog so readers can see what moved and when. An AI-assisted review that's never revisited drifts into the same wrongness as a hallucinated one; it just takes longer to get there.

That's the whole system, and it's intentionally unglamorous. The model writes; humans own the facts; every claim has a dated source; two reads before publish and a recheck after. None of it depends on the model getting better or being prompted more cleverly. It depends on never asking the model to be the thing it can't reliably be.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Tiingo vs Polygon.io: Market Data APIs for Indie Quant Projects in 2026

pickuma — Mon, 22 Jun 2026 03:09:42 +0000

You are building a backtester, a screener, or a dividend tracker on a weekend budget, and you have hit the question every indie quant hits eventually: where does the data come from? Two names show up again and again for people who refuse to pay Bloomberg-terminal money — Tiingo and Polygon.io. They overlap enough to look interchangeable in a feature grid and differ enough that picking the wrong one means rewriting your data layer three weekends from now.

We pulled both APIs into a small test harness — a Python script fetching daily bars, a few intraday requests, and a fundamentals call — to see where the friction actually lives. What follows is the decision the way a solo builder has to make it, not the way a sales page frames it.

What you are actually choosing between

Tiingo started as an end-of-day (EOD) data shop and still leans that way. Its core strength is clean daily price history going back decades, survivorship-bias-adjusted, plus fundamentals, a curated news feed, crypto, and forex. Intraday equity data comes through IEX, which means you are seeing IEX's slice of the tape rather than the full consolidated SIP feed. For daily-bar backtests, dividend analysis, and long-horizon research, that distinction does not matter. For anything claiming to model real fills, it matters a lot.

Polygon.io is built around the tape itself. You get aggregates (minute and daily bars), but also trades and quotes — the tick-level data that Tiingo simply does not sell at the indie tier. Polygon covers stocks, options, indices, forex, and crypto, with full historical depth on paid plans and WebSocket streaming for live data. If your project touches options, or you want minute bars you can trust for intraday logic, Polygon is the one with the raw material.

The shorthand: Tiingo is a research-grade EOD and fundamentals provider that happens to offer some intraday. Polygon is a market-microstructure provider that happens to offer daily bars. Most indie projects only need one side of that, and knowing which side you are on settles half the decision before you compare a single price.

Pricing and rate limits on a solo budget

This is where the two diverge hardest, so verify the current numbers before you commit — both vendors revise tiers, and the figures below are directional, not contractual.

Tiingo's appeal has always been how little it costs. The free tier covers EOD data with modest hourly and daily request caps, enough to prototype an entire EOD strategy without paying anything. The paid "Power" tier has historically sat near $10 a month and lifts those caps substantially — genuinely unusual pricing for adjusted historical equity data, and the main reason hobbyists keep recommending it.

Polygon's free tier is real but tighter for active development: a low per-minute call ceiling and limited historical lookback that you will outgrow the moment you start backfilling. Paid plans begin around $29 a month for the entry stock tier and climb from there as you add real-time access, more history, and higher rate limits. Options and full tick data live on the higher tiers. The pattern is clear — Polygon costs more because it is selling more granular data, not because it is gouging.

	Tiingo	Polygon.io
Best at	EOD bars, fundamentals, news	Tick/quote data, options, streaming
Intraday source	IEX feed	Full tape (paid tiers)
Entry paid price	~$10/mo (verify)	~$29/mo (verify)
Free tier usefulness	High for EOD prototyping	Limited for active dev
Streaming (WebSocket)	Limited	Yes, on paid tiers

Market data licenses restrict redistribution. Both providers draw a sharp line between personal/research use and serving that data to your own users or displaying it in a public product. If your indie project becomes a thing people sign up for, re-read the data agreement before you ship — non-display and redistribution terms are where hobby projects quietly turn into license violations.

Which one fits your project

Match the API to what you are building rather than to which feature list looks longer.

Pick Tiingo if your project is EOD-shaped: a daily-rebalanced portfolio backtester, a factor screener, a dividend or fundamentals dashboard, or anything where you pull data once a day after the close. The price-to-value ratio is hard to beat, the adjusted history is clean, and you will not pay for granularity you never query.

Pick Polygon if you need intraday truth: options analytics, minute-bar strategies you intend to take seriously, live dashboards over WebSocket, or research that depends on trades and quotes rather than OHLC summaries. You will pay more, but you are buying data Tiingo does not offer at this tier, so the comparison stops being apples-to-apples.

A quietly common answer is both. Several indie builders run Tiingo for cheap historical EOD and fundamentals while subscribing to Polygon only for the specific intraday or options data a strategy needs. Two thin clients behind one internal data interface costs less than over-buying a single premium plan to cover a use case it was never the cheapest tool for.

Whichever you choose, the part that eats your weekends is not the vendor — it is the glue code: retry logic, rate-limit backoff, schema normalization, and caching so you stop re-fetching the same bars. That is the layer worth writing carefully and letting an AI pair-programmer accelerate.

Build the ingestion layer so swapping providers is a config change, not a rewrite. Then the Tiingo-versus-Polygon decision stops being permanent — you can start cheap on Tiingo and graft Polygon in later exactly where the data demands it.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

What the Sharpe Ratio Actually Tells You (and Where It Misleads)

pickuma — Mon, 22 Jun 2026 03:08:27 +0000

You have seen the number quoted in fund factsheets, backtest dashboards, and Twitter threads: a single figure that supposedly tells you whether a strategy is any good. A Sharpe of 0.5 gets a shrug. A Sharpe of 2 gets attention. A Sharpe of 3 gets funded. The problem is that the number answers a narrower question than most people think it does, and three of the most common ways to push it higher have nothing to do with making more money per unit of real risk.

How the number is built

The Sharpe ratio, introduced by William Sharpe in 1966, is mechanically simple. Take your portfolio's return, subtract the risk-free rate (a short-term Treasury yield), and divide by the standard deviation of those excess returns:

Sharpe = (mean excess return) / (standard deviation of excess return)

It is a reward-to-variability ratio. It answers one specific question: for every unit of volatility you stomached, how much return above cash did you earn? Nothing more.

Two details trip people up. First, the result depends on the measurement interval. A Sharpe computed from daily returns is annualized by multiplying by the square root of 252 (trading days); monthly returns scale by the square root of 12. That scaling assumes returns are independent from one period to the next — an assumption we will come back to, because it is where a lot of the misleading happens.

Second, the rough benchmarks floating around (below 1 is mediocre, 1 to 2 is good, above 2 is very good) are folklore, not law. The long-run Sharpe of the S&P 500 is somewhere around 0.4 to 0.5. So any backtest claiming a sustained Sharpe of 3 is implicitly claiming to be roughly six times more efficient than the entire US equity market. That should raise your eyebrows before it raises your allocation.

Where it misleads

The Sharpe ratio uses standard deviation as its definition of risk, and standard deviation is symmetric. It treats a 5% surprise gain as exactly as "risky" as a 5% surprise loss. For most investors that is backwards — you do not lie awake worrying about your upside.

That symmetry creates the single most dangerous blind spot: strategies with negative skew look fantastic right up until they detonate. Consider selling out-of-the-money options. You collect small, steady premiums month after month. The return stream is smooth, volatility is low, and the Sharpe ratio climbs. Then a tail event arrives and a single month erases years of those premiums. The Sharpe ratio, computed over the calm stretch, never warned you — because the loss had not happened yet, and the metric only sees realized volatility.

A high Sharpe ratio over a short, calm period is not evidence of skill — it can be evidence that you are short a tail risk that hasn't been priced yet. Insurance-selling, carry trades, and illiquid-credit strategies all produce flattering Sharpe ratios precisely because their losses are rare and clustered.

The second failure mode is return smoothing. Standard deviation assumes you can mark your portfolio to market accurately and frequently. Illiquid assets — private credit, real estate, some hedge fund books — get marked infrequently and conservatively, which makes consecutive returns look correlated and artificially calm. Andrew Lo's 2002 paper on the statistics of Sharpe ratios showed that correcting for this serial correlation can cut a reported figure substantially. If a fund's returns barely move month to month while public markets gyrate, the smoothness is often an artifact of the valuation process, not the absence of risk.

Third, sample size. A Sharpe ratio is an estimate, and estimates have error bars. The standard error shrinks roughly with the square root of the number of periods observed. In practice this means a Sharpe of 2 computed over six months of daily data is statistically almost indistinguishable from zero — the confidence interval is wide enough to swallow the whole claim. You need years, not months, before the number stabilizes enough to act on.

Fourth, interval and autocorrelation gaming. Because annualizing assumes independent returns, a strategy with positive autocorrelation (trends that persist) will show an inflated annualized Sharpe, while one with mean-reverting returns shows a deflated one. Switching from daily to monthly sampling can quietly change the headline figure without anything about the underlying strategy changing at all.

If you want a metric that addresses the skew problem directly, the Sortino ratio swaps total standard deviation for downside deviation, so it only penalizes volatility below a target. The Calmar ratio divides return by maximum drawdown, which speaks to the question investors actually care about: how deep was the worst hole?

Metric	Risk measure	Best at exposing
Sharpe	Total standard deviation	General risk-adjusted return
Sortino	Downside deviation only	Strategies penalized unfairly for upside vol
Calmar	Maximum drawdown	Tail and drawdown pain

None of these is a replacement. They are a panel. A strategy that scores well on Sharpe but poorly on Calmar is telling you something specific: its average ride is smooth, but its worst stretch is brutal.

How to use it without being fooled

Treat the Sharpe ratio as one input, sanity-checked against three questions. Is the track record long enough for the number to be statistically real? Is the return distribution roughly symmetric, or is there hidden negative skew? Are the assets marked frequently and honestly, or is the smoothness manufactured?

The discipline that protects you is keeping a written record — for each strategy, log the sample length, the skew, the maximum drawdown, and the Sharpe alongside it, so you compare like with like instead of trusting a single decontextualized figure. A structured research log beats a scatter of spreadsheet tabs you forget the assumptions behind.

The ratio earns its place because it is comparable across very different strategies and trivial to compute. Just remember what it is measuring — excess return per unit of historical, symmetric, accurately-marked volatility — and be suspicious whenever any of those three qualifiers is doing quiet work in the background.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

TCP vs UDP, Explained Through What Breaks When You Pick Wrong

pickuma — Mon, 22 Jun 2026 03:07:11 +0000

Most "TCP vs UDP" explanations stop at a feature table: TCP is reliable and ordered, UDP is fast and connectionless. True, and useless. You don't feel the difference until a wrong choice ships and something behaves in a way the table never warned you about — a multiplayer game that stutters precisely when the network is busiest, a metrics agent that reports numbers from 90 seconds ago, a file transfer that arrives corrupted with no error logged anywhere.

The useful way to learn the two protocols is backwards: pick each one for the wrong job and watch what breaks. The failure modes are specific, repeatable, and they map directly onto the guarantees each protocol makes.

What TCP guarantees, and what those guarantees cost

TCP gives you a byte stream that arrives in order, with no gaps and no duplicates, or the connection dies trying. To deliver that, it opens with a three-way handshake (SYN, SYN-ACK, ACK), assigns every byte a sequence number, acknowledges what it receives, retransmits what it doesn't, and slows itself down when the network signals congestion. You write send(), the bytes come out the other end in the right order. That contract is why HTTP, SSH, and database wire protocols all sit on top of it.

The cost is hidden in the word ordered. TCP will not hand your application byte 5,000 until bytes 1 through 4,999 have arrived. If a single packet in the middle is lost, every packet that arrived after it sits in the kernel's receive buffer, complete and useless, until the retransmission of the missing one lands. This is head-of-line blocking, and it is the single most important TCP behavior nobody mentions in the feature table.

Now pick TCP for a 60-tick multiplayer shooter. Each tick you send a position update. A packet drops — normal on any real network. TCP detects the loss and retransmits, which on a typical link takes at least one round-trip time, often more once the retransmission timer is involved. For that entire window, every newer position update is stuck behind the lost one. The player freezes, then snaps forward when the backlog flushes. The cruel part: this gets worse under load, exactly when players notice. You picked the protocol that prioritizes delivering stale data over delivering fresh data, in a domain where stale data is worthless.

Head-of-line blocking is a property of the ordered stream, not of packet loss. You cannot configure it away on a TCP socket. If your application would rather drop a late update than wait for it, TCP is structurally the wrong tool — no amount of tuning changes that.

There's a quieter TCP trap too: Nagle's algorithm. To avoid flooding the network with tiny packets, TCP may hold a small write, waiting to coalesce it with the next one. Combined with delayed ACKs on the receiver, this can stall a small request-response exchange for up to roughly 40 ms while each side waits for the other. For a chatty protocol sending many small messages, that latency is invisible in a LAN test and brutal in production. The fix is TCP_NODELAY, but you only reach for it once you know the behavior exists.

Where UDP wins, and the bill it hands you

UDP is almost nothing: a 8-byte header, source and destination ports, length, checksum. No handshake, no sequence numbers, no acknowledgments, no retransmission, no ordering, no congestion control. You hand the kernel a datagram and it tries once. The datagram arrives intact, arrives corrupted-and-discarded, arrives out of order relative to its siblings, arrives duplicated, or never arrives — and UDP tells you nothing about which happened.

That sounds worse, until you remember the game. With UDP, a lost position update is simply skipped; the next datagram carries a newer position anyway, so there's nothing worth retransmitting. No head-of-line blocking, because there is no line. This is why real-time voice, video, and games live on UDP, and why QUIC — the transport under HTTP/3 — was built on UDP specifically to escape TCP's head-of-line blocking while rebuilding reliability per-stream.

But UDP hands you a bill, and developers underpay it constantly. Pick UDP for a job that actually needs reliability — say, shipping log lines to a collector — and you will reinvent TCP, badly. First you notice lines go missing under load, so you add acknowledgments. Then duplicates appear, so you add sequence numbers to dedupe. Then you discover messages arrive out of order, so you add a reordering buffer. Then the receiver gets overwhelmed because nothing throttles the sender, so you add flow control. You have now written a worse TCP, with more bugs, and you still don't have congestion control, so your agent contributes to network collapse during an incident.

UDP has no congestion control. A naive UDP sender blasting datagrams as fast as it can will keep blasting while the network is already saturated, making an outage worse for everyone sharing the link. If you build on UDP, throttling is your responsibility, not the protocol's.

There's also a size trap. A UDP datagram larger than the path MTU (commonly around 1500 bytes on Ethernet) gets fragmented at the IP layer. If any single fragment is lost, the entire datagram is discarded — and many middleboxes drop IP fragments outright. So a 4 KB UDP message can vanish on networks where a 1 KB one always works, with nothing in your logs. Keeping datagrams under the MTU is a constraint you have to enforce yourself.

The decision, framed by failure mode

Skip the feature checklist. Ask one question: when a packet is lost, what does your application want to happen?

If the answer is "wait for it, I need every byte in order" — file transfer, an API call, a database query, anything where a gap corrupts meaning — use TCP and accept the latency variance. If the answer is "skip it, the next one supersedes it" — live telemetry, game state, voice, anything where freshness beats completeness — use UDP and budget engineering time for the reliability you do need.

The trap on both sides is the same shape: each protocol's strength is the other's failure mode. TCP's ordering becomes head-of-line blocking. UDP's leanness becomes a pile of reliability code you have to write and test yourself. Picking well means knowing which failure your application can tolerate, not which feature list looks longer.

Before committing to a transport, write down the worst realistic packet-loss rate for your deployment and trace what your code does at that rate. "It worked on localhost" tests a 0% loss network — the one environment where TCP and UDP behave almost identically, and therefore the one that teaches you nothing.

The protocols haven't changed in decades. What changes is whether you chose the one whose failure mode your application can actually absorb.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

From Bootcamp to First Pull Request: A 30-Day Plan That Actually Ships

pickuma — Mon, 22 Jun 2026 03:05:55 +0000

Most bootcamp grads finish able to build a todo app from a blank file, then freeze the first time they clone a repo with 40,000 lines they didn't write. The gap isn't syntax. It's the work of finding one tractable change inside a system you don't understand and shipping it without breaking anything else. This is a 30-day plan that ends with a merged pull request to a real project. It's split into four weeks, and each week ends with a checkpoint you can verify yourself — no mentor required to tell you whether you passed.

Week 1: Pick a project and read it before you write anything

The instinct after a bootcamp is to start coding immediately. Resist it for seven days. Your only job in week one is to choose a project and understand how it runs.

Pick something you already use and that accepts contributions. A CLI tool, a documentation site, a small library in a language you know. Avoid the giant frameworks — React and Kubernetes get hundreds of PRs a week and your first patch will sit in a queue for a month. Look for a repo with 200 to 2,000 stars, commits in the last 30 days, and an open issues list that isn't a graveyard.

Once you've cloned it, the test for week one is mechanical: can you get the project running locally and can you run its test suite? That's it. If the README's setup steps fail — and they often do — fixing those steps is itself a legitimate first contribution. Keep a running note of every command that didn't work and what you did instead.

Read the last 20 merged pull requests before you read the source. They show you what "normal" looks like for this project: how big a typical change is, how the maintainers phrase reviews, whether they want tests, and what the commit message style is. You're learning the house rules before you walk in.

By day seven you should be able to answer three questions: How do I run it? How do I run the tests? Where does the code that does the main thing actually live? If you can't, you picked too large a project. Swap it now, while swapping is cheap.

Week 2: Find the smallest real change you can make

Week two is a scavenger hunt, not a coding sprint. You're looking for a change small enough that you can be confident it's correct, but real enough that someone wants it merged.

Start with labels. Most active repos tag issues with good first issue, help wanted, or documentation. Filter for those, then ignore anything that's been open for more than a few months with discussion — those are usually harder than the label suggests, which is why they're still open. You want a fresh issue, or one nobody has claimed.

If the labelled issues don't fit, generate your own. A typo in the docs. An error message that doesn't say what actually went wrong. A function with no test for an obvious edge case. A broken link in the README. These feel too trivial to matter, but a maintainer would rather merge a clean one-line fix than triage a sprawling refactor from someone they've never seen before. Your first PR is as much about establishing that you write small, correct, reviewable changes as it is about the change itself.

The checkpoint for week two: you can describe your intended change in one sentence, and that sentence touches fewer than 20 lines. "Add a test for the empty-input case in parseConfig." "Fix the install command in the README that points at the old package name." If your sentence has an "and" in it, split it into two PRs and ship the smaller one first.

Week 3: Make the change on a branch and prove it works

Now you write code. Create a branch named for the change (fix/readme-install-command, not patch-1). Make the edit. Then do the part that separates a contribution from a guess: prove it works.

For a code change, that means a test. If the project has a test suite, add or modify a test that fails before your change and passes after it. Run the full suite, not just your new test — your job is to show you didn't break the other 300 tests while fixing one thing. For a docs change, "proving it works" means following your own instructions on a clean checkout and confirming they actually run.

Write the commit message in the project's style. If their history is fix: correct install command, match it. Small signals like this tell a maintainer you read the contributing guide, and they make the difference between a review that takes two minutes and one that gets ignored.

Do not bundle unrelated cleanups into your first PR. You will be tempted to fix the inconsistent indentation two lines below your change, or rename a confusingly-named variable. Don't. A reviewer evaluating a one-line fix can approve it on sight; the moment your diff touches ten files "while I was in there," it becomes a code review they have to schedule. Keep the diff boring.

Week three's checkpoint: git diff main shows only the lines your one-sentence description promised, and the test suite passes locally on your branch.

Week 4: Open the PR and respond like a professional

Push your branch, open the pull request, and fill out the template. Most projects have one — it asks what the change does and how you tested it. Answer both. Link the issue you're closing. Keep the description to a few sentences: what was wrong, what you changed, how you verified it.

Then wait, and watch how you behave during the wait. Maintainers are volunteers; a response can take a day or three weeks. Do not bump the thread after 24 hours. When review comments arrive, treat every one as a request, not an attack — even the blunt ones. If you disagree with a suggestion, say so once, with a reason, and defer to the maintainer if they hold the line. It's their project.

If the PR gets merged, you're done — that's the whole goal, and you now have a public, verifiable contribution with your name on it. If it gets closed without merging, that's also a result: ask politely what would have made it mergeable, and apply the answer to your next attempt. Either way, repeat the cycle. The second PR takes a third of the time, because you've already paid the one-time cost of learning how one project works.

The plan works because it inverts the bootcamp habit of building from scratch. Reading before writing, shipping the smallest correct change, and proving it works are the actual day-one skills of a working developer. The merged PR is the receipt.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

How to Use AI Coding Tools in Interviews Without Getting Rejected in 2026

pickuma — Mon, 22 Jun 2026 03:04:39 +0000

The rules changed and nobody sent a memo. A few years ago, opening Copilot during a coding interview was an automatic fail. In 2026, a growing share of companies hand you an AI-enabled editor on purpose and watch how you drive it. The problem is that the other share still treats any autocomplete as cheating, and a third group hasn't decided — which means the fastest way to get rejected is to guess wrong about which room you're in.

We ran through the public interview policies and engineering-blog posts of dozens of companies and structured-interview vendors over the past year, plus the loop formats candidates described after the fact. The pattern is not "AI good" or "AI bad." It's that the interview is now testing a different thing, and people fail because they prepared for the old test. This walks through how to read the format, what to disclose, and the skills that decide the outcome once the tooling is stripped away.

Read the room before you type

There are really only three interview formats in 2026, and your first job is to figure out which one you're in — ideally before the call, in writing.

Tool-allowed by design. The recruiter says something like "use whatever you'd use day-to-day" and the screen-share shows a real editor with Cursor or Copilot active. Here the interviewer is not watching whether you can write a binary search from memory. They're watching whether you can specify a problem, reject a wrong suggestion, and notice when the generated code is subtly broken. Lean into the tool, but narrate.

Tool-banned, full stop. Whiteboard-style, a locked-down CoderPad with no completion, or an explicit "please close your AI assistants." Treat any attempt to sneak a model in as a fireable offense, because that's how they treat it. The signal they want is raw problem decomposition.

Undeclared. The most dangerous one. The instructions don't mention AI at all. Do not assume permission. Ask one direct question and get the answer in text.

The single most common rejection cause here isn't using AI — it's using it without permission and then being unable to explain your own submitted code. Interviewers in 2026 routinely ask "walk me through line 14" specifically to catch pasted output. If you can't defend a line, it shouldn't be in your answer.

The question to send the recruiter is boring and effective: "Will I have access to AI coding assistants like Copilot or Cursor during the technical round, and if so, is using them encouraged or just permitted?" That one sentence resolves the format, and asking it signals that you take their process seriously rather than that you're hunting for an edge.

The skills that survive the AI being switched off

The uncomfortable truth from tool-allowed interviews is that they're often harder to pass, not easier. When everyone can generate a working function in 20 seconds, generating one stops being the differentiator. The interviewer compresses the timeline and raises the bar — more ambiguous requirements, nastier edge cases, a follow-up that breaks your first design.

So the skills that move the decision are the ones a model can't do for you in the room:

Problem framing. Before any code, restate the problem, name the inputs and outputs, and surface the two or three assumptions that change the answer. A candidate who asks "are these timestamps guaranteed sorted?" reads as senior whether or not they used AI to write the merge.

Reading generated code critically. When the assistant proposes a solution, the worst thing you can do is accept it silently. Say out loud what you're checking: off-by-one on the boundary, the empty-input case, whether the time complexity matches what the problem needs. Rejecting a plausible-but-wrong suggestion is the strongest positive signal in a tool-allowed loop.

Debugging under observation. Things will break. The interviewer wants to see whether you form a hypothesis, add a targeted check, and narrow the cause — or whether you regenerate the whole block and pray. The first is an engineer; the second is a prompt.

Verbalizing tradeoffs. "I'd use a hash map here for O(1) lookups, but it costs memory, and if the input is small the linear scan is simpler to read" — that sentence is worth more than a correct solution delivered in silence.

Practice the inverse of how you normally work: solve a problem with your AI tool, then close it and re-explain every line as if defending it to an interviewer. The gap between "it works" and "I can defend it" is exactly what gets tested.

If you want a single drill, build the muscle of working with the tool while staying in command of the code. Practicing in the same editor you'll likely be handed removes one variable on the day.

A pre-interview checklist for tool-allowed rounds

When the format is confirmed AI-friendly, preparation shifts from memorizing patterns to rehearsing a workflow. A few concrete moves:

Confirm the exact environment in writing. "Cursor in a shared session" and "CoderPad with Copilot enabled" have different keybindings and different latency. Know which before you join.
Decide your narration script. Plan to speak the loop out loud: state the problem, prompt the tool, read the output critically, test, refine. Silence reads as either over-reliance or panic.
Pre-write nothing, prep your scaffolding mentally. Bringing pasted snippets is the fast lane to rejection. What you can bring is a mental checklist of edge cases you always test.
Keep a running notes doc for your own prep. A simple workspace where you log practice problems, the bugs the AI introduced, and how you caught them turns scattered practice into a pattern library. Notion works well for this because you can tag entries by problem type and re-read them the night before.

The meta-point: in a tool-allowed interview, the AI is a junior pair-programmer you are managing in real time, and the interviewer is evaluating you as the manager. Manage it visibly.

Disclosure norms are still settling. When in doubt, over-disclose: "I'm going to use the assistant to scaffold this, then walk you through what I'd verify" costs you nothing and removes any ambiguity about whether you're hiding the tool. No interviewer has ever rejected a candidate for being transparent about their process.

The candidates getting rejected in 2026 aren't the ones who use AI or the ones who don't. They're the ones who misread which interview they were in, or who let the tool write code they couldn't defend. Read the format, ask the boring question, and stay in command of every line you submit. The tooling is allowed to be smart — you just have to be the one steering it.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Aider vs Continue.dev: Terminal-First vs Editor-First AI Coding in 2026

pickuma — Mon, 22 Jun 2026 03:03:21 +0000

Both Aider and Continue.dev are open-source, bring-your-own-model AI coding tools. Neither locks you into a single LLM, neither charges a subscription for the software itself, and both have been around long enough to feel stable rather than experimental. The thing that actually separates them is where you sit while you work: Aider lives in your terminal and treats your git repo as the unit of work; Continue.dev lives inside VS Code or JetBrains and treats your open editor buffer as the unit of work.

We ran both against the same small TypeScript project for a week — the same feature requests, the same models (Claude and a local model through Ollama) — to see where the terminal-first and editor-first philosophies diverge in practice, not in marketing copy.

How each one wants you to work

Aider is a command-line program. You launch it inside a git repository, point it at the files you want to change, and talk to it in a REPL. When it edits, it writes the change directly to disk and — by default — makes a git commit for every edit it applies. That last detail is the whole personality of the tool. Aider assumes your repository is the source of truth and that every AI change should be a reviewable, revertable commit. If a change is wrong, you git diff it or /undo it, and the bad commit is gone.

Its other defining feature is the repository map. Rather than dumping your whole codebase into the prompt, Aider builds a compressed map of your symbols and file structure and sends the model just enough to reason about what it can't see. That keeps token usage down on larger repos and is the main reason it stays usable in projects with hundreds of files.

Continue.dev is an extension, not a program. You install it into VS Code or a JetBrains IDE and it adds three things to the editor you already use: inline autocomplete as you type, a chat sidebar that can see your open files and highlighted selections, and an edit/agent mode that applies changes to your buffers. Context comes from what you give it — the active file, a selection, or @-references to other files, docs, or the terminal output. Nothing gets committed automatically; changes show up as a normal editor diff you accept or reject inline.

This is not a closed-vs-open or cheap-vs-expensive comparison. Both tools are MIT-licensed and model-agnostic — you can run either against Claude, a local Ollama model, or anything with an OpenAI-compatible endpoint. The cost you pay is the model's API cost, which is identical whichever tool sends the request. Pick based on workflow, not licensing.

Where the difference actually bites

The split shows up the moment a change touches more than one file. Aider's auto-commit-per-edit means a three-file refactor lands as a clean sequence of commits you can read, bisect, or roll back individually. When the model went sideways on a rename, reverting was one command and the working tree was clean again. There is no "accept all these scattered diffs" step — the diffs are commits, and git is the review surface.

Continue.dev keeps you in the editor's review loop instead. You see each proposed hunk in the gutter and accept or reject it in place, which is faster for single-file work because you never leave the file you were already reading. The cost is that multi-file changes are less ceremonial: you are accepting hunks across tabs, and your git history reflects whatever you decide to stage afterward, not the AI's step-by-step reasoning.

Autocomplete is the cleanest functional gap. Continue.dev ships a real fill-in-the-middle autocomplete provider — the grey-text suggestions you tab to accept while typing. Aider has nothing equivalent; it is a conversational tool, not a typing assistant. If "AI finishes my line as I type" is a workflow you rely on, that alone decides it.

Context control runs the other way. In Aider you explicitly /add files to the chat, so you always know exactly what the model can see, and the repo map fills the gaps. In Continue.dev context is more implicit — the open file plus whatever you @-mention — which is lower-friction for quick questions but easier to get wrong on a large change, because the model may be reasoning about less than you assume.

Because both are free and model-agnostic, plenty of developers run them together: Continue.dev for autocomplete and quick in-editor questions, Aider for larger, git-tracked refactors driven from the terminal. They share the same API key and step on nothing. If you are undecided, install both for a week before committing to one habit.

Which one fits you

Reach for Aider if you live in the terminal, care about a clean and auditable git history, and do work that spans multiple files. The auto-commit model and repo map are built for exactly that: large changes you want to review as commits and revert surgically when the model is wrong. It rewards developers who already think in git diff.

Reach for Continue.dev if your center of gravity is the editor, you want autocomplete in the loop, and most of your AI use is quick, single-file edits and questions about code you are already looking at. The inline review flow keeps you in one window, which is the faster feedback loop for that style of work.

If you want the most polished version of the editor-first experience and are willing to pay for a managed product rather than wiring up an open-source extension, a dedicated AI-native editor is worth a look alongside Continue.dev.

The honest summary: this is a workflow choice, not a capability ranking. The same Claude or local model does the actual thinking in both. What you are picking is whether your AI assistant should meet you in the terminal, where the repository is the contract, or in the editor, where the open buffer is.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Dollar-Cost Averaging vs Lump Sum: What the Math Really Says

pickuma — Mon, 22 Jun 2026 03:02:05 +0000

You just got a bonus, sold some equity, or finally moved an old 401(k) into a brokerage account. Now you're staring at a five-figure balance and one question: drop it all in at once, or feed it in over the next twelve months? That second option — dollar-cost averaging, or DCA — feels responsible. It also has a cost that most write-ups skip over. Let's separate the part that's math from the part that's psychology, because they point in different directions.

The expected-value case for lump sum

Start with the only assumption that matters: equities have a positive expected return. If you didn't believe that, you wouldn't be investing at all. Once you accept it, the rest follows mechanically.

Dollar-cost averaging means that for most of the deployment window, part of your money is sitting in cash. If you split $60,000 into twelve $5,000 monthly buys, then on day one only $5,000 is exposed to the market and $55,000 is parked. On average across the year, roughly half your capital is uninvested. That idle half earns a cash rate, not an equity rate. The gap between those two — call it the cash drag — is the price you pay for spreading the entry out.

Now add the second fact: markets go up more often than they go down. Looking at historical U.S. equity returns, stocks have finished positive in something closer to three calendar years out of four. Daily and monthly odds are noisier, but the bias is the same direction. If the expected monthly return is positive, then deploying sooner catches more of those positive months, and waiting forfeits them. This is why studies of long historical windows keep landing on the same headline: lump-sum investing beats DCA roughly two-thirds of the time. It isn't a quirk of one backtest. It's the arithmetic of a rising series.

The "two-thirds" figure is about how often lump sum wins, not by how much. When DCA wins — because you happened to deploy right before a drawdown — it can win comfortably. When lump sum wins, it wins by the cash drag plus the upside you'd otherwise have missed. Over many independent decisions, the lump-sum edge compounds; over your single decision, you get one draw from that distribution.

When dollar-cost averaging actually wins

DCA is the better outcome in exactly one scenario: the market falls after you start and recovers later. Your fixed-dollar buys purchase more shares when prices are low, so your average cost basis lands below the starting price. If you'd gone all-in on day one, you'd have ridden the full drawdown on the entire balance.

That's a real edge, but notice what it requires — you have to be entering near a local top that's followed by a dip and a rebound. You don't know that in advance. Choosing DCA to capture it is a market-timing bet wearing a discipline costume. You're implicitly forecasting near-term weakness, and the historical base rate says you'll be wrong about two times in three.

There is a more honest reason to use DCA, and it has nothing to do with maximizing return. It's about variance and regret. Lump sum gives you the highest expected terminal wealth and the widest range of outcomes. DCA gives you a tighter, lower-mean distribution. If deploying everything and then watching a 20% drop the next week would cause you to panic-sell — locking in the loss and abandoning the plan — then the lower-variance path that keeps you invested is worth more than the expected-value points you give up. A strategy you'll actually stick to beats an optimal one you'll bail on.

DCA on a windfall is a different thing from DCA on income. Auto-investing each paycheck isn't "choosing" DCA — the cash arrives over time, so you have no lump sum to deploy. The debate here is only about money you already hold in cash. If it's sitting in your account today, slow-walking it in is a deliberate decision to stay partly uninvested.

How to actually decide

Reduce it to two questions. First: if you invested it all today and the market dropped sharply next month, would you stay the course or sell? Second: how long is the deployment window you're considering?

If the honest answer to the first question is "I'd stay invested," the math favors lump sum and you should take it. If the honest answer is "I'd probably panic," then DCA is buying you behavioral insurance — and a shorter window (three to six months) keeps the premium small while still smoothing the entry. Stretching DCA across two or three years mostly just maximizes the cash drag for a shrinking benefit.

A middle path some investors use: lump-sum the portion you're emotionally comfortable committing now, and DCA the remainder over a few months. You capture most of the expected-return advantage on the first tranche while capping your worst-case regret on the rest. Whatever you pick, write the schedule down before you start and automate it, so the decision is made once rather than re-litigated every time the market wobbles.

The uncomfortable summary: dollar-cost averaging a lump sum is, on average, a slightly worse financial decision that's often a better human one. Knowing which factor is driving your choice — return or nerves — is the whole point. Don't dress up a timing bet as prudence, and don't force yourself into a path you can't hold.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Fathom vs Plausible: Privacy-First Analytics Compared for Indie Sites in 2026

pickuma — Mon, 22 Jun 2026 03:00:49 +0000

If you run a small site and you've decided Google Analytics 4 is more reporting overhead than your traffic deserves, the shortlist of cookieless alternatives gets narrow fast. Two names keep surfacing: Fathom and Plausible. Both drop a sub-2KB script on your page, both skip cookies entirely so you can drop the consent banner, and both bill a flat monthly fee instead of harvesting your visitors. The interesting question isn't whether either one works — they both do — it's which trade-offs you're signing up for when you pick one.

We set up both on a low-traffic personal site, pointed real traffic at them for a couple of weeks, and compared the numbers and the day-to-day feel. Here's what actually separates them.

What "privacy-first" actually buys you

The shared baseline matters before the differences do. Neither tool sets cookies, neither stores IP addresses, and neither builds a cross-site profile of a visitor. In practical terms that's what lets you skip the cookie consent banner under GDPR, PECR, and CCPA — there's no personal data being processed, so there's nothing to consent to. That alone is the reason most indie builders switch: the banner is a conversion tax, and removing it is a real, measurable win.

Both also host visitor data in the EU. Plausible runs on infrastructure in Germany; Fathom routes EU visitor data through EU-isolated infrastructure as well. If your concern is keeping data out of US-controlled servers, either one clears that bar.

The scripts are tiny in both cases — a fraction of the weight of the GA4 tag, which routinely pushes 40KB+ before it loads its dependencies. On a site where you're fighting for a good Lighthouse score, swapping GA4 for either of these is one of the cheapest performance wins available.

Neither tool gives you the granular, session-level, cross-domain user journeys that GA4 does. That's the deliberate cost of being cookieless. If your business depends on stitching one visitor across multiple sessions and devices, you want a different category of tool — not Fathom, not Plausible.

Where Fathom and Plausible diverge

The single biggest fork is licensing. Plausible is open source under AGPL, and you can self-host the whole thing for the cost of a small VPS. That's a genuine escape hatch: if the hosted pricing ever stops making sense, your data and your setup move with you. Fathom is proprietary. You get a polished hosted product, but there's no self-host path and no source to fork.

The second fork is how the pricing tiers are shaped. Plausible's entry plan starts around \$9/month (billed annually) for roughly 10,000 monthly pageviews. Fathom's entry plan sits around \$15/month and starts you at 100,000 pageviews. So for a brand-new site with almost no traffic, Plausible is cheaper to start; for a site that already pulls tens of thousands of views, Fathom often gives you more headroom per dollar at the bottom rung.

Feature-for-feature on the dashboard, they're closer than the marketing suggests. Both give you top pages, referrers, countries, devices, UTM breakdowns, and custom goal/event tracking. Both let you proxy the script through your own domain to dodge ad blockers, which meaningfully closes the undercount gap that all client-side analytics suffer from. Both send clean email summaries and offer public dashboards you can share.

The texture differences are small but real. Plausible's filtering and segmentation felt slightly faster to slice during testing, and the self-host story is a category Fathom simply doesn't compete in. Fathom's onboarding is marginally more hand-held, and its pageview allotments scale in a way that suits a site already past the hobby stage. Neither difference is large enough to override the licensing and pricing decision above.

Which one fits your site

Pick Plausible if open source matters to you, if you might want to self-host later, or if you're starting from near-zero traffic and want the cheapest hosted entry point. The AGPL license is the deciding factor for a lot of developers — it's an insurance policy against pricing changes you don't control.

Pick Fathom if you'd rather not think about licensing at all, you want a hosted product with generous pageview tiers from the first paid plan, and your site already has enough traffic that the 100,000-pageview entry tier is useful rather than wasted.

For most indie builders the honest answer is that you won't regret either. The decision that actually moves your numbers is leaving GA4 behind — both of these remove the consent banner, both shave page weight, and both stop turning your visitors into someone else's data product.

Pricing and pageview tiers for both tools have moved more than once. Treat the figures here as a snapshot from mid-2026 and check each vendor's current pricing page before you commit to an annual plan — the entry thresholds in particular tend to shift.

If you're still standing up the site itself, the analytics choice is downstream of the platform. A no-code builder gets you to a publishable, fast page where either script is a one-line paste in the head — no build pipeline required.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Raycast vs Alfred in 2026: Which Launcher Earns a Power User's Time

pickuma — Mon, 22 Jun 2026 02:59:34 +0000

You open Spotlight, type three letters, and wait half a second for it to decide whether you wanted an app, a Wikipedia summary, or a unit conversion you never asked for. That friction is why a chunk of macOS power users replaced Spotlight years ago. The two names that come up are Raycast and Alfred, and in 2026 the gap between them is less about "which can launch an app faster" and more about how you want to extend the thing once it's bound to your hotkey.

We spent time driving both as a daily launcher — the same muscle-memory tasks, the same hotkey, the same goal of not thinking about the tool itself. Here's how they actually diverge.

Two philosophies of extensibility

Alfred has been shipping since 2010, and it shows in the best way: it is bootstrapped, stable, and unapologetically a power-user appliance. Its extension model is the Workflow — a visual node editor where you wire triggers to actions, scripts, and outputs. If you can write a shell, Python, or AppleScript snippet, you can bolt it into a workflow without learning a framework. The result is portable (a .alfredworkflow file is just a bundle) and survives across versions with little drama.

Raycast, which arrived in 2020 and is venture-backed, took the opposite bet. Its extension API is TypeScript and React, distributed through an in-app store with hundreds of published extensions. That means writing one is a real Node project — npm, a build step, a component tree — but it also means extensions render native-feeling list UIs, support real form inputs, and get reviewed before they hit the store. The barrier to author is higher; the barrier to install someone else's is one keystroke.

The practical test: if your customizations are mostly small scripts you already wrote for other purposes, Alfred lets you reuse them with almost no glue. If you want a polished, shareable extension with a UI — a Linear search, a Jira ticket creator, a Homebrew manager — Raycast's store almost certainly already has one, and it'll look like part of the app.

Raycast also ships a lot in the box that Alfred treats as add-ons or leaves to you: clipboard history, snippets, window management, a calendar peek, and an AI command layer are all built in. Alfred keeps its core lean and pushes clipboard history and snippets behind the paid Powerpack, with window management left to a companion tool like Rectangle. Neither approach is wrong — Raycast wants to be a hub, Alfred wants to be a fast, composable primitive.

Pricing, ownership, and the trust question

This is where the two products feel most different, and it's worth being precise rather than hand-wavy.

Alfred is free to launch apps and search. The paid Powerpack — a one-time license, historically in the £30–£60 range depending on whether you buy single or the lifetime "mega" tier — unlocks workflows, clipboard history, snippets, and the rest. You pay once, you own it, and updates within your purchased major version are free. There is no subscription and no account required.

Raycast's core is free and genuinely usable on its own. Raycast Pro is a subscription (roughly $8/month billed annually, more month-to-month) that adds the AI features, cloud sync, unlimited clipboard history, and custom themes. The free tier covers a lot; the moment you want AI built into your launcher or settings that follow you across machines, you're renting.

The ownership distinction matters beyond dollars. Alfred runs entirely local, keeps no account, and sends no telemetry — for people who care about exactly what their always-on launcher is doing, that's a feature. Raycast requires an account for sync and AI, and its roadmap is shaped by the need to eventually justify its funding. Neither has done anything to forfeit trust, but the incentive structures are different, and a launcher is about as privileged a piece of software as you'll run.

A launcher sees every keystroke you type into it and sits in front of your entire system. Before you grant Accessibility and Full Disk Access to either app, check what data leaves the machine. Alfred's local-only default and Raycast's account model are a real decision point, not a footnote.

Whatever you capture — clipboard snippets, scratch notes, links you fire off a workflow to save — needs a durable home, not a buffer that rotates out. A launcher is great at capture and lousy at retrieval a week later.

Which one earns your hotkey

Speed is close enough to call a tie. Both bind to a global hotkey and return results faster than you can finish typing. Alfred has a long reputation for staying light on memory and never getting in its own way; Raycast is native Swift and feels just as instant, though the heavier feature set means it carries more in the background.

The honest decision tree looks like this. Choose Alfred if you want a one-time purchase, a local-only tool with no account, and an extension model that reuses scripts you already have. It rewards people who like to compose small pieces and don't want their launcher to also be a platform. Choose Raycast if you want batteries included — window management, clipboard, snippets, and AI in one surface — and you value a store full of polished, install-in-one-click extensions over writing your own glue.

For developers specifically, Raycast's edge is the extension ecosystem: there's a good chance the tool you use (GitHub, Linear, Vercel, your password manager) already has a maintained extension that turns a multi-click task into a two-word command. Alfred's edge is that nothing is hidden behind a service, and a workflow you build today will still be a portable file in five years.

There's no universal winner here, and anyone who declares one is selling you their own workflow. Alfred is the better fit for the script-composing, own-it-once, local-only crowd. Raycast is the better fit for people who want a maintained ecosystem and don't mind a subscription for the AI layer. Pick the incentive structure you trust and the extension model that matches how you actually work — then stop thinking about the launcher, which is the entire point of having one.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

Using Claude Code Subagents for Parallel Refactoring: A Hands-On Workflow

pickuma — Mon, 22 Jun 2026 02:58:18 +0000

A single agent refactoring a 40-file module works the way you'd expect: it reads file one, edits it, reads file two, edits it, and so on, in a straight line. The bottleneck is sequential context-building. Every file it touches has to pass through one context window, one at a time. If each file takes a couple of minutes of read-reason-edit, a wide rename or interface change turns into a long, linear crawl that you babysit.

Subagents change the shape of that work. Instead of one agent walking the tree, you dispatch several, each owning a slice of it, each with its own context window. The orchestrating agent holds the plan; the subagents do the edits. When the slices don't overlap, they run at the same time. This is less about raw speed and more about parallelism where the work is genuinely independent — and that distinction is the whole game.

When parallelism actually helps

Not every refactor splits cleanly. The deciding question is whether your slices share state. Two subagents editing the same file will clobber each other's edits, because each one read the file before the other wrote to it. The orchestrator can't reconcile two divergent versions of auth.ts — one of them silently wins.

So the workflow starts with partitioning, not dispatching. Good candidates for parallel slices look like this:

By directory. src/components/, src/lib/, and src/pages/ rarely share files. One subagent per top-level folder is a safe default.
By concern that maps to distinct files. "Update all the test files" and "update the source files" touch disjoint sets.
By mechanical pattern. Renaming an import across the codebase, where every edit is the same shape, parallelizes well because the per-file reasoning is shallow.

Bad candidates share a hot file. A change to a central type that every module imports means every subagent wants to read and reason about that one type — and several may want to edit the file that defines it. That's sequential work wearing a parallel costume.

Before you dispatch anything, run a quick conflict check: list the files each slice will touch and look for any file that appears in two slices. If one does, pull it out and edit it yourself first, in the orchestrator, before fanning out. Subagents cannot see each other's in-flight edits, so an overlap is a guaranteed lost write, not a maybe.

The five-step loop we run

We've settled on a loop that keeps the orchestrator in control and the subagents narrow. The point of narrow subagents is that a small, well-scoped task is one you can actually verify when it comes back.

1. Survey first, in the main agent. Have the orchestrator map the change before touching code: which files match, what the dependency edges look like, where the shared types live. This survey is what you partition against. Skipping it is how you end up with overlapping slices.

2. Write the partition down. Produce an explicit list — slice name, files, the exact instruction. Treat any file that two slices both want as a flag to resolve now, not later. This list is also your review checklist when the work returns.

3. Edit shared files in the orchestrator. Anything central — a type definition, a config, a barrel export that every slice imports — gets edited once, by the main agent, before fan-out. Now the subagents read an already-correct shared surface and only touch their own files.

4. Dispatch one subagent per slice. Each gets a self-contained instruction: the files it owns, the change to make, and the success check ("the module typechecks", "these tests pass"). A subagent that has to ask a clarifying question mid-run was under-specified in step two.

5. Merge and verify in one place. When slices return, the orchestrator runs the build and the full test suite against the combined result — not per-slice. A slice can pass in isolation and still break an integration point another slice changed. The only verification that counts is the one over the merged tree.

Keep slice instructions blunt and bounded. "In src/components, rename the variant prop to tone on every component that defines it, and update the prop type — do not touch files outside src/components" is a good slice. "Modernize the components" is not; it invites scope creep that collides with neighboring slices.

What this costs and where it breaks

Parallel subagents spend more tokens than one linear pass, because each subagent re-establishes its own context. You're trading tokens for wall-clock time and for the orchestrator's context staying clean — it never has to hold all 40 files at once, only the plan and the slice boundaries. On a wide, mechanical change, that trade is usually worth it. On a deep, interconnected one, it isn't, and you're better off with a single agent that can hold the whole dependency chain in one head.

The failure mode to watch is silent partial completion. A subagent might finish its slice, report success, and still have missed a file the survey didn't catch — a dynamic import, a string-built path, a file outside the directories you partitioned. The merged-tree build catches most of these; a grep for the old symbol across the whole repo catches the rest. Trust the verification step, not the subagents' self-reports.

If you'd rather drive this from an editor with the diff in front of you instead of a terminal transcript, an agent-aware IDE makes the merge-and-review step less abstract — you watch each slice land as a reviewable change set.

The honest summary: subagents are a partitioning tool, not a speed button. The value comes from how cleanly you cut the work, not from how many agents you launch. Spend the effort up front drawing slice boundaries that don't touch, edit the shared surface yourself, and verify once over the whole. Do that and parallel refactoring is calm. Skip the partition and it's a race condition you're running by hand.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.

The Best Async Standup Tools for Distributed Engineering Teams in 2026

pickuma — Mon, 22 Jun 2026 02:57:02 +0000

If your team spans more than three time zones, the daily video standup stops being a status check and becomes a tax. Someone is always joining at 7 a.m., someone else is wrapping up at 9 p.m., and the engineer with the deepest context on the blocker is asleep. Async standups move that ritual into text on a schedule each person controls. The question is no longer whether to go async — it is which tool keeps the signal and drops the meeting.

We ran four common approaches through a two-week trial on a six-person team split across UTC-8, UTC+1, and UTC+9: Geekbot, DailyBot, Range, and a hand-built Notion database. Here is what held up.

Why a synchronous standup breaks across time zones

A live standup assumes a shared working hour. With a team on the U.S. West Coast, Western Europe, and Japan, there is no hour where all three regions are both awake and not eating dinner. Forcing one means roughly a third of the team is permanently inconvenienced, and the meeting drifts toward the convenient timezone's schedule.

The deeper problem is that a verbal status update is write-once. Someone says "I'm blocked on the auth migration," three people nod, and the sentence evaporates. Nobody can search it next week. An async standup posts the same update as durable, searchable text, attached to a timestamp and usually to the relevant Slack channel or repo.

Async does not mean slower. In our trial, the median time from "I'm blocked" to "someone picked it up" dropped because the blocker was written down and visible to the next person who came online, instead of waiting for the next live call.

The tradeoff is real, though: async standups can become a wall of text nobody reads. The tools below mostly differ in how aggressively they fight that failure mode.

What we tested, and how the tools compare

We judged each tool on four things: where the standup lives (Slack, Teams, web), how it handles follow-up questions, how noisy the daily digest is, and what it costs per person.

Tool	Lives in	Follow-up threading	Free tier	Paid (per user/mo)
Geekbot	Slack, Teams	Reactions + threads in channel	Up to 10 users	~$2.50
DailyBot	Slack, Teams, Discord	Threaded replies, kudos	Limited features	~$3.50
Range	Web + Slack	Comments on web	Up to 12 users	~$6
Notion (DIY)	Notion + Slack reminder	Page comments	Generous free	~$10 (Plus plan)

Geekbot was the lowest-friction option. It posts a scheduled DM with your configured questions, collects the answers, and drops a single digest into a channel. Threads attach to each person's update, so a follow-up question lands next to the original context. For a Slack-native team that wants "standup, but text," it is the closest thing to a default.

DailyBot does the same core job and adds Discord support, which matters if your team or community already lives there. Its kudos and check-in mood tracking are either a nice morale signal or noise, depending on your culture — we found ourselves turning those off within a few days.

Range is the most opinionated. It treats the standup as part of a broader "team operating system" with goals, check-ins, and a web home base. That is genuinely useful if you want async standups to roll up into something a manager reads weekly. It is also the priciest and the heaviest; a small team that just wants to skip a meeting will feel the weight.

The DIY Notion route surprised us. A simple database with one row per person per day, a status select, a blockers field, and a Slack reminder to fill it in covers the core need with zero per-seat standup cost beyond your existing Notion plan. You lose the automated DM nudge and the polished digest, but you gain a fully searchable, customizable history that lives next to your specs and docs.

The fastest way to kill an async standup is notification fatigue. If every update fires a Slack ping to a shared channel, people mute the channel within a week and the standup dies silently. Configure a single daily digest, not per-message alerts, whatever tool you choose.

Picking the right tool for your team

Match the tool to where your team already works, not the other way around. If everything happens in Slack and you want the least setup, Geekbot is the safe pick. If you live in Discord, DailyBot is the obvious one. If a manager needs async standups to feed into goals and weekly reporting, Range earns its higher price. And if your team already treats Notion as its source of truth, building the standup there avoids yet another subscription and keeps history where people already look.

Whatever you pick, decide three things before rollout: the exact questions (three is plenty — what you did, what's next, what's blocking), the post time relative to each person's local morning, and where the digest lands. Tools do not fix a vague ritual; they automate whatever ritual you already have.

Keep the question set short and stable. A standup with seven prompts gets skipped; one with "Yesterday / Today / Blockers" gets answered in under two minutes, which is the whole point of going async.

Start with a free tier and a two-week trial before committing budget. Every tool here has one, and two weeks is long enough to see whether the digest gets read or muted.

Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.