A few days ago, someone left a comment on one of my open source projects.
They'd tried my CLI tool — a 3D print quality inspector called Printsight — and found it flagged false defects on prints with uneven lighting. They suggested adding CLAHE (a contrast equalization algorithm) as a preprocessing step.
Good suggestion. Practical. Specific. The kind of feedback you want.
But it took me a while to understand what they were really asking me.
They weren't asking me to add CLAHE. They were telling me: your tool doesn't work in my environment, and I want it to.
The wrong fix
My first instinct was technically correct: write a standalone CLAHE script, document it in the README as a "last resort" for edge cases. Keep the core pipeline clean.
This was the instinct of an engineer who values architectural purity.
It was also wrong.
The standalone script shifts the burden to the user. Now they have to know:
- What CLAHE is
- When to use it
- What parameters to set
- That they should run it before printsight
This is what I now call outputting complexity — you didn't solve the problem, you added a knob and called it documentation.
The right fix is to absorb that complexity into the core pipeline: detect lighting conditions automatically, apply CLAHE only when needed, adapt thresholds per image. The user types printsight photo.jpg. It just works.
This is a simple engineering lesson. But it opens onto something much bigger.
The producer-consumer contract
Every time you produce something — code, a document, a response, a decision — there's someone on the other end consuming it.
And every time you consume something, there was someone who produced it.
This sounds obvious. But its implications aren't.
The producer's job is to absorb complexity so the consumer doesn't have to. You did the hard work — the research, the trial and error, the edge cases — so your output arrives clean.
The consumer's job is to not struggle in silence. When you hit a wall, hand the complexity to someone who can absorb it. You're not failing; you're respecting the division of labor.
Most of us get one side right and the other side wrong.
The three principles
After tracing this idea through a concrete engineering decision, I ended up with three principles that apply whether you're writing code, learning a new field, or just participating in everyday collaboration:
1. As a producer: leave complexity to yourself, leave simplicity to your customer
Every knob you expose is a question you refused to answer. Every default value that "works for most cases" is a judgment call you should have made.
This doesn't mean dumbing things down. It means doing the hard work of figuring out what your consumer actually needs, and giving them exactly that — nothing more, nothing less.
In Printsight's case, this meant redesigning the core pipeline to auto-detect lighting conditions, apply adaptive preprocessing, and return one reliable score. Not a --clahe flag. Not a README section titled "Edge Cases."
In your writing, it means a thesis first, a hook, plain vocabulary — because you absorbed the academic complexity so the reader doesn't have to.
In API design, it means good defaults so users can call one function and get the right answer.
2. As a consumer: don't internal struggle, don't be arrogant
Don't internal struggle. If you hit a wall after ten minutes of independent effort, you've reached the boundary of what solo work can teach you. The next step isn't another thirty minutes of the same — it's asking someone who knows. The consumer's skill is recognizing when to hand the problem off.
Don't be arrogant. Just because you ran the tutorial once doesn't mean you understand the system. Just because you can explain it doesn't mean you can predict it. The five levels of mastery are real — most of us stop at Level 1 (it runs) and think we're done. The consumer who recognizes their own blind spots learns faster than the one who defends them.
3. Everyone is both — always
You're never just a producer or just a consumer. In the same day, you might produce a function call and consume an API, produce a Slack message and consume a design doc, produce a book chapter and consume a research paper.
This means you can't opt out of either responsibility. When you produce, you owe it to your future consumers to absorb the complexity. When you consume, you owe it to your future producers to hand off the complexity you can't carry.
The cycle only works if both sides respect it.
The parallel with AI
There's a reason this pattern feels familiar.
What does an LLM do? It takes a vague, noisy, underspecified question — hundreds of tokens of ambiguity — and compresses it into a coherent answer. The user just sees text. They don't see the transformer layers, the attention heads, the KV cache, the 100 billion parameters that made that sentence possible.
This is "leave complexity to yourself" at planetary scale.
The difference is that AI does it for everyone, all at once, and we treat it as natural. But when a colleague does the same thing — absorbs complexity so our interaction is frictionless — we rarely notice. We should.
The principle doesn't scale out only to AI. It scales down to every interaction you have today.
The test
Before you send that message, commit that code, or finish that conversation, ask yourself:
Did I absorb the complexity here, or did I push it to the other side?
And before you keep banging your head against a problem for another hour:
Is this my complexity to absorb, or should I hand it off?
These two questions, asked consistently, might be the highest-leverage habit you can build. They don't tell you what to do — they tell you how to position yourself. And in both learning and building, position is everything.
