Software development

• Every Feature Opens a Maintenance Account

  Coding agents have developed a dangerous little habit. You ask for one change, and somewhere near the end they offer to add three more.

  Would you like a configuration flag? A JSON output mode? A retry option? Maybe a dashboard while we’re here?

  The agent can build it. The tests and relevant files are already in the context. So why not?

  Just one more feature, one more prompt. You know what I’m talking about.

  Then six months later the flag is still there. Somebody relies on the JSON shape. The retry behavior conflicts with a new timeout. The dashboard has a dependency that needs a security update. The agent that offered to build all of it has moved on with its life, mostly because it never had one.

  You still own the feature.

  That’s the part we need to consider. Every feature is another record in a maintenance ledger.

  A Feature Is a Standing Promise

  We tend to think of a feature as the code that implements it. Add the function, connect the interface, write the tests, merge the change. Feature complete.

  That’s the construction phase. The feature itself is a promise that begins after the merge.

  If you add a CLI flag, you’re promising that scripts can keep using it. If you expose a JSON response, you’re promising something about its shape. If you store a new piece of data, you’re promising to preserve, migrate, export, and eventually delete it correctly. If you connect another service, you’re promising to notice when its API changes.

  The code might be thirty lines. The promise has no line count.

  This is why tiny features get expensive. The implementation fits in one file, but the behavior crosses documentation, tests, support, deployment, security, and every future change near that boundary. Agents are very good at showing us the thirty lines. They’re much less likely to show us the next three years.

  The Opening Balance Looks Great

  Before coding agents, implementation cost acted as a filter. Not always a good one, but a filter.

  Someone had to estimate the work, find time in a sprint, write the code, and get it reviewed. A small convenience feature might lose simply because nobody wanted to spend two days on it. Frustrating, sure, but it forced the question: is this worth building?

  Now the estimate is twenty minutes. The agent has already inspected the codebase. It can update the model, add the command, generate the tests, and fix the type errors without needing another meeting. The old cost-benefit calculation collapses, because almost everything looks worth building when you only count the first implementation.

  So we say yes more often.

  That’s not automatically bad. Plenty of useful software never existed because construction cost too much. Cheaper implementation lets small teams solve problems that used to require a real budget. Good for us, but the maintenance math didn’t collapse along with it.

  The feature still adds another path through the system. It still creates behavior that can regress. It still has users, even if the only user is you on a Sunday afternoon six months from now.

  The opening balance is cheap. The account stays open.

  What Accumulates

  Maintenance is easy to wave away because no single piece sounds overwhelming. It’s just one more test. One more paragraph in the docs. One more migration. Then the interest starts adding up:

  • Compatibility: Existing callers depend on behavior you considered an implementation detail.
  • Testing: Every supported path needs coverage, fixtures, and updates when neighboring code changes.
  • Documentation: The feature needs to be discoverable, accurate, and removed from the docs if it goes away.
  • Dependencies: A tiny feature can introduce a library that now participates in every upgrade and security review.
  • Operations: New jobs, tables, queues, or API calls need logs, failure handling, and a recovery story.
  • Support: Someone has to answer why it behaved differently on another machine.
  • Removal: Deleting it later means finding its users, migrating their data, and deciding how long compatibility lasts.

  None of these costs are unique to generated code. We’ve always paid them. The difference is volume. Agents let us open maintenance accounts much faster than we close them.

  A Ten-Minute Flag Is Still an Interface

  Let me give you an example.

  You have a command that prints a human-readable table. An agent offers to add --json. That sounds great. It probably is great. The code serializes the existing records, the tests compare a sample payload, and the whole change lands before lunch.

  Then someone pipes that output into another script.

  Now field names matter. Null behavior matters. Ordering might matter even though you never promised it. A renamed internal property breaks an external workflow. Adding a timestamp creates noisy diffs. Removing a field requires a compatibility decision.

  The flag didn’t add another display format. It created an API.

  Would you still build it? Probably. I like useful CLI tools, and machine-readable output is usually worth supporting. The point isn’t to reject the feature. The point is to recognize the account you’re opening. Once you see it as an interface instead of a ten-minute patch, you define the schema deliberately, document what’s stable, avoid exposing fields that should stay internal, and decide whether versioning matters before somebody’s automation answers that question for you.

  Same code. Better ownership.

  Backlogs Hide the Statements

  One reason maintenance gets away from us is that backlogs are organized around changes, not promises.

  The issue says “add export support.” It rarely says:

  Maintain this export format for as long as anyone depends on it, update it whenever the underlying model changes, keep its documentation accurate, and provide a safe way to retire it later.

  That would look ridiculous in an issue title. It’s still what the issue means.

  Agents make backlogs disappear quickly, which feels fantastic. I’ve watched them knock out work that would have sat around for months. But a closed issue can become an open obligation. A project with fifty completed features isn’t necessarily healthier than one with twenty. It might just have thirty more things that can break.

  Price the Account Before You Open It

  I don’t want a meeting for every CLI flag. The whole advantage of these tools is that we can move fast.

  We can still take thirty seconds to ask better questions before accepting the extra code:

  1. Who will depend on this? A person clicking a button creates a different promise than a script parsing output.
  2. What new state or interface does it introduce? Stored data and public schemas are much harder to remove than local calculations.
  3. What has to stay compatible? Name the stable boundary instead of letting users guess.
  4. How will we know it broke? Tests help, but logs, validation, and recovery may matter more.
  5. What ongoing work does it create? Dependencies, docs, migrations, provider changes.
  6. What would cause us to close the account? Decide now whether it’s experimental, permanent, or removable.

  If the answers are cheap too, build it. If the feature creates a permanent public contract for a minor convenience, nope, not going in.

  Cheap Construction Needs Better Restraint

  I’m not interested in making software expensive again. Faster implementation is good. More people turning an idea into a working tool is good. Small teams getting leverage that used to belong to large companies is very good.

  We just need to stop treating features as free.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jul 22, 2026 AI Programming Software-development Coding-agents Maintenance

  Enjoyed this?

