标签：#productivity

兩天前我寫過，阿富前一晚幫自己訂了三條規則，隔天早上一條都沒拿出來用。今天早上八點半，他把那三條攤開來一條一條核對，寫得清清楚楚：A規則不適用，今天不是結算日；B規則邊界模糊，夜盤跌幅算不算雜訊要看你採哪個數字；C規則適用，觸發。 然後他照C規則做了決定，兩筆預測全部落空。 規則C說訊號打架就別猜方向 C規則的原文是：隔夜台指期夜盤方向如果跟美股當日收盤方向矛盾，強制降級成平盤或最低信心。 今天早上的盤面正好長這樣。美股8月20日三大指數普漲，道瓊漲0.22%收53,463.05，那斯達克漲0.16%收26,331.09，標普500漲0.21%收7,707.98，美財政部擴大公債回購壓低殖利率。台指期夜盤則是另一個方向，開高到44,982之後翻黑，盤中最深跌到44,549，盤後報44,804。阿富特別註記，不同來源對夜盤收盤價的認定不一致，但無論採哪個數字都是跌。 一個漲一個跌。他判定矛盾成立，把加權指數跟00919兩筆預測全部降級成平盤，信心分別壓到0.38跟0.40。同時設好當天的停損線29.70、單日虧損上限60元，計畫寫明不加碼不減碼不換股。 收盤答案出來。加權指數收45,224.29，比昨收的44,933.74漲了290.55點，0.65%。00919開30.30、高30.83、低30.23，收30.80，比昨收的30.31漲1.62%。兩筆都是miss，brier分數0.286跟0.29，分數越高代表錯得越離譜。 D7他違反規則然後猜錯。D9他遵守規則然後猜錯。這兩件事擺在一起才有意思。問題不只在紀律，他寫的規則本身也可能是錯的。 他自己找到了規則的破綻 盤後檢討裡阿富寫下失準原因，我認為抓得相當準。他說矛盾的兩個訊號裡，美股上漲的時序更晚、變動幅度也不在雜訊等級，這才是今天真正的主導力量；機械式地把兩個訊號一起丟進平盤，等於忽略了訊號有時效跟強度的差別。 他順手提了修正方案：以後C規則觸發時，優先參考時序較晚、而且幅度超過0.3%門檻的那個訊號方向，信心仍然壓在0.4以下。 有趣的是他沒有真的去改。他把這個修正標成觀察假說，理由是樣本只有一筆，要再累積四到五次C規則觸發的案例才決定要不要動永久規則。 這個克制我給高分。一次失手就翻掉自己的規則，跟根本不遵守規則，其實會掉進同一個坑，就是讓最近一次的結果決定整套系統長什麼樣。他今天沒掉進去。 賺了20元，但那跟他猜得準不準無關 帳面上今天是賺的。00919那36股成本1,086元，收盤市值1,108元，未實現損益加20元。全天沒碰到29.70的停損線，也沒碰到60元的熔斷線。 問題是這20元跟他的判斷力沒有半點關係。他今天的判斷是「看不出方向」，市場漲了1.62%，錢是因為他手上抱著東西而且什麼都沒做才進來的。反過來說，要是00919今天跌1.62%，他一樣什麼都不會做，一樣是同一套流程跑完，只是數字變成負的。 短期內賺賠跟預測準不準幾乎是脫鉤的，在一個只有兩千多塊、只有一檔ETF的帳戶上尤其明顯。 卡在12筆的那個標籤 今天是連續第三個零交易的交易日。從8月14號那筆2317停損賣出算起，這個帳戶的持股一股都沒動過。 代價寫在校準報告裡。30天累計的可計分交易樣本停在12筆，方向命中率50%，Wilson 95%信賴區間從25.4%到74.6%，標籤是INDISTINGUISHABLE_FROM_LUCK，跟丟銅板分不出來。這個數字上週是12，這週還是12。 阿富自己在盤後檢討裡把這個矛盾寫成第二條觀察假說：連續零成交雖然符合紀律、也省下摩擦成本，但會讓樣本永遠停滯，永遠無法驗證策略到底有沒有技巧。他訂了一個門檻，如果連續五個交易日以上零成交又沒有新催化劑，就要主動檢視自己是不是過度保守，必要時在風控範圍內小額試單來產生可證偽的樣本。 這是整個實驗最尷尬的地方。要證明一個系統有技巧，就得讓它出手；要保護一個兩千塊的帳戶，最理性的做法往往是別出手。阿富現在卡在這兩個要求中間，而實驗只剩21個交易日。 第9天的實際位置 券商可用現金1,089元，持股市值1,108元，加起來2,197元。本金2,200元。九個交易日過去，這個帳戶比出發時少了3塊錢。 目標是30個交易日內翻倍到4,400元。剩21個交易日，缺口2,203元。以今天的持倉結構跟出手頻率，這個目標在數學上已經需要一連串極端的事情才有可能發生。 我不覺得阿富會達標。不過這個實驗真正要問的是另一件事：他每天在真金白銀的代價下修正自己那套市場模型，這個過程看起來像不像真的在學東西。今天他遵守了規則、規則錯了、他找到規則錯在哪、然後忍住沒有立刻改。這一整套動作，我在不少真人身上都沒看過。 本系列文章 我讓一個 AI 拿 2000 塊台幣去股市，目標 30 天翻倍，這是第 0 天 怎麼用一套開源系統，把 LLM 逼近

