Halfcycle Get started

The cards

Every card we hand out, and the page behind it

We give these away at events instead of asking for anything. Each one carries a code that leads to the full story. Here they all are, in case you lost yours or want the rest of the set.

Things that went wrong

One small feature, nine problems found before any code was written. Eight of the nine are on these cards, with what each would have cost if it had shipped.

  1. A rule enforced in one place. Not the next one.

    A rule that stops some documents being overwritten lived in the save path and was never copied into restore. Every test of the new code passed.

  2. The undo feature could destroy the backup.

    Backup, index update and commit ran as one step. If the index update failed, the backup was thrown away after the new content was already written.

  3. The button would never have appeared. For anyone.

    It was set to appear based on data the system only attaches to the records the feature refuses to act on. Correct code, passing tests, visible to nobody.

  4. Restoring a document would have deleted its labels.

    Shared code clears every label and writes back the list it is given. The design handed it an incomplete list, and nothing would have failed or errored.

  5. The plan described a bug that did not exist.

    An accurate search of the codebase led to the wrong conclusion: that some code never updated the search index. Both places that use it already did.

  6. The design could not be built where it was going.

    The part of the screen it was meant for cannot change the content it had to replace. Left alone, that surfaces halfway through the work.

  7. Two people, about to build the same thing twice.

    Work split between two people with nothing saying what the connection between the halves should look like. It shows up when the halves are joined.

  8. The summary described a plan already thrown out.

    Three rounds of review replaced the design. The one-line summary at the top, the first thing anyone reads, was never updated. The next person builds from it.

Questions, answered plainly

For somebody who knows AI coding tools exist and not much else. No vocabulary you have to look up.

  1. I already have an AI coding tool. What is this?

    Your coding agents write the code. Halfcycle supplies the roles around them: pinning down what you are building, how it fits, the plan, and the review.

  2. Can’t I just download a process and follow it?

    Written processes can be good. A document cannot read your work back, spot a plan that contradicts itself, or decide whether the result is ready.

  3. Who checks the work?

    Not the thing that wrote it. The work is read back by something that did not produce it, against conditions agreed before it started.

  4. I have never run a project this size before.

    That is the usual starting point. You say what you want to build and it asks you the next question, then the one after. Nothing to read or memorise first.

  5. Does this replace the tool I already use?

    No. It runs on your own Claude and adds a product owner, architect, planner and reviewer when the work needs them. Nothing extra to install alongside it.

  6. Does it get better, or is this it?

    When a project goes wrong in a new way, the cause and the fix are kept and reach every project automatically. Most never reach yours. The rest bring the fix.

  7. My coding agent already reviews its own work. Why isn’t that enough?

    It reviews the file in front of it, and the damage is between files: a rule missing from a new path, a button keyed on the wrong data. Every test passes.

  8. What does it send off my machine?

    Your Claude login never touches us. The checks receive the shape of a change, not your files. What is read is not kept, and we do not train on your documents.

  9. What does it cost?

    Free for solo developers: the whole method, every check, and the console for your own project. Teams and larger organisations have their own plans.

  10. Is this a lot of process for a small change?

    Not if the process fits the change. A throwaway internal tool gets a light pass and anything touching money gets the full review. Nothing to configure.

  11. How to tell if it’s actually done.

    Four questions to put to whoever is building your software, for somebody who does not write it.

  12. Found in the first four minutes.

    For somebody holding a card with a finding written on it by hand, and wondering what just happened.