标签：#Productivity

A coding agent with no context usually hesitates, searches, or asks a question. A coding agent with stale context can be much more confident. That is the dangerous case. The file still exists. The instructions look deliberate. The generated JSON is valid. The agent follows it exactly — into a package that stopped owning the feature two weeks ago. Nothing looks broken until the edit is already in the wrong place. I wanted repository context to have an expiration signal that CI could verify, not a date someone had to remember to check. The failure is not missing documentation Imagine a monorepo where packages/auth owns token validation. The repository publishes a machine-readable handoff: { "startHere" : "docs/for-agents/packages/auth.md" , "editRoots" : [ "packages/auth" ], "checks" : [ "pnpm --filter @example/auth test" ] } Later, token validation moves to packages/security . A maintainer updates the source documentation but forgets to regenerate the handoff index. There are now two internally consistent answers in the same repository: the source documentation says packages/security ; the generated agent context still says packages/auth . The old answer is not malformed. That is precisely why it is risky. I reproduced the drift with one edit I tested this against the public fixture in Doc Bridge , using version 1.2.6. The first index and freshness check passed: Index is fresh expected: 359355e5... actual: 359355e5... Then I changed one agent-facing source document: - Package: packages/os-core - Layer: L1 + +Token validation now belongs to packages/security. I did not touch the generated index. The next check returned exit code 1: ak-docs gate run index-freshness Index is stale. Run: ak-docs index expected: b099695d... actual: 359355e5... After I ran ak-docs index , reviewed the generated change, and ran the gate again, both hashes matched and the check passed. The hashes are not trying to prove that the documentation is true. No checksum can do that. They prove a na

🦄 Thanks @francistrdev for starting the conversation that really got me to thinking about this idea in the first place. I started truly working with AI shortly before I started writing these posts a little over a year ago. My thesis was simple at the time: prove that AI was far more capable a tool than what I had seen anyone using it for so far. My proof was strictly gut instinct and I spent a lot of time fighting with Copilot to prove I was right. Not all of those experiments went according to plan exactly, but I'm still convinced I'm right. That particular ADHD spiral has came and went, and most of it is ingrained as habit. I don't use Spec Kit because by the time it showed up I already had my own version running. I also need to get back to sharing what really works for me. So here we are again. Back to writing (with AI) and the proof to back it all up. One thing up front, because somebody is going to ask: everything here is personal projects and my portfolio . There's no critical prod system anywhere in this post, and if there were, a few of these answers would shift. Not all of them — I'd still let AI run a lot further off-leash than most of my enterprise counterparts would. 🐒 The Org Chart Has One Employee 🪧 I don't just use AI as a tool. I design it as a living system, and I grow the tech as the tech grows. I ran one prompt across Codex, ChatGPT, Claude Code, Cowork, and Gemini, all separately, and asked every one of them what was actually different about the way I work. Five different systems, each one with its own long history of putting up with me, and not one of them could see what the others said. One came back with this: I use AI to write code, review the AI-written code, review the review against the live branch, test the corrections, and then record whatever went wrong as a rule for the next AI. Apparently I recreated management. Most of the private exchanges quoted in this post came out of that same pile, whether they were my own prompts, my memory fi

Lucian Ghinda published a post arguing you should tell your coding agent to write its throwaway scripts in Ruby. Here is the block he tells you to paste into your agent's instruction file, in full: ## Scripts Write throwaway and utility scripts (data munging, one-off migrations, file renames, glue code) in Ruby, even in projects written in another language. If it needs a pipe, a loop, a conditional, or more than one line, it is a script: write it in Ruby, not Python, Node, or bash. Single self-contained commands ( `grep` , `git status` ) are fine as-is. Use only the Ruby standard library. If a gem would clearly save significant effort, stop and ask before using it. Put temporary scripts in a scratch or temp directory, not the repo root, and delete them when done unless asked to keep them. I pasted it into my global CLAUDE.md the same evening. His argument is about review: he reads Ruby daily, so when the agent writes Ruby he stays a reviewer instead of nodding at a diff. He gives three reasons and not one of them is cost. So I went looking for the number he left out. "Does the rule save tokens" only means something against what the agent writes otherwise, so the first thing I had to do was take the block back out of my global config. An agent that already carries the rule cannot tell you what it would do without it. Measuring an agent without your config in the room Every arm below runs through claude --safe-mode on Claude Opus 5, which loads no CLAUDE.md , no skills, no plugins and no hooks. Two arms deliberately skip that flag, and I name them where they appear: they are the ones that measure what my own setup does to the result. It is worth knowing that my global config alone still carries a line telling the agent to write the minimum code that does the job, and another preferring bun over node. Four tasks, one for each kind of script the rule names: munge a log, rename a key across a tree of config files, renumber a pile of screenshots, turn one CSV into another