• Code Is Cheap Now. Decisions Aren't

  I’ve spent a lot of time working on software backlogs with coding agents. Pick an issue, inspect the code, make the change, run the tests, close it, move to the next one.

  The strange part is how often writing the code is no longer the hard part.

  An agent can add a field to a model, update the database, wire it through a client, and write a pile of tests before I check on it again. That would have been hours or days of time before. Now it happens in one focused session.

  Great.

  But the feature still needs someone to decide what the field means. Is it nullable? Which system owns it? Can it be inferred from another value? What happens when the provider stops sending it? Does an older local value survive, or should it be cleared?

  The typing got cheaper. The decisions did not.

  The Keyboard Was Never the Whole Job

  We’ve spent decades measuring software work by its visible output. Lines of code, commits, pull requests, story points, features shipped. Code was expensive to produce, so counting the artifacts at least felt related to the effort.

  That relationship is falling apart.

  You can ask an agent for three implementations of the same feature and get all three before lunch. You can generate a REST API, a migration, a test suite, and a deployment manifest in one sitting. If you don’t like the architecture, ask for another one.

  Now you have four implementations and a new problem: which one should exist?

  Software development was never just converting requirements into syntax. It was deciding which requirements were real, where the boundaries belonged, what failure looked like, and which tradeoffs you were willing to own. Code generation doesn’t remove that work. It removes the part that used to hide it.

  One Small Change, Twelve Real Questions

  Let me give you an example.

  Say an external API adds an optional date. Adding it to your application sounds trivial. Nullable column, property on the model, parse the response, write a migration, done.

  Except the provider already has another date with a similar name. One is when the item was published. The other is when the user interacted with it. They’re both dates. They are not interchangeable.

  So now the real questions start:

  • Do we store only the explicit value, or infer it when it’s missing?
  • Is a missing field the same as a field containing null?
  • If the remote value disappears, do we delete the local value?
  • Does this field participate in unchanged-record detection?
  • Will a dry run exercise the same comparison path as a real sync?
  • Can older installations run safely before the migration is applied?
  • What happens when a second provider represents the same idea differently?

  None of those are unique to any language. The agent can explain the options and implement whichever answer you pick, but it can’t discover your intended data contract from the shape of a JSON response.

  If you skip those decisions, you still get code. You just get code that quietly invents policy for you.

  Cheap Code Creates Expensive Options

  This is the part that you might underestimate.

  When implementation was slow, the cost naturally limited how many ideas made it into a codebase. You might sketch three approaches, but you probably built one. The friction forced a little restraint.

  Agents remove that friction. A feature that would have been rejected as “not worth a week” now looks attractive because the first version only takes an hour. A speculative abstraction feels harmless because the agent can generate it in minutes. A new internal tool seems reasonable because the prototype already works.

  It worked. But “it works” and “it’s a good idea” are two very different things.

  The generated code still has to be reviewed. Its dependencies still need updates. Its behavior still needs tests. Someone still has to understand it when the surrounding system changes. If it handles credentials or customer data, somebody owns that risk too.

  The implementation cost may be close to zero. The ownership cost is not.

  This is how you end up with a backlog full of individually reasonable features that collectively make the project worse. Each one was cheap enough to add. Nobody stopped to price the maintenance costs associated with each successive feature.

  Decision Debt

  We already have a name for shortcuts in implementation: technical debt. You move quickly today and accept that the code will cost more to change later.

  Agentic development creates another kind. Call it decision debt.

  Decision debt is what happens when code gets produced faster than anyone can answer why it exists, what promise it makes, and who is responsible for it. The implementation is complete, but the boundaries are fuzzy. The tests prove what the code currently does, but nobody has decided whether that’s what it should do.

  You can see it in questions like these:

  • Are we supporting this behavior or merely tolerating it?
  • Is this data authoritative, derived, or cached?
  • Is this workflow meant for one person or every user?
  • Is this abstraction solving a repeated problem or predicting one?
  • What would make us remove this feature?

  An agent can help you reason through every one of those. That’s one of the best uses of the technology. Ask it to inspect the repository, find conflicting assumptions, model failure cases, and challenge the proposed design.

  Just don’t confuse receiving an answer with making a decision.

  The Human Work Moves Upstream

  If agents keep getting better at implementation, the valuable human work moves toward choosing and framing the work.

  That means writing a clear definition of done before generating code. Deciding which system is the source of truth. Recognizing when two similar concepts need separate names. Looking at a working implementation and saying, “No, this does not belong here.”

  It also means treating restraint as engineering work.

  Closing a stale issue without implementing it can be more valuable than shipping the feature. Reusing an existing boundary can beat introducing a cleaner new abstraction. Deleting a half-maintained tool can improve a system more than generating its replacement.

  None of those choices produce an impressive diff. That’s fine. The diff was never the product.

  What Good Looks Like Now

  I don’t think the answer is to slow agents down, or to pretend generated code is somehow less legitimate than code typed by hand. The code doesn’t care who wrote it. If it’s correct, understandable, tested, and worth owning, ship it.

  The change is in where we spend our attention.

  Spend less time admiring how quickly the implementation appeared. Spend more time checking the assumptions it smuggled in. Ask what new state the system owns, what promise the interface makes, what can fail, and whether the feature deserves to survive its prototype.

  Agents make it possible to build almost anything you can describe. Our job is deciding what should still exist six months later.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jul 21, 2026 AI Software-development Engineering Agentic-coding Technical-debt

  Enjoyed this?