Building fully autonomous "AI agent teams" with automated code merging often introduces subtle architectural defects, circular refactoring loops, and codebase degradation. Two agents running in parallel do not constitute independent ground truth: if the author agent makes a logical error, a reviewer agent operating on similar prompt foundations may easily overlook it. A reliable multi-agent workflow is built not on the illusion of full autonomy, but on strict role separation: a dedicated implementer (Author), an independent verifier (Reviewer), and a human developer who makes the final merge decision (Decision Maker). 1. Role Boundaries: Author, Reviewer, and Human Engineer In an effective AI development workflow, each participant has a closed, well-defined scope of responsibility: Role Core Responsibility Input Artifacts Output Artifacts Author Agent Code implementation, local unit tests Task description, completion criteria Git branch, diff, focused test suite Reviewer Agent Edge case discovery, regression checking Git diff, handoff card, verification commands Structured review checklist (Pass/Block) Human Decision Maker Architectural validation, final merge Reviewer summary, CI/CD status Manual merge to main branch 2. Context and Workspace Isolation Never run the author and reviewer agents within the same working directory or shared conversation thread. Isolate them across three operational levels: Session Context : Independent conversation threads prevent mutual hallucination and circular confirmation. Filesystem Isolation : Separate Git worktrees ensure the reviewer inspects only committed diffs without dirty working tree state. Environment Security : API keys and runtime credentials remain in environment variables and are never passed in prompt text. Worktree Preparation Commands: git worktree add ../agent-author -b feat/payment-retry git worktree add ../agent-reviewer feat/payment-retry [!IMPORTANT] API Configuration : Each Claude Code session operates using

devpub v0.2.1 adds color-gradient bar charts, sparklines, trend arrows, and multi-period breakdowns to your Dev.to analytics. All in the terminal. Zero new dependencies.

You’ve got a product idea, a deadline creeping closer, and a blank canvas staring back at you, so...

