Free throws, obviously. And the reason is mostly the feedback loop.

Shoot a free throw and you know within a second whether it went in. You adjust and try again. Hire a manager and it might take months - or years - before you figure out whether you got it right. Even then, half the time you still can't tell how much was the hire vs. the team they inherited, the market, luck, whatever else was going on.

You improve at the speed of your feedback. More precisely, at the speed and quality of it. Once you start noticing that, a lot of skills and decisions start looking less like talent problems and more like loop problems.

Short loops compress learning

Short feedback loops give you more reps, and you usually catch mistakes sooner - before they compound. That compresses the learning curve. It's also why some domains get so competitive (sports especially). Everybody else is getting those same reps, and they're getting them constantly.

Coding is a clean example. You write something, run it, watch what happens, change it, repeat - usually within a few minutes. Changing a company culture, raising a child, picking an executive: you might wait years before you know if your judgment was any good.

Short loop

Long loop

Same cycle either way - act, observe, update. What changes is how long you wait, how clear the signal is, and whether you can actually connect the result back to what you did.

Easy environments and hard ones

Some environments make this almost unfair. Clear rules, repeatable situations, quick accurate feedback - golf, chess, a lot of crafts. You get a huge number of attempts and you know pretty quickly how you did.

Other environments are the opposite. Business, investing, leadership, hiring. Feedback shows up late, noisy, or just wrong. You don't get clean reps. And most of the work that actually matters lives here, which means "just practice more" isn't really a strategy. You have to get better at learning from worse information.

Know your loop

The useful habit is looking at a skill or decision and asking what the feedback loop actually looks like. A few concrete properties matter more than the rest:

Latency - how long until feedback arrives? Seconds, weeks, years?

Frequency - how many repetitions do you actually get? You can shoot hundreds of free throws in an afternoon. Finding the right investor happens a handful of times in a career, if that.

Fidelity - does the feedback measure what you care about, or are you tracking a proxy that only vaguely relates to the real goal?

Attribution - can you connect the result to a given decision? Revenue went up after a reorg. Was it the reorg, or the product launch that shipped the same quarter?

Cost - how expensive is each attempt? Cheap attempts invite experimentation. Expensive ones make people freeze, or overfit to one data point. Would SpaceX have made it with half the capital?

Reversibility - can you recover after being wrong? Shipping a feature behind a flag is reversible. Signing a five-year contract, or making a very public bet, often isn't.

These properties sit on different parts of the loop:

Latency is the wait between action and feedback. Fidelity and attribution are about the signal - is it clean, and does it clearly point back to what you did? Reversibility is whether the update can actually change the next action, or whether you're locked in. Cost and frequency are more about the cycle as a whole: how often you get to go around, and what each lap costs.

Look at things this way for a while and you'll start noticing where a loop is weak. That's usually where you're stuck.

Manufacture shorter loops

People who get good at long-feedback work usually aren't just more patient. They're building shorter loops inside the long one.

They don't wait five years to learn whether a strategy worked. They create intermediate signals along the way. In practice that tends to look like:

Make smaller bets. A pilot, a prototype, a limited rollout. Same direction as the big decision, but cheaper and faster to learn from.

Track leading indicators, not just the final outcome. Usage, retention, hiring pipeline quality - whatever tends to move before the thing you actually care about.

Write predictions down beforehand. "I think this will do X by Y date, because Z." When the result finally shows up, you have something to compare against. Without that, it's too easy to rewrite history into a story where you basically knew all along.

Review the decision separately from the outcome. A good process can produce a bad result. A bad process can get lucky. Grade yourself only on outcomes and you may just be amplifying noise.

Update before you're certain. Waiting for the final result often means waiting too long. Adjust as intermediate signals come in.

Long loop

Versus the same strategy with a manufactured loop you can run many times before the final outcome arrives:

Manufactured loop

When feedback is slow, patience alone doesn't cut it. You have to find ways to learn before the final result arrives.

Fast feedback can still teach the wrong lesson

Short loops aren't automatically good. A tighter loop makes you improve quickly at whatever it rewards (anyone who's trained an LLM has seen this). That doesn't mean it rewards the right thing.

Social media, gambling, click-through rates, short-term revenue - all of these give you immediate feedback that can feel positive at first. They're also excellent at training you to optimize the proxy until the proxy is the goal. More likes, more clicks, more bookings this quarter... and somehow less of what you actually wanted.

There's a related problem with local maxima. When the loop is fast and the current approach seems to be working, you keep doing the same thing. You stop trying anything structurally different, because the short loop keeps telling you you're on the right track. Until you plateau.

Speed isn't the only lever. If the signal is fast but wrong, you'll get worse at the thing that counts while getting better at the thing that doesn't.

Learning when the world is slow

Anyone can improve when the result is immediate. Free throws, code, games with clear scores - the loop does a lot of the work for you.

The harder part is improving when consequences show up months or years later. Which, inconveniently, is most of the decisions that matter - who you hire, what you build, which strategy you commit to, or how you raise your kids.

Know the loop you're in, and which parts of it are working against you. When the real feedback is far away, manufacture something shorter in the meantime. And don't confuse a fast proxy with the thing you actually care about.

Good judgment is keeping learning even when the world is slow to tell you whether you were right.

At first, this might seem backwards. Both code and essays are just text, but code has to follow exact rules while an essay can be written countless ways. You might expect a language model to be better at the less constrained task. In practice, those constraints are actually part of what makes coding easier for AI.

I've been thinking about this quite a bit since this tweet, so I figured I'd put some thoughts on paper (keyboard?).

Coding and writing require very different things.

Why AI is so good at coding