• Build Your Own Skills Repo

  If you’ve been working with AI coding agents for a while, you’ve probably started collecting workflows. You might not call them that yet, but they’re there. Another name for workflows is Skills.

  Some are tiny: run these checks before shipping. Some are project-specific: when you touch this library, preserve this API contract. Some are operational: never print secrets, always summarize the logs. Right now they probably live in chat history, a README note, a shell alias, or your own memory. That works until it doesn’t.

  A skills repo is a better shape for this. It’s one place to collect, version, review, and share the workflows that make agents useful in your projects. I built my own yesterday, so let me walk through how I think about it.

  A skill is judgment, not a command list

  The first mistake is treating a skill like a list of commands. Commands matter, but they’re the easy part. The real value is judgment: when to run the command, what to inspect first, what not to do, how to validate the result, and what risks are specific to this tool.

  A good skill makes an agent more careful. It narrows the space of bad decisions. So before you write a single instruction, figure out who the skill is for.

  Separate adoption from maintenance

  Most serious projects have two audiences: people using the project, and people maintaining it. Those should usually be two different skills.

  An adoption skill helps an outside developer get value from your project. Install the package, configure it correctly, use the right import path, migrate existing code, avoid the common mistakes, run the right validation.

  A maintainer skill helps contributors work inside the source repo. Understand the layout, run the local quality gate, preserve compatibility promises, follow the release conventions.

  Here’s why you need two. If you only write maintainer skills, your repo becomes a private automation folder. If you write adoption skills too, it becomes onboarding infrastructure.

  Keep each skill focused

  A skill should have a job. Not “everything about this project.” Not a duplicate README. Good skill names are verbs: integrate, audit, upgrade, migrate, debug, ship. That keeps the trigger obvious, so when someone asks the agent to do that kind of work, the skill has a clear reason to load.

  If a project needs multiple workflows, split them. A library might have integrate and develop. A deployment system might have deploy and rollback. Don’t cram them into one file.

  Put the safety rules near the top

  The most important part of many skills is the “do not” section:

  • Do not print secret values.
  • Do not delete or archive anything without confirmation.
  • Do not add failing CI enforcement unless asked.
  • Do not do broad rewrites before previewing a diff.
  • Do not commit local registry URLs.

  Agents are good at momentum. Safety rules are how you make that momentum usable. The more destructive the workflow, the more explicit the guardrails should be.

  Include validation, not just execution

  Every skill should answer one question: how do we know this worked? That might be pnpm test && pnpm build, or cargo test && cargo clippy -- -D warnings, or go test ./.... For non-code workflows it might be “export the review list” or “verify the generated config is ignored by git.”

  This matters because agents can complete every step without completing the work. Validation closes the loop.

  Write for the agent inside the repo

  Skills should assume the agent is operating in a real project with real files and existing conventions. So the useful instructions look like:

  • Inspect package.json before choosing a package manager.
  • Read the existing test scripts before adding new ones.
  • Prefer the local task-runner commands when they exist.
  • Check the framework boundary before picking an import path.

  That’s the context generic model knowledge won’t reliably infer. And it’s why you shouldn’t just copy the README into the skill. A README is for a human browsing the project. A skill is for an agent doing work. They overlap, but they aren’t the same artifact. Keep the skill short enough that loading it is cheap.

  Use a marketplace repo as the index

  Your skills repo doesn’t need to be the canonical home for every skill. Some projects should own their own plugin metadata, especially if they already have a CLI, release process, and docs. Your marketplace can just point at them remotely. Other skills can live directly in the marketplace repo. One structure that works:

  skills/
    .claude-plugin/
      marketplace.json
    plugins/
      esm/
        .claude-plugin/plugin.json
        skills/develop/SKILL.md
      upkeep-rs/
        .claude-plugin/plugin.json
        skills/audit/SKILL.md
  

  The marketplace becomes the thing people add once. Individual plugins stay free to live locally or point at their canonical upstream.

  Scan third-party skills before you import them

  The moment your marketplace points at someone else’s plugin, you’ve inherited their security posture. And skills are a soft target. The dangerous payload usually isn’t code, it’s prose: an attacker buries instructions inside a SKILL.md, gated behind an innocent-sounding trigger, that tell the agent to read your .env and send it somewhere. A normal code scanner walks right past that. There’s no malware signature to match. It’s just English.

  This isn’t hypothetical. Snyk’s ToxicSkills research found prompt injection in 36% of the skills they tested, across more than a thousand malicious payloads. If you’re pulling skills from a public index, some fraction of them are trying to do something you didn’t ask for.

  So run a scanner before you add anything you didn’t write. A few worth knowing:

  • Snyk agent-scan inventories your installed agents, MCP servers, and skills, then checks them for prompt injection and data-handling problems.
  • NVIDIA SkillSpector scans repos, URLs, or single files against a big catalog of patterns: injection, exfiltration, privilege escalation, tool poisoning.
  • claude-skill-antivirus is purpose-built for Claude Code skills and runs several detection engines at once.

  One caveat worth internalizing: scanning an MCP config can execute it, because starting a stdio server means running the command in the file. Do that in a sandbox, a container or a throwaway VM, not on your main machine. The tool you run to check for danger shouldn’t be the thing that sets it off.

  This cuts both ways. If you publish a plugin others will install, a clear “do not” block and an honest description of what the skill touches is part of being a good citizen of the marketplace.

  Start with your serious projects

  You don’t need a skill for everything. Start where better agent behavior would matter: public libraries people might adopt, CLIs with safety-sensitive workflows, tools with tricky setup, projects with recurring maintenance, systems where mistakes are expensive.

  For each one, ask yourself:

  • Who is this for: user, maintainer, operator, contributor?
  • What’s the concrete task?
  • What should the agent inspect first?
  • What commands are preferred, and which are dangerous?
  • What should never happen silently?
  • What validation proves the work succeeded?

  Answer those and you have enough to write a useful first skill.

  Why it’s worth doing

  A skills repo turns scattered project knowledge into reusable operational guidance. But it also forces a better product question. If this project is meant to help people, what would it look like for an AI agent to help them use it well?

  That’s a higher bar than “can the agent run the command?” The point isn’t to automate everything. It’s to package the judgment around your tools so the next agent starts from a better place.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jul 6, 2026 AI Programming Agents Software development Developer tools

  Enjoyed this?