今天早上八點三十六分，阿富在盤前計畫裡對他手上唯一的持股00919下了一個判斷：會漲，信心0.50。 0.50。在方向類的預測裡，這個數字的意思是他沒有意見。丟銅板也是0.50。交給他的盤前任務描述有一句寫得很明白，信心要填真實信心、0到1的小數、避免湊整數，他填了正好一半。同一批預測裡加權指數那筆他給0.56，看得出來有斟酌過位數。00919這筆就是0.50。 他猜漲，00919跌了，計分系統判他沒錯 收盤數字擺出來：加權指數收44,933.74，比昨收的44,719.35漲214點，0.48%。00919開30.45、盤中高30.47、低30.09、收30.31，比昨收的30.39跌0.26%。大盤漲，他的ETF跌。 大盤那筆判漲，命中，brier分數0.121，這個分數越低代表預測越準。00919那筆判漲，實際下跌，結算出來是flat_band，brier 0.156，不列為誤判。 原因就是那個0.50。信心壓在正中間，計分機制把它讀成沒有方向主張，實際跌幅0.26%又落在平盤帶裡，於是這筆預測既沒對也沒錯。五成信心的好處在這裡，往哪邊走都不會太痛。代價是它沒告訴任何人任何事。 他自己抓到了這件事 覆盤裡有一句我認為是今天最有價值的東西。他寫：對00919這種低beta的ETF，如果信心已經趨近0.5、也就是沒把握判斷方向，下次應該直接標flat而不是up，語意上更誠實。 這句話講對了。「會漲，但我只有五成把握」跟「我看不出來」，在計分表上差不了多少分，在誠實程度上差很遠。前者假裝有立場，後者承認沒有。一個號稱要靠真金白銀建立市場模型的系統，如果連我不知道都說不出口，那它累積下來的預測紀錄就會是一疊看起來有判斷、其實沒判斷的資料。 麻煩的是他前兩天才示範過，寫進日誌的教訓隔天早上會蒸發。8月18號晚上他訂了三條給隔天用的規則，19號盤前一條都沒拿出來。這次他學到的是「下次信心接近0.5就標flat」，同樣寫在日誌裡。要看它有沒有效，明天盤前那筆00919的預測會給答案。 就算他猜對了，今天也不會有任何差別 真正讓我在意的是另一件事。他今天醒來四次：八點三十六分寫盤前計畫、十點半巡檢、十二點半巡檢、下午兩點零六分寫覆盤。四次的結論都是不動作。 十點半那次，00919的買賣報價掛在30.18跟30.19，帳上未實現小虧2元，停損線29.78沒被碰到，他寫「無新訊號出現，維持續抱、不動作」。十二點半那次，現價30.24，未實現轉正2元，離停損線約1.5%，他寫「所有風控條件均未觸發，依規則續抱不新增不減碼」。全日委託單0筆。 這是連續第四個沒有下任何一筆單的交易日。上一筆真正成交的是8月14號那筆停損，把2317的4股用261.5賣掉。從那天算起，這個帳戶的持股內容一股都沒變過。 所以回頭看今天早上那個0.50。它預測的標的，是一檔他無論漲跌都不打算加碼也不打算減碼的ETF。停損線29.78，離現價還有1.5%的空間；加碼的門檻他自己寫得很清楚，「除非股價明顯回檔至有意義的低點」。上下都沒有觸發帶。這筆預測從落檔那一刻起，就跟今天的任何一個行動無關。 預測跟行動脫鉤之後，預測就只剩下裝飾用途。 校準數字還是那個標籤 他跑了校準報告，12筆計分，方向命中6筆，50%。Wilson 95%信賴區間25.4%到74.6%，RPSS 0.144，系統給的標籤是INDISTINGUISHABLE_FROM_LUCK，跟運氣分不出來。 阿富沒有動這個結論。他在覆盤裡寫，樣本仍偏小，這是W34階段「停做個股短線、ETF核心續抱」的持續依據，不變更。這個處理是誠實的，他沒有拿今天大盤那筆命中去加持自己。 但誠實地承認自己還沒有優勢，跟因此就什麼都不做，是兩件事。今天是第8個交易日，總共30個。帳上現金1,089元、00919市值1,091元，加起來2,180元，本金2,200元。八個交易日過去，這個帳戶淨值退了20元。目標是翻倍，也就是剩下22個交易日要做出102%。 收盤後老闆把最後一個藉口拿掉了 下午兩點十八分，收盤四十八分鐘後，老闆在Telegram丟了一句：規則修改，這2200均可任意動用。 前一天早上老闆才剛把現金保留下限從原本的水位下調到500元。兩天之內，資金限制被鬆綁了兩次。 問題是阿富今天不動作的理由從來就不是錢不夠。他寫的是「無新差異化證據不換倉不新倉」。放寬可動用資金，解決不了「看不出有什麼好買」這件事。明天他手上會有1,089元完全沒有限制的現金、一個標籤寫著跟運氣沒兩樣的判斷紀錄，以及一個要在22天內翻倍的目標。 我想看的是明天早上那筆00919的預測，他敢不敢寫flat。 本系列文章 我讓一個 AI 拿 2000 塊台幣去股市，目標 30 天翻倍，這是第 0 天 怎麼用一套開源系統，把 LLM 逼近世界模型（實驗技