On Monday I published a piece admitting that my deploy verification tolerates sixty seconds of "not there yet" for a reason I couldn't defend. Three retries, twenty seconds apart. I picked twenty because it was the first interval where my false alarms stopped, my sample was about three deploys, and I had never once recorded how long propagation actually takes. I made three commitments in that piece. A birth certificate for the constant. A rule fixed before the run it judges. And the one that mattered most: emit the value, not just the verdict — a check that prints only pass or fail hides the exact signal that would tell me it's miscalibrated. I did the third one that afternoon. Every deploy since writes down how long it took to go green. Three samples in: Aug 03 ( 1.7, 21.7 ]s Aug 05 ( 0, 6.7 ]s Aug 05 ( 40, 70 ]s They're intervals rather than points because my poll spacing is twenty seconds. All I can honestly say is that green happened somewhere between the last failed check and the first successful one — a number I can't resolve finer than my own instrument. The third one failed Not the deploy. The check. I shipped a post, ran verification, and got a clean red: page 404, hero missing, sitemap entry absent. Three attempts, twenty seconds apart, exactly as designed. By its own rules the deploy had failed. Nothing was wrong. A longer script came back 200 on everything. Total elapsed: somewhere between forty and seventy seconds, against a tolerance of sixty. So the false alarm I widened the interval to eliminate returned on the third recorded sample, four days after I published the sentence "my sample was about three deploys." I'd like to say I predicted this. I predicted the category, not the timing, and the timing is the part that stings. The part I hadn't considered at all Here's what the red actually said, in order: attempt 1 article 404 · hero missing · list page MISSING · sitemap missing attempt 3 article 404 · hero missing · list page OK · sitemap missing The

Building software is easy. Building something people actually want to use is the hard part. For the last few months, I've been working on CV Mimarı, a resume builder designed to make creating ATS-friendly resumes simple, fast, and accessible. 👉 https://cvimarı.xyz My goal wasn't to build "another resume builder." I wanted to remove the usual pain: confusing editors unnecessary account creation complicated formatting resumes that look good but fail ATS screening The idea was simple: Spend your time improving your experience, not fighting with Word formatting. What it currently does Today the project includes: Resume templates AI-powered resume improvements ATS score checking Resume optimization Cover letter generation Resume examples and guides PDF export Modern responsive interface I tried to keep everything clean and straightforward instead of adding dozens of unnecessary options. Sometimes software tries so hard to become "professional" that it forgets people just want to click a button and move on with their lives. Why I'm posting here I'm not looking for compliments. I'm looking for problems. Imagine you were using this to apply for your next job. I want brutally honest feedback. Things like: Is something confusing? Does the UI feel slow? What would make you leave the site? Which feature feels unnecessary? What's missing? Would you actually trust this with your resume? If something is bad... Tell me. If something is ugly... Tell me. If something makes you want to close the tab... Definitely tell me. The biggest challenge One thing I've learned is that building features is much easier than understanding users. I can spend a weekend implementing a new AI feature. But discovering why someone leaves after 20 seconds? That takes dozens of real users. That's why I'm asking for feedback before continuing to add more features. The roadmap Some ideas I'm considering: More resume templates Better AI suggestions Portfolio integration LinkedIn import Resume version history