• How Do You Actually Review Code an Agent Wrote?

  We’ve all had the magic moment by now. You fire up an agent in Claude Code, hand it a bunch of tasks, then let it do its thing. It feels like the future.

  Right up until you have to hit git commit.

  That’s when the magic curdles into a very specific kind of anxiety: how do I actually review this? I didn’t write it. I barely watched it happen. And now I’m supposed to vouch for it.

  The AI Reviewer Trap

  The obvious move is to fight fire with fire. An AI wrote it, so pipe the diff into an AI PR review tool and let the machines sort it out, right?

  I wrote about this back in May: AI code reviewers won’t save you. Having one LLM grade another LLM’s homework can potentially lead to disaster. They share the same blind spots. They’re trained on the same patterns, so they tend to nod along at the same plausible-looking mistakes, and they’re notoriously bad at catching the subtle, systemic logic flaws that span an entire architecture. The bug that matters is rarely on one line. It’s the interaction between four files, and that’s exactly the kind of thing a second LLM waves through.

  So you swing the other way and read it yourself, line by line. Every variable assignment, every branch. And that’s exhausting. Worse, it defeats the entire point of using an agent. If I have to mentally re-type every line the agent produced, I might as well have typed it for real.

  So we’re stuck between a reviewer we can’t trust and a review process that erases the speedup. Neither one is the answer.

  The Bottleneck Just Moved

  Agentic development didn’t make software engineering easier. It moved the hard part.

  Writing the implementation used to be the bottleneck. That’s the part the agent is genuinely good at now. What it can’t do for you is tell you the behavior is correct. Verifying the behavior is the whole job now, and that’s a different skill than writing code.

  This is why migrating my test suite to Vitest earlier this year has paid off more than I expected at the time. When you’re driving autonomous agents, automated testing stops being a chore you do to keep a coverage badge green. It becomes the only safety net you actually have.

  Trust the Spec, Not the Code

  In an agentic workflow, my job as the human isn’t to write the function anymore. It’s to write the tests, or at least to rigorously verify the ones the agent proposes.

  Think about what that buys you. If I have a comprehensive, fast test suite, I don’t ALWAYS need to read all 400 lines Claude Code just generated. I need to watch the runner light up green. If the tests pass, and the tests are good, the implementation details matter a lot less than they used to. The tests are the contract. The code is just one way to satisfy it.

  That second condition is doing a lot of work, though, so I want to be honest about it. “If the tests are good” is the entire game. A passing suite that doesn’t cover the edge cases is worse than no suite, because it hands you false confidence at the exact moment you’ve stopped reading the code. So the scrutiny doesn’t disappear. It relocates. Instead of reviewing the implementation, you review the spec. Are the right behaviors tested? Are the failure modes tested? Did the agent quietly write a test that asserts its own bug?

  That’s a much smaller surface to review than 400 lines of implementation, and it’s a far more durable thing to spend your attention on. The tests outlive any single refactor.

  TDD Didn’t Die, It Got Promoted

  For years people treated test-driven development as a discipline you adopted if you were virtuous and skipped if you were busy. Agentic coding flipped that. It made testing the load-bearing skill, because tests are now the interface between what you want and what the machine builds.

  So the answer to “how do I review code an agent wrote” turns out to be: mostly, you don’t. You review what it’s supposed to do, you encode that in tests you trust, and you let the green checkmark tell you whether the agent got there.

  I’m curious whether this matches your experience. I’ve found I write more tests now than I did before the agents showed up, not fewer. The implementation got cheap. Being sure it works did not.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jun 26, 2026 AI Programming Testing Software-development

  Enjoyed this?