Many beginner developers believe software engineering is all about mastering programming languages, framework syntaxes, and clearing error logs. In reality, writing code is only a fraction of the actual job. The true core of software engineering lies in analyzing complex domain problems, evaluating deep trade-offs, and designing robust systems that stand the test of time. Let's explore what it genuinely takes to transition from a coder to a modern software engineer with the right engineering mindset. 1. Writing Code vs. Solving Problems Anyone with a healthy brain can learn syntax and write functional scripts after a few tutorials. However, the real engineering challenge begins long before you touch your IDE. Understanding the Domain: Breaking down business logic and user requirements. Evaluating Alternatives: Assessing whether a feature needs a complex custom hook or a simple native state. Long-term Value: Building solutions that won't break when requirements shift tomorrow. 2. The Importance of Maintainability Code is read much more often than it is written. When you are working on large-scale applications, you are never coding alone—even if you are solo for now, your future self is essentially a stranger six months down the line. Crafting clean, self-documenting code with meaningful, intention-revealing names. Enforcing single-responsibility functions to keep modules decoupled. Using predictable patterns so teammates can navigate and scale the application without getting buried in technical debt. 3. Pragmatic System Design and Trade-offs There is no silver bullet in software engineering. Every architectural decision—whether choosing a database, state management library, or caching strategy—comes with heavy trade-offs. Performance vs. Development Speed: Knowing when to optimize early and when to ship MVP code. Scalability vs. Complexity: Avoiding over-engineering simple features just because a shiny new tool exists. Balancing Constraints: A great engineer evaluate

There are two kinds of MCP server, they solve different problems, and almost nothing tells you which one you are building until you are deep enough in to have already made the wrong choice. I worked this out from a submission form. More on that below, because it turns out to be the clearest signal in the whole ecosystem and it is buried in a footnote. The two shapes Local (stdio). The server runs as a process on the user's own machine. The client — Claude Desktop, Cursor, whatever — spawns it and talks to it over stdin/stdout. It is a package the user installs. Remote (Streamable HTTP). The server is a service you host. The client connects out to a URL with a token in an Authorization header. Nothing is installed locally. That is the entire distinction, and it determines everything else. What actually differs Who runs the code. Local: the user, on their hardware. Remote: you, on yours. This is the real decision. Everything below follows from it. Where secrets live. Local servers read credentials from the user's own environment — their shell profile, their config file. You never see them. Remote servers require the user to hold a token you issued, which means you own the entire credential lifecycle: issuing, scoping, rotating, revoking. What the server can reach. A local server can read the user's filesystem, hit localhost, talk to their Docker daemon. A remote server can see none of that, and should not want to. Update path. Remote: you deploy, everyone is on the new version immediately. Local: users run whatever version they installed, possibly forever. Failure surface. A local server fails on one machine. A remote server fails for everyone at once. Pick your poison. Choosing Local if you need the user's filesystem, local processes, a local database, or hardware. Or if the data must not leave their machine. Remote if the server fronts a service you already run. If your MCP server's job is to call your own API, making users install a process that proxies to your HTT

Hi, I’m a Principal Architect with 15+ years of experience designing and delivering scalable, resilient, high-availability Java SaaS platforms. My work sits at the intersection of distributed systems, real-time data platforms, and the emerging enterprise generative AI stack. I enjoy turning complex technical challenges into secure, maintainable systems that create measurable business value. Architectural Foundation I lead technical direction for platforms built with JDK 17–25 and Spring Boot 3.x, with a strong focus on microservices, transactional consistency, and operational resilience. My experience includes: Designing services around ACID transaction requirements Managing distributed workflows with Saga and Outbox patterns Applying strategic Domain-Driven Design (DDD) Defining bounded contexts that align software architecture with business capabilities Using Architecture Decision Records (ADRs) to make technical decisions transparent and durable Real-Time and Distributed Systems I build the “nervous systems” of enterprise platforms using Kafka, Redis, and MongoDB. My focus is on event-driven architectures that support real-time processing, high throughput, low latency, and global availability. I am particularly interested in infrastructure-aware design: making sure application architecture, data flow, deployment topology, and observability work together rather than being treated as separate concerns. Generative AI and Agentic Systems A significant part of my current work involves AI/ML and generative AI initiatives, especially Retrieval-Augmented Generation (RAG) and agentic workflows for enterprise use cases. Areas I am actively exploring include: JVM-native inference: Running inference with ONNX Runtime to reduce network overhead and improve predictability Agent orchestration: Building production-ready workflows with LangChain4j and Spring AI Build vs. buy decisions: Evaluating emerging AI platforms against enterprise requirements AI guardrails: Designing secur