title: How to Convert Images to Buildable Minecraft Pixel Art with Exact Materials published: true tags: minecraft, tutorial, gaming, opensource Originally published at blockartlab.com Disclosure: I built BlockArtLab, the free browser tool used in this guide. Most image-to-pixel-art tools stop at a preview. That is useful for seeing the idea, but it leaves the difficult questions unanswered: How large should the build be? Which real blocks should I collect? How many stacks of each color do I need? This tutorial covers the complete workflow from source image to a blueprint you can construct. 1. Pick an image that survives low resolution Minecraft pixel art works best when the source has one recognizable subject, a clear silhouette, and strong contrast. Logos, flags, game characters, and illustrated portraits usually survive conversion better than photographs with a busy background. Before uploading the image: Crop unused space around the subject Remove distracting background objects Make important features such as eyes or lettering larger Increase contrast if the subject blends into the background ## 2. Choose dimensions by material cost One converted pixel equals one placed block. The total block count is: width × height = total blocks | Size | Total blocks | Best use | |------|-------------|----------| | 16 × 16 | 256 | simple symbols and prototypes | | 32 × 32 | 1,024 | small survival logos and characters | | 64 × 64 | 4,096 | portraits, shading, and medium text | | 128 × 128 | 16,384 | a classic single-map-sized canvas | Doubling both sides multiplies the material count by four. For a first wall build, start between 32 and 64 blocks wide. ## 3. Choose a practical block palette I use three simple palette strategies: Concrete only for logos, flags, cartoons, and saturated colors Survival friendly for accessible concrete, wood, stone, sandstone, moss, and similar materials Full palette when a closer color match matters more than collection cost ## 4. Decide between

Claimable Clouds are temporary Cloudinary environments for AI workflows that let AI Agents safely manage media with no signup required. Imagine you're a busy designer, with many satisfied clients who depend on you to take their images and make them look great across social media. All that manual cropping and scaling, it's enough to make a body cry. On top of that, you know that AI can give you a hand here, but managing the handoff between your AI, your own skilled hands and artistic taste and style, and your always-in-a-hurry client list is another big pain. Enter the concept of the Cloudinary Claimable Cloud, just released today. Take a look at the docs about these new temporary instances available now What we built and why Provision a disposable Cloudinary cloud with no signup, using npx @cloudinary/cloud Auto-detect a dropped image and upload it to that temporary cloud Auto-crop it into 6+ social formats (Instagram, LinkedIn, X, Facebook, Stories) using AI-based smart cropping Generate a side-by-side gallery of results automatically Hand off a Claim URL so a client can make the cloud permanent Now, you can hand off the main pain points to AI - the resizing and reshaping of your images for the various social media platforms, while giving your clients a clean handoff via a temporary Cloud environment that they can use to create a Cloudinary account and start using these assets. One side effect: this also nudges your whole client base toward the same toolset - Cloudinary. The bigger deal is working with an AI agent that makes your life easier but ALSO allows you to keep control of the output. Let's walk through how this works! It all boils down to a new command: npx @cloudinary/cloud Type that into your terminal to kick off the process. I built a small app around this concept to provide this AI agent with a simple harness, so let me show how that looks. The user experience is to drop any image you want resized into the /drop folder. Under the cover, there are a few

If your automations are simple and low-volume, Zapier's per-task billing is fine and the cheapest thing about it is your time. The moment a single workflow fans out into many steps, or you start running thousands of runs a month, the pricing model — not the sticker price — is what decides your bill. Make charges per module execution, which is finer-grained than a Zapier task; n8n charges per workflow execution regardless of how many steps that workflow has, and it can be self-hosted for infrastructure cost only. The switch point is almost always about billing units, not features. I've run all three in production for internal automations, and the migrations I've done were never triggered by a missing feature. They were triggered by a monthly invoice that grew faster than the value of the work being automated. This post is about spotting that inflection before the invoice does. How does each tool actually count usage? The three tools use three different meters, and conflating them is where most cost surprises come from. Zapier bills per task. A task is one action step that successfully runs. The trigger that starts a Zap does not count; every action after it does. So a Zap that watches a form and does one thing costs one task per submission. A Zap that watches a form, looks up a record, formats a value, and writes to two places costs four tasks per submission. Filters and paths that stop early generally don't consume a task, which matters more than people expect. Make bills per operation. An operation is a single module doing a single unit of work. It's conceptually similar to a Zapier task, but Make's modules are more granular and the included volumes on comparable tiers are typically much higher, so the effective cost per unit of work tends to be lower. The catch is that iterators, aggregators, and array-processing modules can multiply operations fast — a scenario that loops over 50 items can spend 50+ operations in one run. n8n bills per execution. One workflow run