The biggest difference is that most programming does not require a new idea. Building an auth flow, a settings page, or an API endpoint is usually applying patterns that thousands of developers have applied before. Sure, the details change, but much of the implementation is familiar. That is exactly the kind of work AI is good at: recognizing a pattern, adapting it to the situation, and producing a working solution.

Code also has a much tighter feedback loop, giving AI/agents an immediate way to validate their work. It either compiles or it doesn't. Tests pass or fail. Types line up or they don't. An AI can write some code, check the result, and correct itself. The space of possible solutions is large, but at least boundaries are visible.

It's not really "coding versus writing"

Good writing is different. A good essay has to do more than assemble ideas into polished sentences. It needs an idea of its own - or at least a familiar idea seen from a perspective that makes the reader reconsider it. The writer's job is both to find that point of view and communicate it to the reader: to make a connection others missed, develop an argument worth considering, or turn an experience into an insight.

There is no test suite for that. A paragraph can be grammatically perfect, logically coherent, and still completely uninteresting. This is why AI writing often feels so average. Average code can be useful in many tasks. It just needs to follow conventions, handle the common cases, and ultimately get a job done. But average writing is usually the writing we skip.

The distinction is not really coding versus writing, though. It is work that applies established patterns versus work that depends on a viewpoint or new idea.

AI can be very good at writing when the writing is mostly about applying patterns or logic: release notes, documentation, status updates, summaries, and routine emails. In those cases, originality may even be a liability. The goal is to communicate known information clearly, where introducing new ideas can actually be detrimental.

And AI can struggle with coding when the work is not about building blocks: choosing an architecture with uncommon constraints, coming up with a new algorithm, or making a judgment call where information is limited. Those tasks require taste, lots of context, or a genuinely new approach.

A better way to judge a task

Knowing this gives us a better way to decide what kinds of questions to ask AI. Instead of bucketing your task as "writing", "coding", "design", "research", etc., ask yourself what a good answer requires.

Does it require finding and applying a well-established pattern? Does it have unique constraints that are unlikely to be encountered elsewhere? Can the result be easily checked with a test, a trusted source, a calculation, or some other metric? If so, AI is likely to be useful.

On the other hand, if it requires taking a position, deciding what matters, or creating something whose value depends on taste, there is no clear feedback beyond "what feels right". Sure, AI may still help you think through a problem, but it should not be the one making the final call.

You can apply this filter almost anywhere. AI can summarize a legal document more reliably than it can invent a novel legal argument. It can build a page from an existing design system more reliably than it can create a brand from scratch (or at least one worth copying). It can compare logical options (well, not all the time) more reliably than it can decide the amount of risk your company should take.

On the other side, boundaries are rarely absolute. AI can occasionally produce an original connection, and people do plenty of formulaic writing. But this mental model is useful because it predicts where AI will be dependable and where it will need more supervision.

The right question is not necessarily "Can AI do this?". It is, "What kind of work does this task actually require?".

I've noticed myself letting it slide recently on a project I'd been building with AI. I needed the same access check in a handful of places: a route handler, a background job, an API endpoint, a webhook, etc. Each time, I'd describe what I needed, the model would generate something that worked, and I'd merge it.

Each version looked roughly like this:

if (user.isActive && user.hasPermission('read') &&
    !user.isSuspended && account.status === 'open') {
    // do a thing
}

Essentially the same conditionals every time. Four conditions, maybe slightly different variable names, copy-pasted logic with a word or two changed. There's a much cleaner way to do this - a shared helper, for example, like something I'd extract if I were writing this myself. But I didn't. The code worked! The tests passed and I wasn't the one who'd have to touch it again.

That's the laziness here: if it doesn't follow best practices, or I know a piece of code will be a pain to maintain, what difference does it make? When I need to change something later, the LLM deals with it, not me.

Except the LLM doesn't write in a vacuum. It reads your codebase. The files you have open, the patterns that are already there, and the recent changes you've made. Every shortcut you merge into your codebase is a signal about how things are done here. The next time you ask the LLM for another endpoint with the same access rules, the model won't start from first principles. It'll start from the other four copies already sitting in your repo.

So you ask for a fifth endpoint, and you get a fifth conditional, with the same copied code. You ask for a refactor, and the model preserves all five, because that's what your code looks like. The bad pattern isn't a one-off anymore, it's considered to be your style.

If you let things go on like this, can you really trust that the LLM will catch every instance if you try to fix it later?

Sure, a few of these aren't catastrophic. That's how it always starts, but code smells do stack up. Each duplicated conditional, each "god" function, each "I'll clean this up later" merge adds another layer of signaling to the next prompt. Eventually you can't easily prompt your way out of it. At least not without getting your hands dirty and rolling up your sleeves.

The most frustrating part: I thought I was outsourcing maintenance to the LLM, but the slippery slope I found myself on was actually training it to have ever-worsening habits.

Write code like a human will maintain it. LLMs are sponges that soak up everything you do and repeat it back to you. So make sure it's good.

A modification log is just a table that tracks changes to your data. Not a new idea. Still incredibly useful.

You can do a lot with it later:

• Audit trail
• Display historical trends
• Track user activity
• Replay data to replicate bugs
• See the state of your database at any point in time

You don't need to build any of that on day one. Just log the changes. Whenever you need one of those use cases, the data is already sitting there.

They're also pretty simple to implement. One table, a handful of fields:

• parent_model
• parent_id
• field_name
• old_value
• new_value
• user_id
• created_at

That's flexible enough to cover any model in the app. I'd start with your core ones - users, orders, whatever actually drives the business - and expand from there. Any time a tracked model updates, you write a new row for each field that changed.

Then you need to populate it. A few common approaches:

• Explicit logging in API routes: after each create, update, or delete, write one row per changed field.
• Model hooks: use your ORM's callbacks (before_save, after_update, etc.) so you don't have to touch every route.
• Write-Ahead Logging (WAL): if your database has one, inspect the WAL and write those changes into the mod log.

Pick whatever fits your codebase. What matters is consistency - every change to a tracked model should land in the log.

Reading the data back is the harder part. Normal tables store current state: one row per user, one row per post, one row per order. A modification log stores history - one row per field change. So answering "what did this record look like last Tuesday?" means replaying those changes up to a point in time.

An Example

Say we have a line_items table for items in an order. Quantities go up, go down, sometimes the row gets soft-deleted.

CREATE TABLE line_items (
    id               INT PRIMARY KEY,
    product_id       INT,
    customer_id      INT,
    quantity_ordered INT,
    year             INT,
    is_deleted       BOOLEAN DEFAULT FALSE
);

Question we want to answer: as of end of day on January 10th, what was total quantity_ordered for 2026 orders?

These queries get expensive at scale, so they're usually better as scheduled reports than live dashboards. Here's an approach that worked for us in Postgres:

WITH latest_modifications AS (
    -- Step 1: For each line item + field, keep only the most recent
    -- change that happened on or before the cutoff date.
    SELECT
        ml.parent_id AS line_item_id,
        ml.field_name,
        ml.new_value,
        ROW_NUMBER() OVER (
            PARTITION BY ml.parent_id, ml.field_name
            ORDER BY ml.created_at DESC
        ) AS row_num
    FROM modification_logs ml
    WHERE ml.parent_model = 'line_items'
      AND ml.created_at <= 1768024800000   -- Jan 10 cutoff
),

line_items_snapshot AS (
    -- Step 2: Pivot row-oriented log entries into column-oriented state.
    -- One row per line item, with the latest known value for each field.
    SELECT
        lm.line_item_id,
        COALESCE(
            MAX(CASE
                WHEN lm.field_name = 'quantity_ordered'
                 AND TRIM(lm.new_value) != ''
                THEN lm.new_value::DOUBLE PRECISION
            END), 0
        ) AS quantity_ordered,
        MAX(CASE
            WHEN lm.field_name = 'year'
            THEN lm.new_value::INT
        END) AS year,
        COALESCE(
            MAX(CASE
                WHEN lm.field_name = 'is_deleted'
                 AND TRIM(lm.new_value) = '1'
                THEN 1 ELSE 0
            END), 0
        )::BOOLEAN AS is_deleted
    FROM latest_modifications lm
    WHERE lm.row_num = 1   -- latest change per field only
    GROUP BY lm.line_item_id
),

line_items_with_details AS (
    -- Step 3: Join to the live table for fields that were set at creation
    -- and never modified — and therefore never logged.
    SELECT
        lis.line_item_id,
        lis.quantity_ordered,
        lis.year,
        lis.is_deleted,
        li.product_id
    FROM line_items_snapshot lis
    LEFT JOIN line_items li
        ON lis.line_item_id = li.id::TEXT
)

-- Step 4: Aggregate with query filters
SELECT
    COALESCE(SUM(lit.quantity_ordered), 0) AS total_quantity_ordered
FROM line_items_with_details lit
WHERE lit.year = 2026
  AND lit.is_deleted = FALSE;

From a high level, here is how it works:

1. Rank changes: For each line item and field, find the most recent log entry on or before the cutoff date.
2. Pivot to columns: Turn one-row-per-change into one-row-per-line-item, with the latest value for each field.
3. Join: Pull fields from the live line_items table that were never modified and therefore never logged.
4. Aggregate: Sum the quantity ordered.

The query uses Common Table Expressions (CTEs) - which is basically a virtual table defined with WITH name AS (...). Each CTE behaves like a regular table while the query runs, but nothing is actually written to disk. When the query finishes, the virtual table is gone. Here we use three of them to break the reconstruction into steps you can read top to bottom: filter for the latest changes, pivot log rows into columns, join back to the live table, then aggregate. You could write this as one giant nested subquery, but CTEs make each stage explicit and much easier to debug.

For any app with reasonable activity, this will result in millions (or even billions!) of lines being logged. With each line representing a single field change, the table grows fast. Even with proper indexing, reconstructing historical state is slow enough that you'll usually want to run these queries in a scheduled job rather than on every page load.

That seems like a fair tradeoff to me. You get a complete audit trail and the ability to answer historical questions, all from one table you can add on day one. Start logging changes to your core models now, and the audit trails, trend charts, and bug replays can come whenever you need them.

If you wanted software, you needed specialists with years of experience. Building good software was hard, so the ability to build it was valuable.

That's changed, and we're all watching it happen in real time.

AI is dropping the cost of software development fast. What used to take a team of engineers can now get built by one person with a few AI tools and a small budget for tokens.

So developers are starting to look less like machine shops and more like home builders.

Almost anyone can build a house. Give them a blueprint, the right tools, some subcontractors - the construction itself isn't really the hard part anymore. Whether they can build a good one is a different story.

What separates home builders usually isn't who swings a hammer better. It's the stuff around the build: attracting customers, relationships, design, taste, understanding what the customer actually needs, reliability, project management, reputation.

Two builders can start with the same materials and end up with totally different houses. Software is heading the same way - if it isn't already there - and you'll notice it most at software companies themselves.

For a long time, software companies competed mostly on engineering. Hire better engineers, build things your competitors couldn't. That was the moat.

Today a lot of competitors can ship roughly the same product. So distribution, customer relationships, support, brand, and product judgment matter more. Same stuff that separates home builders, basically - reputation, relationships, taste, getting customers, trust.

Writing usable code is getting less scarce. More people than ever can turn an idea into something that runs.