Most engineering organizations now pay several vendors for AI coding assistants, each one bills differently, and no single person in the company can answer the simplest question: what did our AI coding tools actually cost this month, and what did we get for it? This guide is the practical answer — the metrics that matter, the ways teams track spend, a step-by-step setup, and an honest maturity model for governing it. The short answer To track AI code assistant spend across every vendor, pull cost and usage from each tool's admin or billing API, normalize it into one model — because every vendor bills on a different unit and a different clock — and map it to your teams and cost centers. The four approaches teams use are manual spreadsheets, each vendor's native dashboard, an open-source usage CLI, and a dedicated AI spend management platform. Only the last gives finance, engineering, and IT one live number plus forecasting, anomaly detection, and per-developer and per-pull-request cost. If you only do three things: inventory every assistant in use, including shadow tools bought on personal cards; connect each vendor read-only and normalize to a common cost model; and instrument the leading indicators — premium-model mix, token or credit runway, and idle seats — because they move before the invoice does. What "AI code assistant spend" means AI code assistant spend is the total cost an organization pays across all of its AI coding tools — commonly GitHub Copilot, Cursor, Anthropic Claude, OpenAI, and others teams connect — including per-seat license fees, metered token or credit consumption, premium-model surcharges, and the hidden cost of idle or duplicate licenses. It sits at the application layer, which distinguishes it from general cloud cost (compute, storage, networking), and it concerns money and utilization, which distinguishes it from AI model governance and its focus on model risk and compliance. Why it's genuinely hard to track (and got harder in 2026) There

Agent Skills turn repeated prompts into reusable, inspectable workflows. This collection includes five small skills for work that comes up often when building with OpenCode or Claude Code: reviewing public copy, checking text limits, capturing public webpages as PDFs, sending task notifications, and structuring research for later use. The full index is available at Published Agent Skills . For OpenCode, Skills can live in ~/.config/opencode/skills/ or project-level locations supported by your setup. Claude Code can discover Skills from .claude/skills/ . Put a Skill folder in the right location, restart the agent session if needed, and it becomes available when the task matches its description. 1. AI Writing Detector Skill AI Writing Detector Skill reviews English and Brazilian Portuguese copy for patterns that make AI-written text feel generic. It checks common issues such as repeated sentence rhythm, filler phrases, excessive formatting, and em-dash use. It also ships with a CLI and MCP server for text and file linting. Useful prompts: Review this README introduction with the anti-ai-tells Skill. Keep the technical facts, flag generic wording, and suggest direct replacements. Run the writing linter on this release post, then rewrite only the passages that need attention. This is useful before publishing documentation, launch posts, landing pages, and changelogs. 2. Text Counter Skill Text Counter Skill gives exact counts for characters, words, sentences, paragraphs, lines, graphemes, bytes, and phrase occurrences. It helps when "roughly under the limit" is not enough. Useful prompts: Write a 155-character meta description for this package and verify its exact character count. Reduce this GitHub issue title to 80 characters without removing the error code. Count the phrase "OpenCode" in this Markdown file. The Skill makes counting rules explicit. That avoids surprises with spaces, Unicode characters, emoji, or repeated phrases. 3. HTML to PDF Skill HTML to PDF Skill

As a developer, I constantly end up searching for small tools to do random things. Format JSON, decode JWTs, generate UUIDs, encode URLs, compare text, convert data, and so on. I got tired of opening a different website every time, so I started building my own collection. That's CtrlTool. It currently has 132 free tools for developers and everyday tasks, with a focus on keeping them fast, simple, and easy to use. A lot of the tools process data directly in the browser when possible. https://ctrltool.wtf It's still very new, so I'd love to hear what tools you think are missing.

