DEV Community: PaoloMassignan

Are We Sending More Code To AI Than We Actually Need To?

PaoloMassignan — Wed, 10 Jun 2026 14:13:39 +0000

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)

My Company Wouldn't Let Me Use Claude Code. So I Built a Proxy That Redacts Code Locally

PaoloMassignan — Fri, 05 Jun 2026 07:16:01 +0000

AI coding assistants are getting incredibly good. Tools like Claude Code, Cursor, and Windsurf can explain unfamiliar code, navigate large codebases, generate boilerplate, and often solve problems faster than a traditional web search.

But there is a problem that many engineering teams are quietly struggling with: How do you use cloud-based AI tools without exposing proprietary source code?

Imagine asking an AI assistant to help refactor a critical module. To get a useful answer, you need to provide context. That context may contain:

Proprietary algorithms
Customer-specific workflows
Internal APIs
Database schemas
Business rules accumulated over years
Naming conventions that reveal how your systems work

For many organizations, that risk is enough to stop the conversation before it even starts. In many cases, the concern exists even when the AI provider offers enterprise-grade guarantees, private deployments, or strong privacy commitments.

As a software manager working with large proprietary codebases, I kept running into the same dilemma:

Developers wanted the productivity gains of AI-assisted development.
The company wanted to protect its intellectual property.

Both positions were perfectly reasonable. The challenge was finding a middle ground.

What If Sensitive Code Never Left the Network?

Instead of asking whether AI coding assistants should be allowed, I started asking a different question: «What if the sensitive parts of the code never left the network in the first place?» Could developers still benefit from AI assistance if the model only saw a sanitized version of the code?

That idea eventually became Kiri.

The Core Idea

Kiri is an open-source, on-premises proxy that sits between AI coding tools and cloud LLM providers.

Before a request reaches the model, Kiri intercepts it locally, identifies proprietary implementation details, and replaces sensitive information with placeholders. The sanitized request is then forwarded to the AI provider, and the response is returned to the developer.

For example, instead of sending your raw business logic:

// Before Kiri
 public static decimal CalculateDiscount(Order order) {
      var tier = _tiers[order.Customer.Tier];
      return Math.Min(tier.Base + order.TotalUnits * tier.PerUnit, tier.Cap);
 }

The external model receives:

// After Kiri
  public static decimal CalculateDiscount(Order order) {
      // [PROTECTED: implementation is confidential]
  }

The overall structure of the problem remains understandable, while the implementation details do not. The goal is not perfect secrecy. The goal is reducing the amount of sensitive information that leaves the organization while preserving enough context for the AI assistant to remain useful.

The Hard Part Wasn't Building the Proxy

The most interesting challenge turned out to be something else entirely: How much information can you remove before the AI stops being useful?

Remove too little and you risk exposing information you care about. Remove too much and the model can no longer understand the problem. Finding that balance turned into a series of experiments.

In some scenarios, the model remained surprisingly useful even after aggressive redaction. In others, removing key information quickly degraded the quality of the answers. What I learned is that privacy is not a binary choice between "send everything" and "send nothing." There is a large and mostly unexplored design space in between.

Why Not Just Use Enterprise AI?

This is a reasonable question. Many AI providers already offer enterprise agreements, private deployments, and data-retention guarantees. For some organizations, that is probably enough.

For others, legal requirements, internal policies, customer contracts, regulatory concerns, or simple risk aversion still make external code sharing difficult. Kiri is not intended to replace enterprise offerings. It is an attempt to explore another option.

Measuring Instead of Guessing

One unexpected result of the project was the benchmark itself. I quickly realized that discussions about AI privacy often become theoretical. Everyone has opinions, but very few teams have a way to quantify the trade-off.

One thing I wanted from the beginning was a way to measure the impact instead of endlessly debating it. Most privacy tools make claims; Kiri lets you measure.

The project includes a benchmark tool that can run directly against your own repository. Rather than trusting my assumptions, you can test the approach on your own codebase and see what happens.

The benchmark helps answer questions such as:

How much code is being redacted?
Which identifiers remain visible?
How aggressive should the redaction strategy be?
How much structural context is still preserved?

I found this far more useful than theoretical discussions about AI privacy because every codebase is different. A strategy that works well for one project may be completely inappropriate for another.

Why Open Source?

I released Kiri as an open-source project because I suspect many teams are facing the same dilemma. Developers want the benefits of AI-assisted development, while security, legal, and engineering leadership want stronger guarantees around intellectual property.

Those goals are often presented as mutually exclusive, but I'm not convinced they are.

Questions for the Community

I'm genuinely curious how other organizations are approaching this problem today:

Are AI coding assistants completely banned?
Are you relying on enterprise agreements?
Are you running local models?
Are you building internal gateways?
Are you taking a completely different approach?

I'd love to hear what has worked for you — and what hasn't.

Try It Yourself

If you're curious, don't take my word for it. Run the benchmark against your own repository and see how much information can be removed before the AI starts losing context. The results surprised me more than once.

Kiri is fully open source under the MIT license and includes documentation, examples, and the repository benchmark tool.

📂 GitHub: PaoloMassignan/kiri
🌐 Project Page: [kiri]https://paolomassignan.github.io/kiri/)