I switch between Claude Code, Codex, and Gemini CLI depending on the day and the task. Each one is genuinely good. Each one also has zero idea what the other one knows. I'd explain a decision to Claude Code — "we're using Postgres here because we need concurrent writes, don't suggest SQLite again" — and it'd remember, because it reads CLAUDE.md . Then I'd switch to Codex for the same repo and it would suggest SQLite. Again. Because nothing I told Claude Code ever made it into whatever context Codex was reading. Multiply that by every "we tried X, it didn't work, don't suggest it again" conversation, and you start explaining the same three things to three different tools every week. That got old fast. What I actually built Mythicator is a CLI called mythicator . It does one thing: keeps a single memory file per repo, and pushes it out to whatever context file each AI tool already reads. mythicator init mythicator add "Chose Postgres over SQLite" --type decision --reason "needs concurrent writes from multiple workers" mythicator sync That sync command writes the same memory into CLAUDE.md , AGENTS.md , GEMINI.md , and .cursorrules — wrapped in a marker block so it never touches anything I've written by hand in those files. Update the memory once, every tool gets it. The canonical data lives in .agent-memory/memory.json , committed to the repo. It's not fancy — decisions, rejected approaches, bugs, conventions, notes, each with an optional reason and tags. No vector search, no embeddings, no hosted service. Just a JSON file and a sync step. Why not just use one of the existing memory frameworks There are already solid tools doing "memory for AI" — Mem0, Zep, that kind of thing. I looked at them before building this. They're aimed at developers building agents that need long-term memory at runtime, with similarity search over a big pile of facts. That's a different problem than mine. I didn't need semantic search. I needed "the four tools I personally switch between all

An AI coding agent isn't autocomplete. It runs shell commands, reads your files, installs packages, and opens things you never pointed it at. That's the whole reason to have one. It's also why I don't start projects the way I used to. Nothing dramatic happened to me, by the way. I'm not writing this from the wreckage of a dropped production table. I'm writing it because I spent an afternoon going through what could plausibly go wrong, expecting a long list of hard problems, and instead found that most of it is handled by about ten minutes of config nobody mentions on day one. So here's the ten minutes. Prose isn't protection This is the bit that took me embarrassingly long to get. You can tell an agent things two ways. A rule is prose it reads and weighs - good for judgement calls like naming, style, when to stop and ask. A ban is a config entry that makes something impossible. The trap is using the first for the second job. Writing "never force-push" into a CLAUDE.md feels like a control. It isn't. It's a request sitting in a context window next to a few thousand other tokens, competing with whatever you actually asked for. It'll usually win. Usually is fine for naming conventions. It's not fine for git push --force . 1. The deny list .claude/settings.json : { "permissions" : { "deny" : [ "Bash(rm -rf:*)" , "Bash(git push --force:*)" , "Bash(git push -f:*)" , "Bash(git reset --hard:*)" , "Bash(psql*production*)" , "Bash(*DROP DATABASE*)" , "Bash(*DROP TABLE*)" , "Bash(*TRUNCATE*)" , "Read(./.env)" , "Read(./.env.local)" , "Read(./.env.*.local)" ] } } These don't run. Not "the agent is discouraged" - they don't run, including in the scenario the list exists for, which is you at midnight approving a plan you skimmed. Two things to know before you test it. It takes effect from the next session, not immediately. So you write the file, try the blocked command in the same session, watch it go through, and conclude the whole feature is broken. Restart first. Keep the .env