A working product and a good product are still very different things.

As AI makes it easier to build, the skills that matter more are the ones around the build: figuring out what customers need, picking the right features, making decent tradeoffs, and shipping something people actually want to use.

Inside companies, developers are adapting too. Instead of laying every brick themselves, they're coordinating subcontractors - LLMs, coding agents, APIs, third-party integrations, open-source libraries. More of the job is deciding what should get built, reviewing the work, and making sure the pieces fit. That shift is happening inside companies whose competitive edge is already moving elsewhere.

There's been a lot of discourse on this. The usual question is whether anyone can build software now (yes). The more interesting one is what happens once everyone can.

What does this mean for software companies?

Once just about everyone can build software, what actually sets a software business apart?

A lot of the same things that set home builders apart: customer acquisition, distribution, trust, reputation, relationships, brand, product judgment, support. Engineering still matters - just not as the only thing that does.

AI makes software easier to build. It doesn't magically make everyone capable of building Stripe, AWS, Figma, or PostHog. The hard parts of running systems at that scale are still out of reach for vibe coders.

For decades, software companies won because they could build things others couldn't.

You can still win. You just win differently now - by knowing what to build, being a good partner to build it with, and going about the process in a way that doesn't fall apart.

Software development isn't worthless. The value is shifting. It used to come from being able to build. More and more it comes from knowing what to build, how to build it, and who you're building it for.

When building gets easy, construction stops being the differentiator.

I'm seeing more and more cases where engineers take an existing or legacy codebase and use AI to refactor, optimize, and improve it. Over time, the codebase hardly resembles the original in design, implementation, and sometimes architecture. Sure, it still deploys and passes tests, and it still lives in the same repo. But in many cases the developers don't actually understand how it works anymore.

I want a term for this: Theseus Slop.

Theseus Slop is what happens when LLMs gradually replace the code in a system you already had, eventually replacing almost every line of code, function, and file, until it feels like a different codebase altogether. Unlike vibe coding a project from scratch, this usually begins with code that you understand and ends with code that you do not.

Maybe you've seen this by now: a legacy service gets "modernized" over a few months, the domain is still the same, the repo name is unchanged, but the auth flow, API integrations, error handling, and even folder layout feel foreign. You can ship features, but you can't explain why a particular guard clause exists.

Where the name comes from

The term comes from the Ship of Theseus, also called Theseus's Paradox, a thought experiment about identity and change. In the paradox, a ship is gradually repaired by replacing each part with a new one, until nothing of the original remains. That raises two questions:

• Is the ship with all new parts still the same Ship of Theseus?
• If it is not, at exactly what point did it stop being the original?

There is no clean answer. It depends what you mean by "the same". Same exact design? Same functionality? Same crew or name on the boat?

Vibe coding does something similar at a glance, but Theseus Slop is the slower version on code you already owned: each piece swapped out until the whole is unfamiliar, with no single moment where anyone called it a rewrite.

You cannot name the exact commit where your understanding ended, any more than you can name the plank that ended the original ship.

The questions

The same two questions apply to codebases.

Is it the same codebase? You can see the Git history and how the codebase has evolved over time. The product name and deployment target are all the same. But the structure of modules, the patterns for I/O, and the implicit conventions or even overall style may not be. Under one set of criteria - continuous version control, same overall functionality - you have one system. Under another - shared mental model among the people who maintain it - you may have replaced it without ever declaring a rewrite. You might not even realize it until you try to explain how it works to someone else.

Is it still yours? You wrote much of the first version. You approved all of the AI's generated diffs. Ownership in that sense is intact. Yet "yours" also means you made all of the design decisions and can reason about it when asked: trace a bug, reject a bad abstraction, explain a tradeoff in review. Theseus Slop is the gap between owning the repo and understanding how it works. The code is in your repo, but the design decisions are not in your head.

When does it matter?

What's the counterargument?

The old ship (code) needed replacing. If it's truly a legacy project, then it's already a liability. If AI-assisted refactors fix bugs, remove dead paths, shrink modules, or align the system with how the product works today, the replacement may be an improvement in every measurable way. Yes, potential confusion among maintainers is a cost, but so was paralysis around code everyone was too afraid to edit.

I would guess some teams argue the gap does not matter much if the repo has a solid set of tests, types, and documentation. You don't need to keep the old architecture in your head if behavior is well known and well documented.

It seems to me that both points hold in many projects. The disagreement is not whether AI can improve code - it clearly can - but whether the remaining gap in understanding matters for your situation.

There are other factors to consider as well:

Stakes. Theseus Slop hurts when you must debug under pressure, review security-sensitive changes, onboard a new engineer, or work through an audit that requires you to know how the system works and not just what it does. It doesn't matter as much when you are throwing together a prototype, exploring an idea for a weekend, or just writing a one-off script.

Scale. A solo developer working on a small tool can better handle an unfamiliar structure. The complexity is usually less anyway. But a team on a long-lived, critical production system magnifies the problem: there is no subject matter expert who can answer questions about their section of the codebase and you must rely on AI to regurgitate an accurate explanation back to you.

Why name it

My attempt to coin the term "Theseus Slop" is not an argument against using AI on existing code. But it's a label for a certain outcome: incremental replacement (without thorough review) at the expense of comprehension. For any important project, it's a risk that needs to be understood and avoided. For everything else, it's a risk that needs to be managed.

Unstack Software LLC ("Unstack", "we", "us", or "our") operates unstack.io (the "Site"), a blog and content site. We hope you ("You" or "Your") enjoy reading it. Please use the Site responsibly. If you post comments or other content, keep it lawful and respectful. We may remove content or restrict access if you don't.

The articles, posts, and other materials on the Site are for general information and entertainment. They are not professional advice. Your use of the Site is at your own risk.