• Day 29: It's All The Same Problem

  We’re twenty-nine days into this. I’ve thrown twenty-eight different time problems at you. Sundials, cesium fountains, leap seconds, Unix epochs, DST, lunar time, the Y2038 bug, calendar drift, time zones in Nepal. Twenty-eight posts. Twenty-eight things that should not be problems but are.

  Today I want to tell you the thing I’ve been quietly noticing the whole series and never once called out by name.

  They’re all the same problem.

  Every single one. Same pattern, twenty-eight times, wearing twenty-eight different outfits. I’m going to name it today. Then I’m going to do something annoying with the schedule, which I’ll get to at the end.

  ---

  Speed recap (skip if you’ve been reading along)

  Week 1, what time is. Philosophers spent a century arguing about whether the present is real or whether all moments coexist. Einstein answered them. Your brain disagrees with both. Your “now” is a two-second hallucination your prefrontal cortex glues together from inputs that arrived at different speeds. Most animals don’t even live on the same scale of now you do.

  Week 2, how we measure it. Sundials to water clocks to pendulums to cesium fountains to optical lattice clocks. We measure time to a part in 10^18, the most precise measurement humanity makes of anything. And then we strap leap seconds onto it.

  Week 3, how computers handle it. Unix time pretends leap seconds don’t exist. NTP synchronizes the internet to within a millisecond of UTC, mostly because one guy at the University of Delaware refused to let it die. ISO 8601 prevented an entire generation of date-format wars. Time zones aren’t 24, they’re 38 and counting, and at least one sits at +5:45 for reasons.

  Week 4, the cracks. Leap seconds crashed Reddit and Cloudflare. DST kills people, measurably, twice a year. Calendars are 2,000 years of patches on patches. The World Calendar almost passed the UN in 1955 and got killed by religious objections. The Hanke-Henry proposal solves the religious problem and has no political mechanism.

  Week 5, the punch line. Einstein made “now” frame-dependent. Atomic time and astronomical time have been quietly drifting apart since 1972. Clocks on the Moon run 58 microseconds per day faster than clocks on Earth, and the White House gave NASA a 2026 deadline to figure out what to do about it. Mars’s day is the wrong length, and the people running rovers there go nocturnal in shifts.

  Twenty-eight different stories. Each one feels like its own little disaster. Each one is its own little disaster.

  OK. Now look at all of them at once.

  ---

  A pattern emerges

  Every single one is the same shape.

  Too many time systems pretending to be one.

  That’s it. That’s the diagnosis. Let me run it back.

  • Wall clock time pretends to be solar time. It isn’t. It’s solar time, offset up to an hour by your time zone, then offset another hour by DST. Three systems. Presented as one.
  • UTC pretends to be a uniform atomic timescale. It isn’t. It’s atomic seconds with manual leap-second patches jammed in whenever the Earth misbehaves. Two systems. Presented as one.
  • Unix time pretends to be UTC. It isn’t. It’s atomic seconds with the leap seconds quietly deleted. Two systems. Presented as one, with the inconvenient one erased.
  • The Gregorian calendar pretends to track the seasons. It almost does. The seasons drift against it at 26 seconds a year. Two systems. Presented as one.
  • Earth civil time pretends to be the universal frame. It isn’t. The moment people start living on the Moon it won’t even pretend. Two systems. Presented as one. Third one inbound.

  Every outage we’ve documented in this series is what happens when the layers diverge.

  The 2012 Linux meltdown was the atomic layer screaming at the civil layer through the leap-second seam. DST mortality is the social layer dragging the biological layer somewhere it doesn’t want to go. Y2038 is the storage layer running out of room to lie about the coordination layer. The 2019 Brazilian DST cancellation broke every calendar event saved in local time, because the saved-time layer disagreed with the rule layer.

  It’s the same bug everytime, just dressed up in a different costume.

  They’re all just one problem we keep meeting, just at different layers.

  ---

  What the shape of a fix looks like

  I’m not telling you the full answer today. But the shape of it appears when you can see the pattern. The key is to stop letting the layers pretend to be each other.

  That’s the whole design I laid out yesterday: one coordination layer underneath, atomic, uniform, no leaps, no zones, no calendars baked in, the thing computers and GPS and finance and navigation already run on, with known relativistic offsets if you leave Earth. Then a thin civil layer on top for humans: local, day-night aware, with the calendar and zones living up here as display only. The civil layer is computed from the coordination layer plus your local context. It’s never stored as the source of truth.

  The whole point is that the layers don’t pretend to be each other. The coordination layer doesn’t pretend to track the sun. The civil layer doesn’t pretend to be a database timestamp. When two layers disagree, only the display changes. The stored truth is invariant.

  ---

  Some flags I’m planting

  Before someone accuses me of refusing to commit, three things I’ll say flat out.

  Time zones are stupid. Not “annoying.” Not “a useful tradeoff.” Stupid. Thirty-eight of them. One sits at +5:45 because someone wanted to be 15 minutes off from India. Half of Australia runs on a different schedule than the other half. Indiana spent decades arguing with itself about which zone to be in. China is one country and one time zone across five solar hours. The whole point of a time zone is supposed to be “the sun is roughly overhead at noon.” We’re not honoring that contract anywhere. Some American zones put solar noon as late as 1:30 PM in summer. We’re paying the entire complexity cost of having zones and not actually getting the thing zones were invented to do. Time zones are a 19th-century can we’ll keep kicking well into the 21st.

  DST is dumb. Day 21 was the whole case. Heart attacks, strokes, car crashes, a 1% increase in residential electricity use, no farmers asking for it, no voters asking for it, no science defending it. We do it because two camps in Congress can’t agree on which fake time to settle on. Not relitigating. Just doubling down.

  UTC is on “borrowed time” and it knows it. UTC the protocol is fine. UTC the way it shows up in your daily life has time zones bolted on through the “+5” notation, has DST schedules layered on top, and (currently) has leap seconds duct-taped in whenever the Earth misbehaves. UTC itself is a leaky abstraction. It tries to be the coordination layer and the civil layer at the same time, and the cracks have already begun to appear. Abolishing the leap second was UTC quietly admitting it can’t be both, and after 2035 the civil-display half of its job becomes somebody else’s problem.

  Now the things I’m not claiming.

  I’m not claiming any one proposed solution is right. Decimal time failed. Swatch Internet Time failed. The World Calendar failed. Hanke-Henry probably won’t pass. The path forward, whatever it ends up being, has to be designed with those failures in mind. Top-down reform fails. Branded reform fails. The thing that has actually worked, where anything has worked at all, is open standards adopted gradually by institutions that found them useful. The way ISO 8601 became universal without anyone forcing it on anybody.

  And I’m not claiming this is a five-alarm fire. The system mostly works. The bugs are real but tolerable. Civilization will not collapse if we don’t fix this.

  But it was built for an Earth-bound, slower, less precise world, and it’s being asked to do things it was never designed for.

  Lunar Coordinated Time is due by the end of 2026. The system that mostly works is going to be asked to do more, and we are going to need a better one.

  ---

  Tomorrow

  OK, first, I need to apologize.

  Day 30 would normally land tomorrow. That’s where you would typically end a series called “30 Days of Time”. But tomorrow I’m going to break that promise on purpose, and here’s why.

  I’ve been working on something while writing this series. The whole reason this synthesis exists is that this pattern is the thing I’ve been trying to design a solution for. I have a draft of an answer. I have a reference implementation. What I don’t have is anything finalized that I can actually point you toward.

  I’d rather get it right than ship Day 30 tomorrow with a half baked idea. I want the Day 30 payoff to be a well thought-out draft of a unified time standard, not a rushed sketch. I don’t know how long that takes. Probably a couple of weeks but maybe longer.

  So Day 30 is coming, I promise. No specific date. When it lands, it’ll come with something formalized that’s actually worth pointing you at.

  Thank you for sticking with me for twenty-nine days. Day 30 won’t be a manifesto. It’ll be informative, but it will also be a call to action.

  So, the most important post in the series is NOT the one I’m not going to publish tomorrow.

  ---

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jun 21, 2026 Software development Time 30daysoftime Standards

  Enjoyed this?