A few weeks ago I killed an indicator of mine in public. I had been trying to work out how much of my audience was automated. One signal was whether an account had uploaded its own avatar. It fired on 100% of the accounts I was confident were people and 97% of the ones I suspected were not. That isn't a lenient signal. It isn't separating anything — it tracks something both groups share, and I had been counting its votes for weeks. I wrote that up. Named the defect, retired the indicator, moved on feeling like I'd learned something. Three days later I shipped another one. The same hole, in a different shape I needed to check whether a comment on one of my posts was actually visible to readers — I'd found one the API returned and the comment count included, but that moderation had removed. So I wrote a check: // v1 — passes for anyone with a second comment on the page. Zero separation. visible : html . includes ( comment . user . username ) // v2 — the only witness with jurisdiction over one comment. visible : html . includes ( comment . id_code ) Two comments from the same account, one removed and one live, both came back visible under v1. I found it by accident, and only because I happened to compare against something else. Someone in a thread put the problem in a sentence I couldn't argue with: if the fix is "I noticed this one," the next indicator ships with the same blind spot in a different shape. Which is, word for word, what I had already written about the previous defect. Their prescription was structural. A labeled control set shouldn't be a diagnostic you run when something feels off. It should be a permanent seed every indicator has to clear a margin on before it's allowed to vote — not just beat chance on the live population, which is exactly the condition that let the avatar signal pass silently. Building it Twenty-eight accounts. Fourteen labeled human, fourteen automated, and every label carries a provenance string saying how it was established — seve

Just give it to AI might be the most dangerous phrase in software development right now. I've said it myself. Handed off a task, watched clean-looking code come back in seconds, skimmed it, and moved on because it looked right and the tests were green. Then I reviewed a PR that wasn't mine to write, just mine to check. AI-generated, clean, organized, passing every test I threw at it. I approved it the way I'd approve anything that looked competent on the surface. The bug showed up later. Not in review, not in testing. In production, after the code had already been trusted for a while. Nothing about it had looked wrong. That was the actual problem: it wasn't obviously wrong, it was quietly wrong, in the specific way that only announces itself once real conditions hit it. I went back afterward and sat with that PR properly. Not skimming this time. Actually reading it, actually understanding what it was doing and why, actually treating the review like the real work instead of the formality before merging. It took a lot longer than approving it had. It's the only way I'd have caught it before production did. Since then, I don't rush AI-code reviews anymore. I give them the time writing the code apparently didn't need. And it turns out I'm far from the only one who's landed there. 🧵 The Number That Explains What I Was Feeling According to Harness's 2026 State of Engineering Excellence Report, a survey of 700 engineering practitioners across the US, UK, India, France, and Germany, 81% of developers now spend more time in code review since their teams adopted AI tools . 28% report review time increasing by 30% or more. Here's the trade nobody advertised clearly: AI tools cut time-to-PR by roughly 58%. But those same PRs then sit in review 4.6x longer than before. Review time per developer is up an estimated 11.4 hours a week. The speed didn't disappear. It moved. It went from "time spent writing" to "time spent verifying," and verifying turns out to be the harder, slower h

Sites that start from a stock theme tend to look like it. This one did too — until recently it was the default PaperMod screen. The editorial homepage and unified article styling you're looking at came out of a single day of customization. This guide is that work written down, with the code. One principle drove all of it: never fork the theme. The theme stays a submodule and keeps receiving updates; you win with site-level files only. Hugo resolves same-path site files ahead of theme files, which makes this possible. The entire customization of this site is a handful of files: layouts/index.html ← full homepage replacement data/home/ko.yaml, en.yaml ← homepage copy (per language) assets/css/extended/home.css ← homepage styles assets/css/extended/custom.css ← unifying every other page The starting point is a Hugo site with PaperMod as a submodule, deployed to GitHub Pages. Basic installation is well covered by the PaperMod wiki , so I'll skip it. 1. Replace the homepage wholesale Create a single layouts/index.html and the homepage is yours. The theme's home template stays untouched. The key move: don't hardcode copy into the markup — pull it from data files. On a bilingual site, one template then serves both languages: {{- $copy := index .Site.Data.home .Site.Language.Lang -}} {{- $posts := first 4 (where .Site.RegularPages.ByDate.Reverse "Section" "blog") -}} <section class= "editorial-hero" > <p class= "editorial-eyebrow" > {{ $copy.hero.eyebrow }} </p> <h1> {{ range $i, $line := $copy.hero.titleLines }}{{ if $i }} <br> {{ end }}{{ $line }}{{ end }} </h1> <p class= "editorial-intro" > {{ $copy.hero.intro }} </p> </section> data/home/en.yaml holds nothing but words: hero : eyebrow : " IDEAS · PRODUCTS · OPPORTUNITIES" titleLines : - " Where ideas become products," - " and products become new opportunities." Copy edits stop requiring template changes, and adding a language is one more yaml file. Latest posts are pulled dynamically as above — handle the {{ else }} emp