These Terms of Use (the "Terms"), the Site, and our practices may change from time to time. We will try to warn you about material changes, but we make no guarantees.

That's the basic idea, but You must read through the entire document below and agree with all the details before You use the Site.

Your Agreement with Unstack

Your use of the Site is governed by these Terms. The "Service" means the Site at https://unstack.io/ and its subdomains, including all pages, articles, posts, media, and any features we make available in connection with the Site (such as comments, sharing controls, newsletters, search, or other interactive elements).

By accessing or using the Service, You agree to these Terms. If You do not agree, do not use the Service.

Unstack may change the Terms from time to time. If we make material changes, we may post the updated Terms on the Site and update the effective date. Your continued use of the Service after the changes take effect constitutes acceptance of the updated Terms. If You do not agree to the changes, stop using the Service.

If you have any questions about the Terms, please contact us at support@unstack.io.

Who May Use the Site

• You may not use the Service if You are barred from receiving services under the laws of the United States or other applicable countries, including the country in which You are resident or from which You use the Service.
• You must be at least 13 years old to use the Service. If You are under 18, You represent that You have your parent or guardian's permission to use the Service.
• If You create an account or submit content that requires registration, You must provide accurate information and You must be a human. Accounts or submissions created by automated methods are not permitted except where we explicitly allow them.

Use of the Site

• Your use of the Service must comply with all applicable laws, regulations, and ordinances.
• You agree not to engage in any activity that interferes with or disrupts the Service, including attempting to overload, scrape, or probe our systems without permission.
• You may not use the Service to transmit malware, spam, or unsolicited communications.
• You may not attempt to gain unauthorized access to any part of the Service, other users' accounts, or our systems or networks.
• We may limit or suspend access to the Service, or remove content, at our sole discretion, with or without notice.

Comments and User Content

The Service may allow You to post comments, feedback, or other material ("User Content"). You retain ownership of Your User Content, but by submitting it You grant Unstack a worldwide, non-exclusive, royalty-free, perpetual license to use, host, store, reproduce, modify, publish, display, and distribute Your User Content solely as needed to operate, promote, and improve the Service.

You represent and warrant that:

• You own or have the necessary rights to submit Your User Content;
• Your User Content does not violate these Terms or any applicable law; and
• Your User Content does not infringe the intellectual property, privacy, or other rights of any third party.

You agree not to submit User Content that is unlawful, defamatory, harassing, hateful, obscene, fraudulent, misleading, or that promotes illegal activity or violence. We do not pre-screen User Content and are not responsible for it. We may remove or refuse any User Content at any time, for any reason or no reason.

Interactive Features, Links, and Sharing

The Service may include links to third-party websites, embedded content, social sharing buttons, comment systems, newsletters, or other interactive features. These features may be operated by us or by third parties. Your use of third-party features may be subject to those parties' terms and privacy policies.

When You use sharing or embed features, You understand that content may be visible on third-party platforms according to those platforms' settings and policies. We are not responsible for how third parties handle information You choose to share.

Privacy and Analytics

The Service is subject to our Privacy Policy, available at https://unstack.io/privacy (the "Privacy Policy"), which is incorporated into these Terms by reference. The Privacy Policy describes how we collect, use, and share information, including through cookies and typical website analytics.

By using the Service, You agree to our collection and use of information as described in the Privacy Policy. Where required by law, we will seek Your consent for certain uses of cookies or similar technologies.

Ideas and Feedback

You may choose to, or we may invite You to, submit comments or ideas about the Service or our content ("Ideas"). By submitting any Idea, You agree that Your disclosure is unsolicited and without restriction, that it will not place Unstack under any fiduciary or other obligation, and that we are free to use the Idea without additional compensation to You, including on a non-confidential basis.

Modification of the Site

• You acknowledge that the Service may change from time to time without prior notice, including the addition or removal of features, content, or design.
• Unstack shall not be liable to You or any third party for any modification, suspension, or discontinuance of the Service or any part of it.

External Resources

The Service may include hyperlinks to other websites, content, resources, or email content. Unstack is not responsible for the availability, accuracy, or practices of any external sites or resources and does not endorse advertising, products, or other materials on or available from them.

License from Unstack and Restrictions

All content available on or through the Service, including without limitation text, photographs, graphics, logos, trade and service marks, and audiovisual content, is owned or controlled by Unstack, its licensors, or other rights holders and is protected by copyright, trademark, and other laws. You acknowledge that the Service and any underlying technology contain our proprietary information.

Subject to Your compliance with these Terms, we grant You a personal, worldwide, royalty-free, non-assignable, non-exclusive license to access and use the Service for Your personal, non-commercial use (unless we expressly permit otherwise in writing).

You may not (and may not permit anyone else to):

• copy, modify, distribute, publicly display, or create derivative works from our content except as permitted by law or with our prior written permission;
• remove any copyright, trademark, or other proprietary notices;
• use any robot, spider, scraper, or other automated means to access or index the Service in a manner that burdens our systems or violates these Terms, except for standard search-engine indexing where allowed by our robots rules;
• reformat or frame any portion of the Site;
• use the Service for commercial purposes not permitted under these Terms;
• impersonate Unstack, any of our employees or representatives, or any other person or entity; or
• collect or store personal data about other users except as permitted by these Terms and applicable law.

Our Copyright Dispute Policy

Unstack respects the intellectual property of others and expects users to do the same. If You believe that material on the Service infringes Your copyright, please send a notice containing the following to our Designated Copyright Agent:

• identification of the copyrighted work claimed to have been infringed, or, if multiple works are covered by a single notification, a representative list;
• identification of the claimed infringing material and information reasonably sufficient to permit us to locate it (providing the URL(s) satisfies this requirement);
• information reasonably sufficient to permit us to contact You, such as an address, telephone number, and email address;
• a statement that You have a good faith belief that the disputed use is not authorized by the copyright owner, its agent, or the law;
• a statement, made under penalty of perjury, that the information in Your notification is accurate and that You are the copyright owner or authorized to act on the owner's behalf; and
• Your physical or electronic signature.

Our Designated Copyright Agent can be reached at: Unstack Software LLC, Attn: Copyright Agent, legal@unstack.io.

Links to Other Websites

The Service may contain links to other websites ("Third Party Sites"). Unstack does not endorse, verify, or assume responsibility for Third Party Sites or any products, services, or content on them. If You follow a link to a Third Party Site, You do so at Your own risk and may be subject to that site's terms and policies. You should review the privacy and other policies of any Third Party Site You visit. Concerns regarding a Third Party Site should be directed to that site.

Disclaimer of Warranties

IF YOU ACCESS THE SERVICE, YOU DO SO AT YOUR OWN RISK. WE PROVIDE THE SERVICE "AS IS", "WITH ALL FAULTS", AND "AS AVAILABLE." WE MAKE NO EXPRESS OR IMPLIED WARRANTIES OR GUARANTEES ABOUT THE SERVICE OR ANY CONTENT ON IT. TO THE MAXIMUM EXTENT PERMITTED BY LAW, WE DISCLAIM ALL SUCH WARRANTIES, INCLUDING STATUTORY WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, AND NON-INFRINGEMENT.

WE DO NOT GUARANTEE THAT THE SERVICE WILL BE UNINTERRUPTED, ERROR-FREE, OR SECURE, OR THAT CONTENT WILL BE ACCURATE, COMPLETE, OR CURRENT. CONTENT ON THE SITE REFLECTS THE AUTHORS' VIEWS AT THE TIME OF PUBLICATION AND MAY NOT BE SUITABLE FOR EVERY PURPOSE. NOTHING ON THE SITE IS LEGAL, FINANCIAL, MEDICAL, OR OTHER PROFESSIONAL ADVICE.

Limitations on Liability

YOUR SOLE AND EXCLUSIVE REMEDY FOR ANY DISPUTE WITH US IS TO STOP USING THE SERVICE. IN NO EVENT SHALL OUR TOTAL CUMULATIVE LIABILITY TO YOU FOR ANY AND ALL CLAIMS RELATING TO OR ARISING OUT OF YOUR USE OF THE SERVICE, REGARDLESS OF THE FORM OF ACTION, EXCEED ONE HUNDRED DOLLARS ($100).

IN NO EVENT SHALL WE BE LIABLE TO YOU (OR ANY THIRD PARTY CLAIMING THROUGH YOU) FOR ANY INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE, OR EXEMPLARY DAMAGES, OR ANY DAMAGES FOR LOST PROFITS, LOST DATA, LOSS OF GOODWILL, OR PERSONAL INJURY, ARISING FROM YOUR USE OF OR INABILITY TO USE THE SERVICE, EVEN IF WE KNEW OR SHOULD HAVE KNOWN OF THE POSSIBILITY OF SUCH DAMAGES.

BECAUSE SOME STATES OR JURISDICTIONS DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, IN SUCH JURISDICTIONS OUR LIABILITY SHALL BE LIMITED TO THE EXTENT PERMITTED BY LAW.

IF YOU ARE A CALIFORNIA RESIDENT, YOU WAIVE CALIFORNIA CIVIL CODE SECTION 1542, WHICH PROVIDES THAT A GENERAL RELEASE DOES NOT EXTEND TO CLAIMS THAT THE CREDITOR DOES NOT KNOW OR SUSPECT TO EXIST IN HIS OR HER FAVOR AT THE TIME OF EXECUTING THE RELEASE.

Indemnification

You agree to hold harmless and indemnify Unstack Software LLC and its affiliates, officers, agents, employees, and partners from and against any third-party claim arising from or related to (a) Your breach of these Terms, (b) Your User Content, or (c) Your use of the Service or violation of applicable law, including any liability or expense arising from claims, losses, damages, suits, judgments, litigation costs, and attorneys' fees. In such a case, Unstack will provide You with written notice of the claim where reasonably practicable.

Choice of Law and Dispute Resolution

These Terms shall be governed by and construed in accordance with the laws of the State of Nebraska, without regard to conflict-of-law principles, as applied to contracts made and performed entirely within Nebraska.

Any controversy, dispute, or claim arising out of or related to these Terms, the Privacy Policy, or the Service shall be settled by final and binding arbitration in Douglas County, Nebraska, pursuant to the rules of the American Arbitration Association, except that either party may seek injunctive relief in a court of competent jurisdiction. Any disputes shall be resolved individually, without resort to any form of class action.

General Legal Terms

These Terms, together with the Privacy Policy, constitute the entire agreement between You and Unstack regarding the Service and supersede any prior agreements on the subject.

If any part of these Terms is held invalid or unenforceable, that portion shall be construed to reflect the parties' intentions as nearly as possible, and the remaining portions shall remain in full force and effect.

The failure of Unstack to exercise or enforce any right or provision of these Terms shall not constitute a waiver of such right or provision.

Unstack shall not be liable for failing or delaying performance resulting from any condition beyond our reasonable control, including governmental action, acts of terrorism, natural disasters, labor conditions, power failures, or Internet disturbances.

We may assign this agreement at any time to any parent, subsidiary, affiliate, or successor, or in connection with a merger, sale, or other transfer of our business. You may not assign Your rights under these Terms without our prior written consent.