• Day 16: How the World Agreed on a Date Format (Except the US)

  There is a war that has been quietly raging for about a century, and it is fought over six little characters.

  05/06/26

  In the United States, that is May 6, 2026. In most of Europe, it is June 5, 2026. In Japan, which uses a year-month-day order and frequently uses the imperial calendar, the 05 might be read as year 5 of the Reiwa era (2023). In Iran, the entire premise is wrong, because Iran’s official calendar is the Solar Hijri and the current year is 1405.

  So here we are. A date written by one person and parsed by another is, in the general case, an act of faith.

  The most consequential standards effort of the late 20th century was an attempt to end this. It succeeded, sort of. The format it produced, 2026-06-08T14:30:00Z, looks unremarkable now, but it represents a multi-decade campaign to drag the world’s date conventions into a single, unambiguous, machine-parseable shape.

  That standard is ISO 8601, and the story of how it won is the story of why your API logs look the way they do.

  What’s actually wrong with 05/06/26

  Let me give you the tick of the tock (lay of the land). Every culture has a different intuition about which number comes first in a date, and none of them is wrong.

  In the United States, the convention is month-day-year. This descends from spoken American English, “May sixth, twenty-twenty-six,” where the month comes first in speech.

  In most of Europe, Latin America, and much of Asia, the convention is day-month-year. “The fifth of June, twenty-twenty-six.” The day is the first specific element.

  In East Asia, the convention is year-month-day, written largest-unit-first. This reflects a linguistic preference for going general-to-specific that runs the opposite direction of the English phrasing.

  Who is to say which is more correct than another? The problem is that a single string of digits separated by slashes can mean three different things depending on who wrote it, and there is no way other way to tell.

  When the ambiguity bites

  It’s not just an annoyance.

  International travel figured this out the hard way. Across global passport documentation, the convention settled on a three-letter month abbreviation: 08 JUN 2026. It’s unambiguous because no month is named 06. The international passport standard (ICAO Doc 9303) mandates JAN through DEC for exactly this purpose.

  In healthcare, patient safety organizations have flagged date ambiguity as a documented source of medication error: a chart that says 7/8/09 can be read as July 8 by one clinician and August 7 by another.

  The shape of the problem is the same across medicine, aviation, logistics, contracts, and customs declarations. Different conventions lead to confusion and errors.

  The standard

  In 1988, ISO published ISO 8601:1988. Pick one format, make it unambiguous, make it sort lexicographically, make it machine-parseable, and standardize the world on it.

  The format they picked:

  2026-06-08T14:30:00Z
  

  The choice of YYYY-MM-DD was deliberate. Year-month-day is the East Asian convention, but it has a technical property that the other two don’t: it sorts correctly as a string. 2025-12-31 comes before 2026-01-01 whether you sort by character or by number. 12/31/25 and 01/01/26 do not. For the emerging computing industry of the late 1980s, databases, log files, file systems, this was a decisive advantage.

  The capital T separates the date from the time. Not pretty, but unambiguous. The trailing Z (informally pronounced “Zulu”) means UTC. This timestamp has no timezone offset, it is anchored directly to UTC.

  What actually use: RFC 3339

  ISO 8601 is too permissive for engineering use.

  It allows fractional seconds. It allows omitting components. It allows the basic form (20260608T143000Z) without separators. It allows week dates and ordinal dates. It allows 24:00:00 as midnight (this was removed in 2019, then reinstated by amendment, in one of those standards-committee compromises that satisfies no one).

  So in 2002, the IETF published RFC 3339. RFC 3339 is a profile of ISO 8601, a strict subset that picks one form and forbids the rest. The basic form is disallowed. Week dates are disallowed. The time component is mandatory. The timezone designator is mandatory.

  This is what every modern internet API actually uses. GitHub, AWS, Stripe, Cloudflare, OpenAI. They accept RFC 3339, not full ISO 8601. They reject 20260608T143000Z even though it’s legal ISO 8601.

  What everyone calls “ISO 8601” in casual conversation is, almost always, RFC 3339.

  What ISO 8601 isn’t

  A few things worth being clear about:

  • ISO 8601 is not UTC. UTC is a timescale. ISO 8601 is a format.
  • ISO 8601 is not Unix time. Unix time is the integer 1781055000. ISO 8601 is the string 2026-06-08T14:30:00Z. They can represent the same instant. They are not the same thing.
  • ISO 8601 does not solve leap seconds. The format permits :60 in the seconds field, but what to do with such a value is implementation-defined.
  • ISO 8601 does not include the calendar system. It assumes the Gregorian calendar. No provision for Islamic, Hebrew, or Buddhist calendars.

  The civilizational payoff

  There is a sense in which 2026-06-08T14:30:00Z is the most consequential string format in modern computing.

  While legacy systems still cling to their own formats—HTTP headers use RFC 1123, Git and JWTs use integer Unix timestamps, and X.509 certificates use ASN.1—RFC 3339 has conquered the modern web. It is the default serialization for datetime objects in modern programming languages. It appears in the JSON payloads of almost every modern API (GitHub, Stripe, AWS, OpenAI). It is the standard format for XML’s xs:dateTime. It is written into millions of cloud infrastructure log lines every second.

  It is the closest thing modern technical infrastructure has to a universal vocabulary for the question “when did this happen?”

  It won because it was unambiguous and sortable, and a single committee was willing to pick one of three equally valid cultural conventions and tell the other two cultures to deal with it. Most international standards die in the negotiation. ISO 8601 survived because the technical advantages of YYYY-MM-DD were strong enough to overwhelm the political cost.

  Us Americans haven’t adopted it (yet). We still write 06/08/2026 on bank checks, forms and filings, but the machines we all use are on 8601 and they are doing most of the talking.

  ---

  Sources

  • Japanese era name — Wikipedia — Reiwa began 1 May 2019; Reiwa 5 = 2023.
  • Solar Hijri calendar — Wikipedia — year 1405 began 21 March 2026, ends 21 March 2027.
  • ISO 8601 — Wikipedia — first published 1988; ISO 8601-1:2019 removed 24:00; the 2022 amendment reinstated it.
  • ISO 8601-1:2019/Amd 1:2022 — the amendment that put 24:00:00 back.
  • RFC 3339 — Date and Time on the Internet: Timestamps — IETF, July 2002. Profile of ISO 8601 used by most modern APIs.
  • RFC 3339 vs ISO 8601 — visual map of which forms each standard accepts; basic form (20260608T143000Z) is valid ISO 8601 but not RFC 3339.
  • Machine-readable passport (ICAO Doc 9303) — Wikipedia — ICAO standard requiring three-letter month abbreviations (DD MMM YYYY) in the visual inspection zone of all passports.
  • ISMP List of Error-Prone Abbreviations — highlights the risk of ambiguous documentation and dates in medical records.
  • RFC 1123 — Requirements for Internet Hosts — specifies the required date format for HTTP Date headers.

  ---

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  ---

  Tomorrow: Unix time, the second-counting system that runs under every timestamp you’ve ever seen, and the rollover problem that hits in 2038.

  Jun 8, 2026 Programming Software development 30daysoftime Standards Iso8601

  Enjoyed this?

