Package Intelligence for Engineers & Coding Agents
Secchi, an open-source tool for understanding package adoption, health, and ecosystem signals.
I want to explore is how coding agents make engineering decisions when we haven't already made those decisions for them. I use open source package dependencies selection as an example and show how the decision-making happens inside the coding agent workflow and eventually introduces Secchi, an open-source project I am building. Hopefully, there is something useful here to take away, ways to optimise the agent workflow even if you take Secchi out of the picture.
When agents make engineering choices
The current state shows coding agents become very much active contributors to software projects including code review process. We engineers spending a lot of time thinking about how to control them. We define skills, agent instructions, permissions, hooks, policies, and other guardrails to make their behaviour more predictable.
All of these are important parts of building a reliable agent harness. But there is another side we need to consider: how much freedom should we leave for an agent to make engineering decisions?
As engineers, we rarely work with every technical decision predetermined for us. We operate within architectural standards, security requirements, and organizational policies, but we still explore. We compare libraries, evaluate new tools, question existing choices, and sometimes replace something familiar with a better alternative.
If every dependency, framework, and implementation choice is encoded into a skill or instruction, an agent may become very consistent, but it also becomes limited to the engineering choices we already know.
We could unintentionally use increasingly capable agents to keep reproducing the same technology stack.
Good agent harnessing probably sits somewhere between these two approaches.
We still define the boundaries that cannot be crossed, particularly around security and organizational policies, but leave enough room for the agent to explore alternatives when the decision has not already been made.
Open-source dependencies are a good example
An agent may need a CLI framework, HTTP client, database driver, serialization library, or SDK while implementing a task.
Rather than always prescribing exactly which package it must use, we could allow the agent to evaluate alternatives. But knowing that a package solves the technical problem is not enough.
Example : msgspec vs Pydantic
I recently ran into this while working on serialization. I had not told the coding agent which library to use. Instead of reaching for Pydantic, which I was already familiar with, the agent suggested msgspec.
msgspec is a high-performance serialization and validation library for Python.
Whether it is the right choice still depends on the application, ecosystem compatibility, features, maintainability, and other requirements, but the interesting part for me was how the option surfaced in the first place.
If I had written a skill saying “use Pydantic for data models and serialization,” the agent would probably have followed that instruction. I would have gained predictability, but potentially lost the opportunity to consider another library that might be better suited to that particular problem. We want to benefit from the broader open-source ecosystem, not simply reproduce the technology choices we already know right ?
Generally speaking, There are key questions, I would normally care about before introducing a dependency in my project:
Is the package actively maintained?
Is adoption growing or declining?
How widely is it depended upon?
How frequently is it released?
Are there security or licensing concerns?
How does a coding agent choose a package today?
When a coding agent needs a dependency, it does not usually perform a systematic library or package health assessment. The process is more likely to look like this:
Path 1: Agent explores but not enough insights
Task → Prior knowledge / search → Basic checks → Choose → Implement
⚠️ Fast and flexible, but package health is not systematically evaluated.
Path 2: Predefined choices
Task → Read project instructions / skills → Select recommended or approved dependency → Implement
⚠️ Faster and consistent, but search and exploration are skipped.
Package intelligence as an agent capability
An agent could be instructed to perform a more thorough evaluation before introducing a dependency. After checking whether a package solves the ask, agent could gather broader signals such as:
adoption and download trends
release and maintenance activity
security signals
dependency and ecosystem health
licensing and compatibility
This gives the agent better evidence before making a choice.
The agent has to search across package registries, repositories, documentation, security sources, release histories, and other places. It has to retrieve that information, interpret it, normalize different signals, and compare candidates.
⚠️ It is expensive and hard to scale. more searches, more tool calls, more tokens, and more context consumed just to make a dependency decision.
Sure, We can give an agent better instructions, but we are still asking every agent to repeatedly gather package intelligence for itself.
What if package intelligence itself were an agent capability?
Introducing Secchi
Repo : https://github.com/kannandreams/secchi
That question eventually led me to build Secchi, an open-source package intelligence tool.
Secchi does that evidence-gathering separately. It collects package signals from different sources and exposes them in a structured form to engineers and agents.
For an agent, that intelligence can be exposed through MCP.
The agent can still discover using its existing knowledge or search.
Secchi provides the package evidence needed to make that decision with better context.
The agent still considers the repository, technical requirements, project constraints, team policies, and implementation trade-offs. Secchi adds structured, up-to-date information about the packages being considered.
The idea is to make it easier
For engineering teams, Secchi can provide better visibility into the open-source libraries used across projects and help identify changes in their adoption or health over time.
For coding agents, the same intelligence can provide additional context when exploring and selecting dependencies.
Secchi currently provides an interactive terminal dashboard with adoption trends, health signals, ecosystem distribution, reverse dependencies, health history, and version adoption.
Secchi is open source and still early. If this idea interests you, give it a try. I’m particularly interested in hearing where the package intelligence is useful, what is missing, and where it gets things wrong.
Project link : https://github.com/kannandreams/secchi
Bugs and feature ideas are welcome. And if you find the project useful, give it a ⭐ on GitHub.