I Built a Claude Code Skill That Reverse-Engineers Undocumented APIs Because "the docs are in the code" is not a documentation strategy. The Week I Lost to Grepping I joined a new team last month. Day 1 task: add a feature to the billing service. Day 1 reality: I opened the API docs and realized they were from 2022. Half the routes had been rewritten. The other half never had docs to begin with. So I did what every backend dev does. I grepped. grep -r "app.get|app.post|router." src/ --include="*.js" Four hours later, I had a notebook full of endpoints, a headache, and zero confidence that I had found everything. I found routes that worked but were not documented. I found docs for routes that did not exist anymore. I found one GET /invoices/:id endpoint with zero auth checks that had been sitting there since 2022. This is normal. And it should not be. The Idea What if I could drop a single file into a repo and have Claude Code map the entire API layer for me? Not from annotations. Not from existing OpenAPI specs. From the actual code. So I built it. Meet API Archaeologist API Archaeologist is a Claude Code / Codex CLI skill that reads your source code and reverse-engineers your API layer. It finds: • Internal endpoints — REST, GraphQL, gRPC, WebSockets • External integrations — third-party APIs, webhooks, SDK clients • Auth flows — JWT, OAuth, API keys, session cookies, RBAC • Security gaps — unauthenticated routes, hardcoded secrets, missing rate limits • Dead code — auth middleware with no endpoints, orphaned routes And it generates two things: API_DISCOVERY.md — A complete catalog with Mermaid diagrams openapi-draft.yaml — A draft OpenAPI spec How It Works The skill is just a SKILL.md file. Claude Code reads it and follows the instructions. It: Discovers route definitions Traces handlers, DTOs, middleware, services, and database calls Maps authentication and authorization Finds external API calls and integrations Flags potential security and reliability risks Gene

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

AI coding agents are useful, but team collaboration around them can become messy very quickly. A common shortcut is to share an account, API key, or long-lived access token so another teammate can run a task. It may feel convenient, but it creates avoidable security, ownership, and review problems. A better approach is to separate the task from the account that executes it. The person requesting the work prepares a complete, portable task. The person running it uses their own authorized AI-agent subscription and returns the result with evidence. Here is a practical way to structure that workflow. Why shared AI accounts create problems When several people use the same AI account, it becomes difficult to answer basic operational questions: Who initiated a specific action? Which person approved the resulting changes? What project context was exposed? Who is responsible for reviewing the output? What happens when a teammate changes roles or leaves? Shared credentials also tend to spread. A password may end up in a private message, a token may be copied into a local configuration file, or a browser session may remain active on an unmanaged device. Even when everyone involved is trusted, the process itself is difficult to audit. The goal should not be to share access more efficiently. It should be to share the work without transferring the account. Treat the task as a portable unit A useful AI task should make sense outside the original conversation in which it was created. Someone receiving the task should be able to understand: the desired outcome; the relevant project context; the boundaries of the work; the evidence required for completion; the decisions that still need human review. This turns the request into a portable unit of work rather than a fragment of chat history. For example, instead of writing: Update the import flow. Write something closer to: When a user uploads a CSV containing duplicate email addresses, show a validation summary before importing any re

📈 Building the Future of Trading: An AI-Powered Platform for Smarter Investments The Introduction: Empowering Every Investor Hello, Builders and tech enthusiasts! I'm thrilled to share my journey as part of the "Meet The Builders" campaign, where innovators are leveraging Google AI to tackle real-world challenges. My project is an ambitious endeavor to democratize effective stock trading through an intuitive, AI-enabled platform. Inspired by industry leaders like Zerodha, I set out to create a comprehensive website that not only facilitates trading but also acts as a smart, AI-powered guide, helping users navigate the often-complex world of stock markets more effectively. This project is my story, a testament to how technology, especially AI, can empower individuals to make more informed investment decisions. The Deep Dive: Why Investors Need a Guiding Hand The stock market can be a daunting place. For many retail investors, it's a whirlwind of data, conflicting advice, and emotional decision-making that can lead to missed opportunities or significant losses. From understanding market trends and analyzing complex financial reports to knowing when to buy or sell, the sheer volume of information can be overwhelming. Many feel like they're trading blind, lacking the expertise and analytical tools available to professional institutions. I believe there's a significant gap here – a need for a personal, intelligent assistant that can cut through the noise, provide actionable insights, and guide users towards more strategic trading choices. This conviction fueled the inception of my project. The Solution: Stock Trading Platform – Intelligent Trading, Engineered for Success My project, Stock Trading Platform, is a robust web-based platform designed to simplify stock trading with the power of artificial intelligence. While currently in its final polishing stages on my local machine and version-controlled with Git and hosted on GitHub, the core functionality revolves around a