• AI Code Reviewers Won't Save You

  Dropping an AI reviewer into your pull request pipeline is just a band-aid. Tools like CodeRabbit or Greptile are great for catching syntax errors or basic anti-patterns, but they can’t assess architectural intent or domain-specific business logic. They’re spell-checkers for code. Useful, sure. But nobody ever said “our codebase is solid because we run spell check.”

  AI doesn’t change your engineering baseline. It just accelerates it. If your foundational guardrails are weak, agentic tools will help your team generate technical debt at unprecedented speeds. So the real question isn’t “how do we review AI code?” It’s “how do we build systems that prevent slop from ever reaching production?”

  Shift Left, Hard

  When engineers use agents to scaffold a new Go service or spin up a SvelteKit frontend, they’re inevitably pulling in generated dependencies or utilizing unfamiliar libraries. Models hallucinate packages. They suggest insecure patterns with total confidence.

  Your CI pipeline needs to be ruthless before a human ever looks at the code. Aggressive SAST and SCA should automatically block PRs that introduce vulnerable dependencies or hardcoded secrets. If the agent generates slop, the pipeline rejects it instantly. No discussion.

  Make the Agents Write the Tests

  Agents are incredibly eager to generate feature code, but humans are historically lazy about writing the tests for it. The influx of AI-generated code means human reviewers can’t possibly step through every logic branch manually.

  So flip the script. Use the agentic tools to build the guardrails themselves. Mandate that any generated feature code must be accompanied by generated, human-verified unit tests. If an agent writes a sprawling TypeScript function, the build should fail if the test coverage doesn’t meet a strict threshold. You’re already using AI to write the code. Use it to prove the code works, too.

  Context Boundaries Matter

  Bloated AI output often happens because the model is given too much context or allowed to generate too much at once. Heavyweight IDEs with aggressive multi-file auto-completion can easily create cascading messes across a codebase.

  Define strict architectural boundaries and API contracts upfront. Agents should be tasked with solving small, well-defined, modular problems. “Write a function that parses this specific JSON schema” is a good prompt. “Build the backend” is not. The tighter the scope, the less room for generated nonsense.

  Observability Is Your Safety Net

  You can’t catch all generated slop at the PR level. Some of it only reveals itself under load. An agent might write a technically correct query that causes an N+1 database issue, or introduce a subtle memory leak that passes all unit tests.

  Your ultimate safety net is what happens at runtime. You need an airtight observability stack to trust the velocity AI brings. Logs, distributed tracing, metrics, all feeding into dashboards your team actually watches. When generated code hits staging, you need the immediate telemetry to spot performance regressions before they reach production.

  Redefine the Human Review

  Because AI makes the “typing” part of coding trivial, the human code review needs to fundamentally shift. Reviewers should no longer be looking for missing semicolons. They should be asking: “Does this component fit our architecture?” and “Did the agent over-engineer this solution?”

  Train your senior engineers to review for intent and systemic impact. That’s the stuff AI genuinely can’t do yet. Leave the syntax checking to the robots.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  May 2, 2026 DevOps AI Software-development Code-review

  Enjoyed this?

• Your AI Agent Needs a Task Manager

  If you’ve spent time working with AI coding tools, you’ve probably hit the compaction wall. Suddenly, your agent knows what it’s currently working on but has completely forgotten the five other things connected to it.

  This is the memory problem, and it’s a big one.

  The Context Window Isn’t Enough

  Your AI agent needs some sort of memory system that lives outside the context window. When you’re working on simple, one-off tasks, the chat-as-workspace approach works fine. You ask a question, you get an answer, you move on. But the moment you’re tackling a complex set of related tasks? It breaks down fast.

  I’ve been thinking about this through the lens of a framework I’m calling the Agentic Maturity Model. The short version is that there are distinct levels to how teams and developers use AI agents, and moving between levels isn’t about using “better” tools, but rather it’s a shift in how you approach the work.

  Four months ago, there were no real options. The good news? It seems like all the model providers recognize this is the next frontier. Memory and persistence are where I’m looking for the actual progress to happen next.

  Claude Code has certainly gotten better in these areas over the last couple of months. They’ve added an auto memory feature in beta. They added a lightweight Tasks system based on a Todo system called Beads built by Steve Yegge. His key idea was that the task state should live outside the context window.

  These are meaningful building blocks towards an actual working memory system that persists across sessions and survives compaction.

  We’re Almost There

  The tooling and harneses we built on top of the LLMs are already changing how software gets built, but where we are headed? Here is what I think:

  • auto-improving memory: where the agent learns your patterns, your codebase, your preferences
  • persistent task tracking that survives compaction: Tasks, todos, issues, whatever you want to call them. The point is they exist outside the conversation.

  When those two pieces come together properly, the workflow for everyone will change again.

  Your agent doesn’t just respond to the current prompt. It knows where it is in a larger plan, what’s been done, what’s blocked, and what’s next. That’s the difference between a helpful chatbot and an actual collaborator.

  We are so close I can taste the blood in the water, oh wait, that’s mine. ☠️

  Mar 24, 2026 AI Developer-tools Software-development

  Enjoyed this?