Unstack Software LLC will collect certain non-personally identifiable information about you as you use our sites. We may use this data to better understand our users. We can also publish this data, but the data will be about a large group of users, not individuals. We may also collect certain personal information about you and your use of the Service (as defined herein) which may be published and used in the aggregate as set forth in this Privacy Policy.

We will also ask you to provide personal information, but you'll always be able to opt out. If you give us personal information, we won't do anything evil with it.

We can also use cookies, but you can choose not to store these.

Unstack Software makes available services include our web sites (https://unstack.io (the "Site")), our blog, our API, our dashboard, and any other software, sites, and services offered by Unstack Software in connection to any of those (taken together, the "Service"). It is Unstack Software's policy to respect your privacy regarding any information we may collect while operating our Site.

Questions

If you have question about this Privacy Policy, please contact us at support@unstack.io.

Visitors

Like most website operators, Unstack Software collects non-personally-identifying information of the sort that web browsers and servers typically make available, such as the browser type, language preference, referring site, and the date and time of each visitor request. Unstack Software's purpose in collecting non-personally identifying information is to better understand how Unstack Software's visitors use its website. From time to time, Unstack Software may release non-personally-identifying information in the aggregate, e.g., by publishing a report on trends in the usage of its website.

Unstack Software also collects potentially personally-identifying information like Internet Protocol (IP) addresses. Unstack Software does not use such information to identify its visitors, however, and does not disclose such information, other than under the same circumstances that it uses and discloses personally-identifying information, as described below. We may also collect and use IP addresses to block users who violated our Terms of Service.

Gathering of Personally-Identifying Information

Certain visitors to Unstack Software's websites choose to interact with Unstack Software in ways that require Unstack Software to gather personally-identifying information, such as names and email addresses. The amount and type of information that Unstack Software gathers depends on the nature of the interaction. Unstack Software collects such information only insofar as is necessary or appropriate to fulfill the purpose of the visitor's interaction with Unstack Software. Unstack Software does not disclose personally-identifying information other than as described below. And visitors can always refuse to supply personally-identifying information, with the caveat that it may prevent them from engaging in certain Service-related activities.

Additionally, some interactions, such as posting a comment, may ask for optional personal information. For instance, when posting a comment, may provide a website that will be displayed along with a user's name when the comment is displayed. Supplying such personal information is completely optional and is only displayed for the benefit and the convenience of the user.

Aggregated Statistics

Unstack Software may collect statistics about the behavior of visitors to and users of the Service. For instance, Unstack Software may monitor and store data about the most popular parts of the Unstack Software Site or other statistics. Unstack Software may display this information publicly or provide it to others.

In addition, Unstack Software may, from time to time, collect certain personal information from you or your company and/or your use of the Services (your "Data"). Unstack Software may publish and display your Data in the aggregate to the public through our Site or on our blog. However, all Data is only used and published in the aggregate which means that any published Data will not identify you, your company, or link you to the published information in any way.

Unstack Software does not disclose personally-identifying information other than as described below.

Protection of Certain Personally-Identifying Information

Unstack Software discloses potentially personally-identifying and personally-identifying information only to those of its employees and contractors that (i) need to know that information in order to process it on Unstack Software's behalf or to provide services available at Unstack Software's Site websites, and (ii) that have agreed not to disclose it to others. Some of those employees and contractors may be located outside of your home country; by using the Service, you consent to the transfer of such information to them. Unstack Software will not rent or sell potentially personally-identifying and personally-identifying information to anyone. Other than to its employees, contractors, and affiliated organizations, as described above, Unstack Software discloses potentially personally-identifying and personally-identifying information only when required to do so by law, or when Unstack Software believes in good faith that disclosure is reasonably necessary to protect the property or rights of Unstack Software, third parties or the public at large.

If you are a registered reseller or newsletter subscriber and have supplied your email address, Unstack Software may occasionally send you an email to tell you about new features, solicit your feedback, or just keep you up to date with what's going on with Unstack Software and our products. We primarily use our website and blog to communicate this type of information, so we expect to keep this type of email to a minimum. If you send us a request (for example via a support email or via one of our feedback mechanisms), we reserve the right to anonymize and publish it in order to help us clarify or respond to your request or to help us support other users. Unstack Software takes all measures reasonably necessary to protect against the unauthorized access, use, alteration or destruction of potentially personally-identifying and personally-identifying information.

Cookies

A cookie is a string of information that a website stores on a visitor's computer, and that the visitor's browser provides to the Service each time the visitor returns. Unstack Software uses cookies to help Unstack Software identify and track visitors, their usage of Unstack Software Service, and their Service access preferences. Unstack Software visitors who do not wish to have cookies placed on their computers should set their browsers to refuse cookies before using Unstack Software's websites, with the drawback that certain features of Unstack Software's websites may not function properly without the aid of cookies.

Business Transfers

If Unstack Software, or substantially all of its assets, were acquired, or in the unlikely event that Unstack Software goes out of business or enters bankruptcy, user information would be one of the assets that is transferred or acquired by a third party. You acknowledge that such transfers may occur, and that any acquirer of Unstack Software may continue to use your personal information as set forth in this policy.

Data Transmission, Security, and Storage

Unstack Software uses third party vendors and hosting partners to provide the necessary hardware, software, networking, storage, and related technology required to run the Service. You understand that although you retain full rights to your data, it may be stored on third party storage and transmitted through third party networks.

It is extremely difficult to guarantee the complete security of data transmitted through the Internet, via mobile devices, or through the physical transfer of information. While we will take precautions to limit security risks, we can not fully eliminate all security risks associated with personal information. We do not guarantee or warrant the security of any data or information transmitted to us by you, and you do so at your own risk.

Privacy Policy Changes

Although most changes are likely to be minor, Unstack Software may change its Privacy Policy from time to time, and at Unstack Software's sole discretion. Unstack Software encourages visitors to frequently check this page for any changes to its Privacy Policy.

What it means

In the context of computers, Halt and Catch Fire (shortened to HCF) has been generalized to describe machine-code that causes the CPU to stop doing anything useful, forcing you to only recover by resetting (or power-cycling) the machine. In a pretty literal sense, it "halts" the machine. Sure, the "catch fire" part is a joke, but it's not as far-fetched as it might seem. Take the IBM System/360 for example. Apparently when this system would encounter a certain invalid opcode, it would constantly access a specific location in the magnetic core memory, which caused it to get very hot and even catch on fire.

Over time, HCF also became a catch-all label for undocumented or invalid opcodes that lock up the processor, intentional test modes that look like a hang, and real hardware bugs (you might even recall that some early Pentium-class chips could be locked up with a carefully chosen illegal instruction, known as the F00F bug - more on that later).

The phrase was created, in part, because of the standard of using three-letter assembly mnemonics: ADD, CMP, JMP, etc. The joke spread in various publications, including HCF alongside some other personal favorites of mine:

• EPI: Execute Programmer Immediately
• DC: Divide and Conquer
• CRN: Convert to Roman Numerals

The Motorola 6800

So HCF was mostly just a joke, until it wasn't.

The Motorola 6800 has 256 single-byte opcodes, but not every bit pattern corresponds to a documented instruction. Hit the wrong one and the chip does whatever the silicon "decodes" into — sometimes nothing much, sometimes something significant.

Gerry Wheeler's BYTE piece "Undocumented M6800 Instructions" ran in December 1977, volume 2 number 12, in the Technical Forum on pages 46–47. He starts from Motorola's own docs: 197 documented opcodes, which leaves 59 bit patterns unaccounted for in the official story. Some of those behave like NOPs, some change the condition-code register in patterns Wheeler said were still "undeciphered" at the time, and two bytes — $9D and $DD — share one especially nasty outcome he chose to call Halt and Catch Fire. He is explicit that "The mnemonics are, of course, assigned by me."

What actually happens, in hardware terms, is that the part stops behaving like a normal fetch–decode–execute engine: the program counter keeps advancing and the chip issues reads while the address lines march through memory like a hardware counter. Interrupts will not stop you from your path of self-destruction - you only get out of the loop with a reset or power cycle. Wheeler's own description is worth reading in the original, rather than paraphrasing:

When this instruction is run the only way to see what it is doing is with an oscilloscope. From the user's point of view the machine halts and defies most attempts to get it restarted. Those persons with indicator lamps on the address bus will see that the processor begins to read all of the memory, sequentially, very quickly. In effect, the address bus turns into a 16 bit counter. However, the processor takes no notice of what it is reading... it just reads.

On the "catch fire" half of the phrase, he adds, "Well, almost." While the IBM system did catch fire in cases, it seems that the Motorola 6800 did not.

Outside BYTE, the same opcode family picked up other nicknames. David J. Agans, in Debugging (2002), remembers DD as what his team called the "Drop Dead" instruction—same bus-walking trick, different name—and notes that engineers used it deliberately because "all of the address and clock lines were nice, cycling square waves" on a scope.

Most machines only feel like they hang. On at least one early 6800 microcomputer with finicky memory-mapped video, the pattern can show up as visible "snow". Ben Z's Sphere News article is a great rabbit hole to go down (video RAM arbitration, timing, CRT artifacts).

Years later, Motorola engineers wrote more about this same issue. In IEEE Design & Test (1985), Daniels and Bruce describe an illegal opcode that customers found on the MC6800, internally nicknamed HACOF, where the program counter could increment forever until reset. They also tell of a detail that's almost hard to believe: product engineering wanted a fast way to scan RAM during bring-up, recognized this behavior already did something like that, and basically kept it instead of paying to remove it. So, in the words of Bob Ross, this turned out to be a "happy accident".

More recently, someone actually put a real MC6800 on hardware and actually measured the thing instead of just trusting scans of old magazines and Wikipedia pages. Doc TB's lab write-up notes an interesting detail: after the opcode is fetched, there is a delay on the order of tens of milliseconds before the address lines settle into the famous fast counting pattern, and there are other undocumented opcodes that look like slower or glitchier versions of the same idea.

Beyond Motorola

Motorola wasn't the only modern processor with this issue: illegal 6502 opcodes that lock the CPU, the Pentium F00F bug (if you remember that era), pairs of instructions on some architectures that wait forever for an interrupt that cannot arrive, and modern x86 fuzzing talks where people still turn up invalid states in huge processors.

Basically, with fuzzing they're trying to set random or unexpected data to the processor to help identify vulnerabilities or bugs in the processor. Unsurpisingly, it's a pretty effective strategy, and not just for processors, but for all kinds of software as well.

Halt and end post

This was a fun bit of history to research - and there turned out to be much more to it than I expected, even regarding the "catch fire" part. As a lot of software moves up the stack, it's easy to lose sight of the hardware from our 10,000 foot view. In the end, it's just a bunch of silicon wired together in a way that can sometimes go wrong.

All I know is that this phrase is too good to not use - expect a future project (or company) to use the "HCF" acronym.

Sources and more info

To keep you busy, here are some links to the sources and more info:

• Gerry Wheeler, "Undocumented M6800 Instructions," BYTE Dec 1977
• David J. Agans, Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems (AMA, 2002), p. 77
• Ben Z, "Sphere News: Halt and Catch Fire!"
• RetroComputing SE #15289
• Doc TB, "Investigating the HCF instruction on Motorola 6800"
• Wikipedia: Halt and Catch Fire (computing)