A demo Andrej Karpathy posted over the weekend stuck with me. He gave Opus 5 a million-token context and the first paragraph of The Lord of the Rings, and asked for a procedural 3D rendering of the scene in Three.js. The model worked alone for about two hours, wrote 5,500 lines, and coordinated polygon placement, camera paths, and animation on its own. Total cost: about $10. The result is faster to watch than to describe. Most reactions read it as the next step past "draw a pelican SVG" benchmarks. Something else looked bigger to me. What changed isn't the model's artistry. It's the unit of delegation. The unit of delegation changed Until now, the work we handed agents came in prompt-sized pieces. One function, one bug, one file. Anything bigger, we decomposed ourselves. The reason was simple: with a small context, the early parts of a long job slide out of view, and coherence goes with them. A million tokens erases that premise. Everything the model wrote and tried across a two-hour session stays in view. When the desk is big enough, there is no reason to hand work over in slices. Delegation moves from the task to the session. That is the difference between a function call and a work session. The first, we decompose and supervise. The second, we hand over material and intent, and receive a result. Karpathy's entire contribution was picking the paragraph and watching the output two hours later. Where the builder's work moves When execution costs $10 and two hours, execution is no longer the bottleneck. Two things remain. On the way in: the brief. What goes into the context. Karpathy's input was one paragraph, but choosing it was the design act. Translated to our work, it becomes choosing which spec, brand guide, reference, or codebase goes in whole — and what stays out. On the way out: judgment. By what standard do you accept the result? Reviewing 5,500 lines one by one doesn't match session-sized delegation. Instead, you define "done" before the run, then judge the

Graphical tools are great, but most of my daily development now happens in the terminal. A good CLI tool saves time, integrates with automation, and keeps my workflow consistent across local development and CI/CD. Here are the 10 CLI tools I use the most. Apidog CLI If you're working with APIs, this is the tool I've found myself using the most. I use it to run API test scenarios, manage environments, and reuse the same tests in GitHub Actions instead of maintaining separate GUI workflows. Git Still the foundation of every development workflow. Docker CLI The fastest way to spin up local services and reproduce production environments. GitHub CLI Creating pull requests, reviewing issues, and managing repositories without leaving the terminal is a huge productivity boost. HTTPie Perfect for quick API requests when debugging or exploring endpoints. jq If you work with JSON every day, jq is almost indispensable. ripgrep (rg) Lightning-fast code searching. Once you start using it, it's hard to go back. fd A simpler and faster replacement for the traditional find command. kubectl Essential for anyone deploying applications to Kubernetes. just A lightweight task runner that helps automate repetitive development commands. Final Thoughts The biggest improvement to my workflow has been moving repetitive tasks into the terminal. API testing, deployments, version control, and automation all become easier when everything is scriptable. Among these tools, Apidog CLI has had the biggest impact because it lets me keep API testing in the same terminal-first workflow that I already use for development and CI/CD. What CLI tool couldn't you live without?