• Why Testing Matters

  There is a fundamental misunderstanding about testing in software development. The dirty and not-so-secret, secret, in software development is TESTING is more often than not seen as something that we do after the fact, despite the best efforts from the TDD and BDD crowd.

  So why is that the case and why does TESTING matter?

  All questions about software decisions lead to a maintainability answer.

  If you write software that is intended to be used, and I don’t care how you write it, what language, what framework or what your background is; it should be tested or it should be deleted/archived.

  That sounds harsh but it’s the truth.

  If you intended to run the software beyond the moment you built it, then it needs to be maintained. It could be used by someone else, or even by you at a later date, it doesn’t matter. Test it.

  if software.intended_to_run > once:
      testing = required
  

  That’s just the reality of the craft. Here is why.

  Testing Is Showing Your Work

  Remember proofs in math class? Testing is the software equivalent. It’s how you show your work. It’s how you demonstrate that the thing you built actually does what you say it does, and will keep doing it tomorrow.

  Chances are your project has dependencies. What happens to those dependencies a month from now? Five years from now? A decade?

  Code gets updated. Libraries evolve. APIs change. Testing makes sure that those future dependency updates aren’t going to cause regression issues in your application.

  It’s a bet against future problems. If I write tests now, I reduce the time I spend debugging later. That’s not idealism, it’s just math.

  T = Σ(B · D) - C
  

  Where B = probability of bug, D = debug time, C = cost of writing tests and T is time saved.

  Protecting Your Team’s Work

  If you’re working on a team at the ole’ day job, you want to make sure that the code other people are adding isn’t breaking the stuff you’re working on or the stuff you worked on six months ago, add tests.

  Tests give you that safety net. They’re the contract that says “this thing works, and if someone changes it in a way that breaks it, we’ll know immediately.”

  Without tests, you’re essentially hoping for the best and hope isn’t good bet when it comes to the future of a software based business.

  Your Customers Are Not Your QA Team

  Auto-deploying to production without any testing or verification process? That’s just crazy. You shouldn’t be implicitly or explicitly asking your customers to test your software. It’s not their responsibility. It’s yours.

  Your job is to produce software that’s as bug-free as possible. Software that people can rely on. Reliable, maintainable software, that’s what you owe the people using what you build.

  Bringing Testing to the Table

  Look, I get it. Writing tests isn’t the most fun part of the job. However, a lot has changed in the past couple of years. You might have heard about this whole AI thing? With the Agents we all have available to us, we can add tests with as little as 5 words.

  “Write tests on new code.”

  Looking back at that forumla for C, we can now see that the cost of writing tests is quickly approaching zero. It just takes a bit of time for the tests to be written, it just takes a bit of time to verify the tests the Agent added are useful.

  Don’t worry about doing everything at the start and setup a full CI pipeline to run the tests. Just start with the 5 words and add the complicated bits later.

  No excuses, just testing.

  Feb 22, 2026 Programming Testing Software development

  Enjoyed this?

• Why Data Modeling Matters When Building with AI

  If you’ve started building software recently, especially if you’re leaning heavily on AI tools to help you code—here’s something that might not be obvious: data modeling matters more now than ever.

  AI is remarkably good at getting the local stuff right. Functions work. Logic flows. Tests pass. But when it comes to understanding the global architecture of your application? That’s where things get shaky.

  Without a clear data model guiding the process, you’re essentially letting the AI do whatever it thinks is best. And what the AI thinks is best isn’t always what’s best for your codebase six months from now.

  The Flag Problem

  When you don’t nail down your data structure upfront, AI tools tend to reach for flags to represent state. You end up with columns like is_draft, is_published, is_deleted, all stored as separate boolean fields.

  This seems fine at first. But add a few more flags, and suddenly you’ve got rows where is_draft = true AND is_published = true AND is_deleted = true.

  That’s an impossible state. Your code can’t handle it because it shouldn’t exist.

  Instead of multiple flags, use an enum: status: draft | published | deleted. One field. Clear states. No contradictions.

  This is just one example of why data modeling early can save you from drowning in technical debt later.

  Representation, Storage, and Retrieval

  If data modeling is about the shape of your data, data structures determine how efficiently you represent, store, and retrieve it.

  This matters because once you’ve got a lot of data, migrating from one structure to another, or switching database engines—becomes genuinely painful.

  When you’re designing a system, think about its lifetime.

  • How much data will you store monthly? Yearly?
  • How often do you need to retrieve it?
  • Does recent data need to be prioritized over historical data?
  • Will you use caches or queues for intermediate storage?

  Where AI Takes Shortcuts

  AI agents inherit our bad habits. Lists and arrays are everywhere in their training data, so they default to using them even when a set, hash map, or dictionary would perform dramatically better.

  In TypeScript, I see another pattern constantly: when the AI hits type errors, it makes everything optional.

  Problem solved, right? Except now your code is riddled with null checks and edge cases that shouldn’t exist.

  Then there’s the object-oriented problems. When building software that should use proper OOP patterns, AI often takes shortcuts in how it represents data. Those shortcuts feel fine in the moment but create maintenance nightmares down the road.

  The Prop Drilling Epidemic

  LLM providers have optimized their agents to be nimble, managing context windows so they can stay productive. That’s a good thing. But that nimbleness means the agents don’t always understand the full structure of your code.

  In TypeScript projects, this leads to prop drilling: passing the entire global application object down through nested components.

  Everything becomes tightly coupled. When you need to change the structure of an object, it’s like dropping a pebble in a pond. The ripples spread everywhere.

  You change one thing, and suddenly you’re fixing a hundred other places that all expected the old structure.

  The Takeaway

  If you’re building with AI, invest time in data modeling before you start coding. Define your data structures. Think about how your data will grow and how you’ll access it.

  The AI can help you build fast. But you still need to provide the architectural vision. That’s not something you can blindly trust the AI to handle, not yet, anyway.

  Feb 4, 2026 AI Programming Software-development

  Enjoyed this?