Imagine both snippets are sent to Claude.
The first contains the full implementation.
The second contains only a description of what the code does.
The question that started bothering me was simple:
Does the model really need the implementation?
Or are we sending more knowledge than we actually need to?
A strange dilemma
A few months ago I started using AI coding tools seriously.
Like many developers, I was impressed almost immediately.
Refactoring became easier.
Boilerplate almost disappeared.
Understanding unfamiliar code became dramatically faster.
Tasks I would normally postpone became easier to start.
The more I used these tools, the harder it became to ignore how useful they were.
Then I went back to work.
And for the first time, I found myself understanding both sides of the discussion.
I understood why developers love these tools.
And I understood why companies are nervous about them.
Because source code isn't just source code.
It contains years—sometimes decades—of accumulated know-how.
Business rules.
Optimization strategies.
Manufacturing expertise.
Pricing models.
Customer-specific workflows.
The things that actually make companies different.
I don't think those concerns are irrational.
At the same time, after seeing what tools like Claude Code can do, I couldn't help thinking we'd be crazy not to use them.
And that led me to a question.
Are we solving the wrong problem?
Most discussions about AI coding tools eventually arrive at the same conclusion:
"If you want the benefits of cloud AI, you have to send your code."
And if your company is uncomfortable with that, there are only two possible answers:
- Ban AI tools.
- Accept the risk.
But are those really the only options?
Because when I looked at the actual tasks I was asking AI to perform, something felt off.
Did Claude really need to see every pricing formula?
Every optimization heuristic?
Every business-specific rule?
Every implementation detail?
Or was it possible that, for many tasks, the model only needed to understand the intent?
That question became an obsession.
A simple thought experiment
Imagine asking Claude to help with this:
def calculate_risk_score(customer, transactions):
score = 0.0
# proprietary implementation
return score
No surprise there. Of course it can work with that.
But what about this?
def calculate_risk_score(customer, transactions):
"""
Calculates a normalized risk score from customer
profile information and transaction history.
Returns a value between 0 and 1.
"""
return 0.0
The implementation is gone.
The purpose remains.
The interface remains.
The context remains.
Can the model still help?
Can it still explain the surrounding code, generate tests, suggest refactorings, review architecture, or answer developer questions?
I didn't know. But I wanted to find out.
Going down the rabbit hole
The deeper I looked, the more interesting the question became.
Modern coding models derive a surprising amount of value from things like:
- Naming conventions
- Interfaces and signatures
- Architecture pattern
- Code comments
- File structure
- Surrounding context
In many situations, they seem to care less about implementation details than we instinctively assume.
Not always. But often enough to make me curious.
And curiosity eventually turned into an experiment.
That experiment became Kiri
Kiri started from a very simple idea:
What happens if implementation details are removed before they leave the machine?
Instead of forwarding source code unchanged, Kiri attempts to replace selected implementations with higher-level descriptions while preserving enough context for the model to remain useful.
Not because I believe implementation details never matter. They absolutely do.
But because I wanted to explore a different question: How much usefulness survives when implementation details disappear?
The workflow is intentionally simple:
- A coding assistant sends a prompt.
- Kiri intercepts it.
- Protected implementations are replaced with functional descriptions.
- The modified prompt is forwarded to the model.
- The model responds normally.
The interesting part isn't the proxy itself. The interesting part is understanding where this approach works—and where it doesn't.
Measuring intuition
At this point I had plenty of opinions. What I didn't have was data.
So I built a benchmark suite.
Not to prove that redaction always works (it doesn't), and not to prove that models never need implementation details (they often do).
Instead, I wanted to understand:
- How much code could be removed
- How much context could be preserved
- Which approaches worked best
- Where the idea breaks down
Some tasks degrade quickly. Others remain surprisingly resilient.
The results ended up being at least as interesting as the original idea.
What surprised me most
The biggest surprise wasn't that redaction sometimes worked.
It was realizing that source code contains multiple layers of information:
- Interfaces
- Intent
- Architecture
- Business rules
- Proprietary logic
- Competitive knowledge
Not all layers have the same value. And not all layers are equally necessary for every AI-assisted task.
That realization changed how I think about AI adoption.
Final thoughts
I'm not claiming to have solved the problem. If anything, the more I explored it, the more complicated it became.
But I do think we should challenge one common assumption: Cloud AI may not need to see every implementation detail to remain useful.
And if that's true, then perhaps the conversation shouldn't be "Should we use AI?", but rather:
"What information does AI actually need?"
💬 Let's discuss!
I'd genuinely love to hear how other teams are approaching this problem.
- Are AI coding tools fully allowed in your company?
- Are they restricted or completely banned?
- Are we sending more code to AI than we actually need to?
Let me know your thoughts in the comments below!
🔗 Project Links
- Website: Github/kiri
- GitHub Repository: PaoloMassignan/kiri (Leave a ⭐ if you like the concept!)
- Live Demo: kiri-demo
- Benchmark Details: Check the full data directly in the Kiri Benchmark Section (Nota: punta alla sezione corretta del tuo README)
Top comments (2)
This is a useful distinction. I’d also separate “implementation hidden” from “context still sensitive”: names, interfaces, comments, tests, and surrounding architecture can reveal a lot even when the function body is redacted. The strongest version of this approach probably needs a task-by-task policy, where refactors/tests/docs each get different disclosure levels instead of one global “redact code” switch.
That's actually one of the questions I've been struggling with.
Once you start thinking about it, implementation code is only one layer of information. Names, interfaces, comments, tests, architecture and even file structure can leak quite a lot of knowledge.
I'm curious: where would you draw the line in practice?
For example, would you consider method names and signatures generally acceptable to expose, while treating comments and tests as more sensitive? Or do you see the disclosure policy being driven primarily by the specific task (refactoring vs testing vs documentation)?