Before You Unleash the AI, De-Complect the Problem

AI has made the easy path very easy.

You can describe a feature, wait a few minutes, and get a screen, a schema, a button, a helper function, a test, a setting, a second mode, and a small dashboard you did not remember asking for. This is powerful. It is also how a product turns into soup before anyone notices.

The hard part of software development was never only typing the code. It was deciding what should exist.

That is where Rich Hickey is useful.

Hickey is famous for drawing a sharp line between simple and easy. Easy is nearby. Easy is what the tool offers first. Easy is adding one more flag because the flag gets today’s problem out of the way.

Simple is different. Simple means not tangled. One thing. One job. One idea that can change without dragging a dozen unrelated ideas along with it.

That distinction matters more now, not less, because AI agents are excellent at easy.

Feature Soup Is Cheap Now

Imagine a note-taking app. At first it captures notes. Then someone says, “It would be useful if notes could have dates.” Sensible enough. Then reminders. Then owners. Then projects. Then a dashboard. Then permissions. Then a CRM-style contact view. Then recurring reminders. Then a calendar sync.

None of those requests is stupid in isolation.

But after a while the original product is no longer a note-taking app. It is a task manager, calendar, CRM, dashboard, and half a project-management system, all wearing the same coat.

A human team can do this slowly. An AI-assisted team can do it at frightening speed.

Another familiar smell is the “simple settings object”. It begins as user preferences. Then it grows feature flags. Then billing state. Then permissions. Then UI state. Then device capabilities. Then a little bit of cached server truth because it was convenient at the time.

Eventually nobody knows what the settings object means. It has become a small god-object. It answers every question because every question was put inside it.

The Hickeyian move is to stop and ask:

What have we tied together that could vary independently?

That question is boring in the best possible way.

Simple Does Not Mean Tiny

There is a trap here. “Simple” does not mean “small” in the sense of fewer files, fewer modules, or fewer deployable pieces.

Sometimes splitting a thing makes the system simpler. Sometimes it just creates operational pain.

Datomic is a useful counterexample for me. It is beautifully separated at the conceptual level: storage, transactor, peers, time, identity, value. But the fact that parts of it can be deployed and reasoned about separately does not automatically make operating it painless. In my experience, those separate deployable pieces could themselves become a source of friction.

So this is not religion.

It is more like guidelines.

A split earns its keep when it makes the system easier to understand, test, recover, or change. If it only makes the diagram look clever, it is probably theatre.

The Unix Shape

The Unix philosophy says: build small tools that do one thing well, then compose them.

That idea is still alive because it keeps human reasoning cheap. grep, sort, uniq, and pipes are not impressive because each tool does everything. They are impressive because each tool does something clear, and the composition stays visible.

Clojure has a similar feel in a different place. Instead of inventing a new method for every class of data, you learn a relatively small set of functions and apply them across maps, vectors, lists, sets, and lazy sequences. The Seq abstraction is one of the reasons this works: many things can be viewed as a sequence, and the same functions become reusable.

Object-oriented systems often go the other way. A new kind of data brings a new set of methods. The operations get glued to the shapes. Sometimes that is useful. Sometimes it means the same idea is reimplemented in a dozen places because the system never made the common operation plain.

This is the bit worth stealing: not Lisp, not Clojure, not any one technology, but the taste for reusable operations over simple data.

Why AI Makes This Urgent

An AI agent will happily build whatever confused shape you describe.

If you ask for “a simple dashboard with capture, reminders, publishing, team permissions, analytics, and AI suggestions”, it may produce something that looks plausible. It may even work for the happy path. But the product truth is already muddy.

The better use of an agent is earlier than that.

Use it to grill the idea.

Use it to read the docs and ask whether the app reality matches them.

Use it to identify the nouns you have introduced.

Use it to ask which nouns are secretly doing two jobs.

Use it to find the one split that would reduce actual confusion, then demand proof that the split helped.

The goal is not to make the architecture impressive. The goal is to keep the product coherent enough that a tired human can still understand it.

A Small De-Complect Review

Before you set the AI loose, try this:

De-complect review

1. What are we about to build?
2. What nouns have we introduced?
3. Which nouns are doing more than one job?
4. Which things vary independently?
5. What is the smallest split that would make the next implementation clearer?
6. What proof would show the split helped?

For a note-taking app, the review might reveal that notes, reminders, tasks, and contacts are separate concepts. They may still connect, but they should not be quietly fused just because the first implementation found it convenient.

For a settings object, it might reveal that user preference, permission grant, billing status, feature flag, and UI state are different kinds of truth. They should not all sit in the same object merely because every screen needs to check them.

For an AI-generated prototype, it might reveal that ten buttons are really a sign that nobody has found the primary action yet.

That last one is often the big clue. A product with many plausible buttons but no obvious first move is usually not rich. It is unresolved.

Complexity Needs Proof

There is one more rule I would add to the Hickeyian lens:

Only complexify for improvement.

Adding a boundary, workflow, queue, schema, or service is not automatically wrong. But the extra moving part needs a feedback loop. It should reduce bugs, shorten tests, make recovery easier, make privacy safer, or cut the amount of context a human has to hold in their head.

Without that proof, it is just more machinery.

This matters because AI makes machinery cheap. Cheap machinery is still machinery.

So before the next project sprint, after the grilling but before you unleash the AI, run a de-complect review.

Ask what has been tied together.

Ask what varies independently.

Ask what proof would show the split helped.

Then build the smallest thing that proves it.

That is not slower. It is how you avoid going fast in the wrong shape.

---

Draft source note: generated on 2026-06-08 from the ChatGPT seed “ChatGPT - The Hickeyian Way” and the resolved Blog Intent Grill. The draft intentionally avoids private Commandbook internals and uses generic examples for public readability.