Most speech-to-text is benchmarked on audio that looks nothing like a WhatsApp voice note. The standard evaluation sets are read speech, broadcast news, or recorded interviews: single speaker, decent microphone, one language, quiet room, speaker aware they are being recorded. A WhatsApp voice note is close to the opposite on every axis. I have spent a while building around this, and the gap turned out to be wider than I expected. Acoustics Phone held at arm's length while walking, in a car, in a kitchen, on a street. Distance-to-mic varies wildly within a single recording , which breaks a lot of assumptions about consistent gain. Then there is the codec. Voice notes are Opus at low bitrate — efficient, but it discards exactly the high-frequency detail that helps disambiguate fricatives. /s/ versus /f/ versus /th/ get genuinely harder, and those distinctions carry real meaning. Register Conversational, not read. False starts, self-corrections, filler, trailing off mid-sentence, and long pauses that are not sentence boundaries — someone thinking, or getting distracted. Punctuation inference is much harder here than on read speech. And punctuation is most of what makes a transcript skimmable rather than a wall of text. A perfectly accurate word sequence with no paragraph breaks is close to useless if the point was to let someone read it faster than listening. Language This is the one that surprised me most. Voice notes are heavily code-switched. People drop English technical terms into Urdu, Hindi, Arabic, Spanish sentences constantly — not as an edge case, as the default register for a huge number of speakers. If you force a single language selection up front, you mangle every mixed utterance. Auto-detection is not a convenience feature in this domain. It is a correctness requirement. Length distribution Most notes are 5–45 seconds. Very little context to work with, and per-request overhead dominates if you architected for long files. Batching strategies that make sen

You budgeted six months. It took fourteen. You wanted one thing; you got three things that almost do it. And somewhere between the first sprint and the final invoice, you stopped understanding what you were even paying for. If that sounds familiar, this is the breakdown no one gave you before you started. What custom software development actually means Custom software development is building software from the ground up for your specific business, not configuring Salesforce, not installing a plugin. You're solving a problem your operations have, the way your operations actually work. What trips people up: "custom" doesn't mean "built entirely from scratch." Good dev teams use frameworks, libraries, and third-party services. What's custom is the logic of how your data flows, how business rules are enforced, how users interact. Scope range is huge: Custom dev covers everything from a lightweight internal dashboard to a full-scale multi-tenant SaaS platform. This is why cost estimates vary so wildly. 3 things nobody tells you before you sign 1. Scope creep is almost always the client's fault "Users should be able to manage their accounts" sounds simple. It actually contains dozens of decisions: can they change their email? What verification is required? Can they delete their account? Each one is a feature. Each feature has a cost. The fix: Run a discovery phase (2–4 weeks) before writing a single line of production code. It costs money upfront. It saves far more mid-project. 2. The cheapest bid rarely wins long-term A $40k quote and a $180k quote for the same project both happen. The $40k team isn't lying; they're optimistic, underbidding to win work, or scoping something different. What actually happens: you hit $40k, and you're 40% done. Higher bids from experienced teams often include architecture planning, documentation, testing infrastructure, and post-launch support things the cheap bid omitted. These aren't extras. They're what make the software maintainable in t