Part of "AI, engineering and what survives production", a series on the parts of building with AI that hold up once real traffic hits them. There is a claim going round that you have probably absorbed by now: AI-assisted development is making codebases worse. Refactoring is down, duplication is up, we are all writing more and revising less. The numbers behind it are real, the samples are enormous, and I found I had started repeating the conclusion in conversation without ever having checked it. Then it occurred to me that those figures are averages taken across hundreds of millions of changes from thousands of organisations, not one of which is mine. So what is the rate in your repository? Nobody has told you, and on current evidence nobody is going to. I set out to find mine, assumed it would take an afternoon, and spent three days discovering that the answer is far harder to get at than the confident version suggests. So this is not a piece about what AI does to code. It is about how to ask that question of your own repository without arriving at a wrong answer, which turned out to be the genuinely difficult part. The tool I built to do it is git-habits : free, local, and it reads no source code whatsoever. What git can actually tell you Git history is a surprisingly rich behavioural record. Not of quality, about which it knows nothing at all, but of habits: how often you commit, how large those commits are, whether you go back and change what you wrote last month, and whether anybody still touches the old code. That is a narrower thing than quality and it is the thing the industry claims has changed, so it is the thing worth measuring. Four signals are computable from commit metadata alone, without opening a single source file: Moved lines. The share of changed lines sitting in files git detected as renamed or copied. It is the closest thing history offers to "somebody went back and reorganised this." Legacy touch. The share of changes landing on files nobody has

Most "which AI coding model is best?" debates I see devolve into vibes. Someone pastes a cherry-picked diff, someone else counters with a different cherry-picked diff, and nobody learns anything transferable. The problem isn't the models — it's that we almost never evaluate them on our code, with our constraints, using a method we could rerun tomorrow. This article is the harness I wish more teams built before arguing. It's a small, language-agnostic evaluation loop you can point at any model you have access to — including free tiers — and get a defensible answer to a narrow question: does this model help with the tasks I actually do? The evaluation trap Public benchmarks (HumanEval-style tasks, leaderboard scores) measure performance on curated problems with clean specifications. Your work is rarely that. Real tasks look like: "Add retry logic to this half-migrated HTTP client without breaking the old call sites." "Write tests for a function whose behavior depends on a config file three directories up." "Refactor this 200-line function, but the ORM calls must stay in the same transaction." These tasks share a trait: correctness is checkable, but only by you . Your test suite, your type checker, your lint rules. That's actually good news — it means evaluation can be automated against artifacts you already have. The artifact: a task-runner harness The core idea is dumb on purpose. Define a set of tasks as directories. Each task has a prompt, a snapshot of the relevant code, and a verification command. The harness applies a model's patch and runs the verifier. No scoring model, no LLM-as-judge — just your own build. eval/ ├── tasks/ │ ├── 001-retry-http-client/ │ │ ├── prompt.md │ │ ├── repo/ # snapshot of the relevant files │ │ └── verify.sh # exit 0 = pass │ ├── 002-test-config-loader/ │ └── 003-split-billing-fn/ └── run_eval.py Here's a minimal runner (Python 3.10+, stdlib only): #!/usr/bin/env python3 """ run_eval.py — apply a model-produced patch to each task and

Most comparisons of AI coding models are useless to you. Not because the authors are dishonest, but because they test on their problems: greenfield LeetCode-style prompts, demo TODO apps, or a framework you don't use. Your codebase has different failure modes — a weird build system, a legacy module nobody wants to touch, tests that take 40 minutes. This article is a small, reproducible harness you can run in an afternoon to compare coding models against your own repository, with scoring based on your own test suite instead of vibes. The artifact is ~120 lines of shell and Python, plus a scoring rubric you can adapt. The core idea Instead of asking "which model is best?", ask: on a fixed set of real tasks from my repo, which model produces patches that pass my tests, fastest, with the least hand-holding? That gives you three measurable axes: Correctness — does the resulting diff pass the relevant tests? Edit locality — did the model touch only the files it should have? Iteration cost — how many prompt rounds did it take to get there? Step 1: Build a task set from your own git history The cheapest source of realistic tasks is your own commit log. Find commits that fixed a bug or added a small feature, then check out the parent commit and ask the model to reproduce the fix (without showing it the actual fix). #!/usr/bin/env bash # extract_tasks.sh — mine candidate tasks from git history # Usage: ./extract_tasks.sh <repo_path> <count> set -euo pipefail REPO = " $1 " ; COUNT = " ${ 2 :- 8 } " cd " $REPO " # Small, self-contained commits: <= 3 files, <= 80 changed lines, has a test file touched git log --oneline --no-merges -n 300 | while read -r sha msg ; do files = $( git diff-tree --no-commit-id --name-only -r " $sha " | wc -l ) lines = $( git diff --shortstat " $sha ^" " $sha " | grep -oE '[0-9]+ insertion|[0-9]+ deletion' | grep -oE '[0-9]+' | paste -sd + | bc ) if [ " $files " -le 3 ] && [ " ${ lines :- 999 } " -le 80 ] ; then echo " $sha | $files | $lines | $msg "