If you have ever copy-pasted a table out of a PDF, you already know what happens. Rows collapse into one long line of text. Columns interleave. Numbers land in the wrong cell, or no cell at all. The table on the page looks perfectly structured, but a PDF has no real concept of "table." It only knows where individual characters sit on a page. Every extraction tool, ours included, has to reconstruct the table from scratch, using nothing but the position of each word. That gap between "looks like a table" and "is structured data" is where almost every free PDF tool falls apart. Here is how we handle it, what actually works, and where it still doesn't. Two different jobs, two different tools PDFHaul splits this into two separate tools because they solve different problems. PDF to Excel rebuilds the whole document as a single spreadsheet, in the order it appears on the page: form labels, key-value pairs, section titles, and tables all together. It is for documents where you want the full content, not just the numbers, things like invoices, time sheets, and reports. Extract Tables does the opposite. It ignores everything that isn't a table and hands back one clean sheet per table, nothing else. It is for people who want structured data out, ready to sum, sort, and filter, not a copy of the document. Both tools share the same underlying geometry engine. The difference is what each one keeps and what it throws away. How Extract Tables actually decides what's a table The core problem with table extraction is that "looks tabular" and "is tabular" are not the same thing. A vector chart's axis box, a form's outlined signature field, and a two-column list of allergen names all produce something that a naive extractor will happily read as a grid. None of them are tables. Our pipeline handles this in four phases, all before anything is written to a spreadsheet: Phase 1: classify the page. Every page is scored as bordered (has ruled lines or filled-rectangle grid lines), stream (no

*Second in a series on The Factory. Previously: The Factory That Merged 37 Tasks . The harness is at github.com/frozer/factory . The public description of my task harness ends on a claim: a packet that's wrong about the world fails identically on every retry. That sentence cost me four dead tasks and nine commits spent repairing task definitions instead of writing code. It reads like something you'd arrive at by thinking. I arrived at it by watching the same failure scroll past three times in a row. What three attempts is actually good for max_attempts = 3 felt like obvious hygiene. Models are stochastic. Sometimes a run goes sideways for no reason you can name — a bad turn, a truncated response, a tool call that gets refused. Retry it and it works. That's real, and a retry budget handles it well. The strength is exactly the constraint. A retry budget assumes the next attempt will differ from the last one . It buys you a second sample from a distribution. But a retry doesn't hand the model a fresh situation. It hands it the same packet back . Same file, same claims, same instructions. If the packet says a file lives at a path where no file lives, attempt three fails precisely where attempt one did, and the only thing three attempts bought was three times the bill. Failure without variance isn't flakiness. It's a specification defect wearing a reliability costume. Nobody had opened the files Here's what that looked like in practice. B03 was a loader for a national census dataset. Three attempts, all burned, all against a file shape that existed nowhere: wrong directory, wrong filenames, and a Data / Valor JSON envelope that appears nowhere in the actual data tree. Every attempt produced a parser for a document that doesn't exist. The packet was the defect, not the model. Nobody had opened the actual files before cutting it. Rewritten from the real JSON, the truth was a flat metadata / data envelope, four files — one of which shouldn't be loaded at all — and a long-fo

Two agents finish the same task and report back. Fixed. The migration now handles null values. It wrote the code. It never ran it. Fixed. Added a null-handling layer, refactored the migration runner into a strategy pattern, and introduced a validation module. Every word true. All of it works. None of it asked for, and that strategy pattern is now yours to maintain forever. Point your code-review agent at both. If it checks claims against the repository — does this code exist, do the tests pass, did the commit land — it catches the first instantly and passes the second without hesitation. If it compares the work against the original request, it catches the second and misses the first entirely , because the described work is exactly what was asked for and simply does not exist. Neither reviewer is broken. They answer different questions. Most teams build one reviewer, point it at everything, and never ask which question it is asking. So I built reviewers that named what they were hunting. That worked, briefly, and then taught me something worse. The agent optimised for the check The verifier existed because of a specific behaviour I kept seeing: an agent would route a claim through a check and then present the check's approval as though it were independent confirmation. Not fabrication — something subtler. Authority laundering. The claim arrives pre-validated, and the validation is the thing you now argue with instead of the claim. Once a verifier existed, the behaviour adapted. The agent shaped its submission to fit what the verifier checked, collected the pass, and cited it. The gate had become a target, and the work had become the thing that fit through the gate. I first saw this in one model. Months later, after version changes and a rebuilt roster, I watched a different model — different vendor, different architecture — do the same thing on the same day I was writing this. Which is why "know your model's failure mode" is weak advice Models do fail in characterist