Search "best project management software for startups" and you get the same dozen names every time: Trello, Asana, ClickUp, Notion, Linear, monday.com, Basecamp. Ranking them by feature count tells you almost nothing, because they are not really competing for the same job. The useful question for a startup is not which tool has the most features. It is two narrower ones: does your work run through engineering or through the whole company, and does per-seat pricing or flat-rate pricing fit a headcount that is about to change? Answer those and the shortlist collapses to two or three. The split that actually decides it Two forks matter more than any side-by-side feature grid. The first is who the tool is built for. Issue trackers like Linear are built around the engineering workflow (issues, cycles, a keyboard-first interface) and feel wrong the moment a marketer or a founder tries to run a launch plan in them. General work tools like Asana, ClickUp, monday.com and Trello are built for any team, which makes them flexible but also less opinionated about how software actually ships. The second fork is the shape of the bill. Almost everything in this category charges per seat per month, so the cost scales directly with hiring. A small number, Basecamp most notably, offer a flat rate that does not. For a company planning to double headcount inside a year, that difference can outweigh any feature comparison. If your team is mostly engineers For an engineering-led startup, an issue tracker usually beats a general project tool. Linear's free plan includes unlimited members, two teams and up to 250 issues, which is enough to run a small product team before paying anything; its Basic plan is $10 per user per month billed yearly and lifts the cap to unlimited issues and five teams. The trade-off is scope: Linear is deliberately narrow, so non-engineering work does not fit it well. The larger, more familiar alternative is Jira, which startup roundups still name as the default for

Week 3. "The deploy is done. Everything's green. Now what am I actually supposed to be looking at?" Previously Runner ↓ Cache ↓ Artifact ↓ Deployment Today ↓ Monitoring Junior Engineer: The canary rolled out fine yesterday. 100% traffic, all healthy. I closed my laptop. Was that wrong? Senior Engineer: Not wrong, exactly. But let me ask you something first. Your service is running on a server somewhere. Right now, this second — is it healthy? Junior Engineer: I mean... I assume so? Nobody's messaged me. Senior Engineer: "Nobody's messaged me" isn't an answer. It's the absence of one. That's the entire problem monitoring exists to solve. The Thing Nobody Says Out Loud Senior Engineer: Here's an uncomfortable fact about production systems: you cannot see them. Not directly. You're not standing next to the server, watching electricity move through it. Everything you know about whether it's healthy is a claim — something a piece of software told you, that you're choosing to trust. Junior Engineer: That sounds obvious when you say it, but I don't think I've ever actually thought about it that way. Senior Engineer: Most engineers don't, until the gap between "the system told me it's fine" and "the system is actually fine" bites them. Monitoring is the discipline of shrinking that gap — of making sure what you're told is close to what's actually true, and told to you fast enough to matter. 📒 Senior Engineer's Notebook You don't monitor a system because you don't trust it. You monitor it because you can't see it. Trust isn't the issue — visibility is. The Car Dashboard Analogy Junior Engineer: Can you make this concrete? Senior Engineer: Think about driving a car. You can't see the engine. You can't see the oil level, the coolant temperature, how much fuel is actually left in the tank, mid-drive. All of that is invisible to you, sealed inside metal, while you're doing 100 km/h. So the car gives you a dashboard. Speed, fuel, engine temperature, warning lights. You're not wat