Mature, well-documented SDK with clear examples, but the monorepo is dense, dev setup is heavy, and contributor onboarding could be sharper.
last scored 2026-06-15
Readiness lenses
The same repo, two ways: how ready it is for an AI coding agent, and for a human newcomer. Switch lenses to see each one's score and checks.
How ready the repo is for an AI coding agent to read, build, and operate it.
26 of 35 checks passed across 6 categories.
Machine Orientation
6 checks passed2 problems found
- lowllms.txt present
An llms.txt is the emerging machine-orientation standard — a curated map for LLMs.
Fix: Add an llms.txt pointing at the key docs and entry points.
- lowArchitecture doc
An ARCHITECTURE doc hands an agent the module map instead of making it infer one.
Fix: Add an ARCHITECTURE.md describing the major components and how they fit.
- README present — An agent reconstructs what the repo is and how to work in it from the README first.
- Agent instructions file — AGENTS.md / CLAUDE.md is the direct, machine-read channel for entry points and conventions.
- Agent instructions stay lean — A bloated instructions file burns context and measurably hurts more than it helps.
- Repository description set — The one-line description is the fastest orientation signal an agent reads.
- Topics set — GitHub topics situate the repo's domain and stack for an agent at a glance.
- Contribution conventions are written down — A contributor guide is where an agent learns the branch, commit, and review conventions it must follow.
Reproducible Setup
4 checks passed2 problems found
- lowEnv template present
A .env.example tells an agent which configuration keys it must supply to run.
Fix: Ship a .env.example listing every required key with placeholder values.
- lowDev container
A .devcontainer gives an agent a one-command, fully-declared environment.
Fix: Add a .devcontainer so the toolchain is declared, not assumed.
- Lockfile committed — Without a lockfile two clones can resolve different dependency trees — the build isn't reproducible.
- Runtime / toolchain pinned — An unpinned runtime makes an agent guess the version a clean environment needs.
- Version pins are exact — A floating pin (a bare major, or a range) still drifts between installs.
- Container or dev-container — A Dockerfile / compose / devcontainer removes 'works on my machine' from setup.
Code Navigability
1 check passed1 problem found
- lowTypeScript strict mode on
Strict typing gives an agent typed signatures to anchor an edit on, not guesses.
Fix: Turn on `strict` in tsconfig.json.
- Conventional source layout — A recognised src/ · lib/ · app/ layout lets an agent localise code without spelunking.
Verification Surface
6 checks passed1 problem found
- lowBuild command
A documented build command is the discoverable way for an agent to produce artifacts.
Fix: Add a `build` script that produces the distributable.
- Tests present — Runnable tests are the ground truth an agent checks its own edits against.
- Test command defined — A `test` script is the documented, discoverable way to run the suite.
- Lint command defined — A linter an agent can run catches a class of mistakes before they ship.
- CI configured — Readable CI is the feedback loop an agent reads to know what 'green' means here.
- Task runner present — A Makefile / Taskfile / justfile gives an agent a single index of the project's commands.
- Typecheck command — A typecheck script lets an agent catch type errors before they ship.
Agent Safety
6 checks passed2 problems found
- mediumSecurity policy
A SECURITY.md is where an autonomous security agent reads this repo's rules before acting on it.
Fix: Add a SECURITY.md stating the disclosure channel and the repo's security rules.
- lowAutomated dependency updates
Dependabot / Renovate keeps dependencies patched without a human in the loop.
Fix: Enable Dependabot or Renovate.
- No committed .env — A tracked real .env hands secrets to anything — including an agent — that reads the repo.
- No exposed secrets — Secret-shaped literals in tracked files are a live credential leak.
- .gitignore covers env files — An ignore rule for .env is what keeps the next careless commit from leaking secrets.
- CODEOWNERS present — CODEOWNERS marks the 'don't touch without review' zones an agent should respect.
- .gitignore present — A .gitignore is the first guard against an agent committing secrets or build junk.
- License makes the code reusable — Without a license an agent cannot safely copy, redistribute, or vendor any of this code.
Context Economy
3 checks passed1 problem found
- lowNo oversized source file
A single file in the hundreds of KB blows past an agent's effective context window.
Fix: Split the largest files along their natural seams.
- Dependencies not vendored in — A committed node_modules / vendor tree drowns the real signal an agent needs.
- Build output not committed — Generated dist/ · build/ output is noise an agent has to read past.
- Generated / vendored files marked — A .gitattributes linguist marker tells tools (and agents) what to skip.
How ready the repo is for a human newcomer to understand, set up, and contribute.
72 / 10017 of 25 checks passed across 6 categories.
First Impression
85Clear, professional README with a strong narrative and copy-pasteable quick-start.
The README immediately explains what E2B is (open-source infrastructure for secure sandboxes), why it exists, and provides separate quick-start code for both JavaScript and Python with actual working examples. The visual badges for PyPI and NPM downloads signal maturity and adoption. However, the README could better explain the distinction between the base SDK and specialized packages (Code Interpreter SDK, CLI) upfront.
Getting Running
62SDK installs are trivial, but the dev setup for contributing is complex and poorly documented.
Installing the SDK itself (npm i e2b, pip install e2b) is straightforward, and the quick-start requires only an API key. However, there is no DEV.md or explicit local dev setup guide visible in the README—only a bare DEV.md file in the root (likely intended but not excerpted). The monorepo uses pnpm@9.15.5 with overrides, Changesets, and Docker for codegen, but a newcomer clone-to-test path for contributing to the core SDKs is not explicitly laid out.
Finding Your Way
68Reasonable structure (split by packages), but the navigation is not self-evident and lacks an architecture overview.
The file tree shows clear package boundaries (cli, js-sdk, python-sdk, connect-python, etc.), but there is no top-level architecture or package-dependency diagram. The README does not explain which packages are user-facing (js-sdk, python-sdk) versus internal tooling (cli, connect-python). A newcomer would struggle to understand whether to focus on the SDK or the CLI or both, and how they interact.
Path to Contribute
65CONTRIBUTING.md exists and issue templates are set up, but the dev workflow and test suite expectations are vague.
The snapshot shows CONTRIBUTING.md, .github/ISSUE_TEMPLATE/, and a Makefile with codegen and test targets. However, without seeing the full CONTRIBUTING.md or test documentation, a newcomer cannot confidently run tests or understand the contribution workflow (e.g., how to trigger a release via Changesets, how to test locally without the backend). The presence of GitHub Actions (js_sdk_tests, python_sdk_tests) implies tests exist but they're not linked from the README.
Signs of Life
82Active, well-maintained: recent commits, regular releases via Changesets, and solid issue/PR workflow.
Last pushed on 2026-06-15 (very recent), 55 open issues (healthy), 12,598 stars (mature), and the .changeset/ folder with multiple pending release entries shows an active release cadence. GitHub Actions workflows for testing (CLI, JS, Python SDK) and releases (publish_packages.yml, publish_candidates.yml) demonstrate a professional CI/CD setup and ongoing maintenance.
Open Door
78Apache 2.0 license is clear and welcoming; no visible code of conduct or security policy.
The LICENSE file is present (Apache 2.0), which is permissive and unambiguous—no legal barrier to contribution. However, there is no CODE_OF_CONDUCT.md or SECURITY.md visible in the snapshot, and no help/support channels (discussion forum, Discord, Twitter) are mentioned in the README. The homepage link (e2b.dev/docs) should serve as a fallback but is not explicitly called out in the README for help.
First Impression
3 checks passed0 problems found
- README present — The README is the first screen — with none, a newcomer has nothing to land on.
- Repository description set — The one-line description sets expectations before a newcomer even opens the README.
- Topics set — Topics situate the project's domain at a glance and help a newcomer find it.
Getting Running
4 checks passed2 problems found
- lowEnv template present
A .env.example shows a newcomer exactly which settings they must fill in to run it.
Fix: Ship a .env.example listing every required key with placeholder values.
- lowOne-click dev container
A .devcontainer lets a newcomer start in a cloud IDE with zero local setup.
Fix: Add a .devcontainer for a one-click, batteries-included environment.
- Lockfile committed — Without a lockfile a newcomer's install resolves differently and hits errors the docs don't mention.
- Prerequisite versions pinned — Unpinned prerequisites are the classic 'works on my machine' first-run failure.
- One-command environment — A Dockerfile / compose / devcontainer turns a fiddly setup into one command.
- Versions pinned exactly — A floating version still drifts — a newcomer can hit a break the maintainer never saw.
Finding Your Way
1 check passed2 problems found
- mediumArchitecture / overview doc
An overview hands a newcomer the map instead of making them reconstruct it.
Fix: Add an ARCHITECTURE.md (or a 'Project layout' README section) naming the key directories.
- lowNo oversized source file
A single thousand-line file is a wall a newcomer bounces off.
Fix: Split the largest files along their natural seams.
- Conventional source layout — A familiar src/ · lib/ · app/ layout lets a newcomer guess where things live.
Path to Contribute
5 checks passed1 problem found
- lowPull-request template
A PR template tells a first-time contributor what a good change includes.
Fix: Add a PULL_REQUEST_TEMPLATE.md.
- CONTRIBUTING guide — A CONTRIBUTING guide is the difference between a guessed and a guided first PR.
- Issue templates — Issue templates show a newcomer how to file something useful — and that contributions are welcome.
- Test command defined — A documented test command lets a contributor check their change before opening a PR.
- Lint command — A linter lets a first-time contributor catch style issues before review.
- Task runner — A Makefile / Taskfile gives a contributor a single index of the project's commands.
Signs of Life
2 checks passed1 problem found
- lowAutomated dependency updates
Dependabot / Renovate activity is a visible heartbeat of ongoing maintenance.
Fix: Enable Dependabot or Renovate.
- Tests present — A test suite signals a project that's cared for, not abandoned.
- CI configured — Green CI on every change tells a newcomer the project is actively kept working.
Open Door
2 checks passed2 problems found
- lowCode of conduct
A code of conduct states the social ground rules that make it safe to step in.
Fix: Add a CODE_OF_CONDUCT.md (the Contributor Covenant is the de-facto standard).
- lowSecurity policy
A SECURITY.md tells a newcomer how to report a problem responsibly.
Fix: Add a SECURITY.md describing how to report a vulnerability.
- License present — With no license the project isn't legally reusable — the door is shut however friendly the README.
- License is a standard one — A non-standard or custom license is a legal question mark a newcomer won't resolve.
Where the grip slips
- highGetting Running+18 pts if fixed
Dev setup not documented; monorepo complexity hidden.
A newcomer cloning the repo has no clear path to build and test locally. The root Makefile shows codegen and test targets, but no explicit walkthrough for setting up a dev environment is visible in the README or root. The monorepo uses pnpm, Changesets, Docker, and generated code—all heavy dependencies—but no guide explains prerequisites or how to bootstrap.
Fix: Add a 'Development' section to the README or reference DEV.md clearly at the top. Include: prerequisites (Node.js version, pnpm, Docker), bootstrap steps (pnpm install, make codegen), and how to run tests for a single package (e.g., 'cd packages/js-sdk && pnpm test'). Link to it from 'Contributing' section.
- highFinding Your Way+16 pts if fixed
No architecture overview or package dependency map.
The file tree lists packages (cli, js-sdk, python-sdk, connect-python, etc.) but does not explain their relationships, which are public-facing, or where to start. A newcomer cannot quickly map whether the SDKs depend on the CLI, whether the infrastructure (infra/) is user-facing, or how code-interpreter relates to the base SDK.
Fix: Add a 'Project Structure' section to the README describing each top-level package, its role, and its audience. Example: 'js-sdk: User-facing SDK for JavaScript. cli: Command-line tool for managing templates and sandboxes. connect-python: Protobuf code generator (internal tooling).' Include a rough dependency tree if helpful.
- highPath To Contribute+15 pts if fixed
CONTRIBUTING.md and test expectations are not visible or clear.
The snapshot shows CONTRIBUTING.md exists, but its contents are not provided. Without seeing it, a newcomer cannot know: how to set up tests, what test commands to run, PR/commit conventions, or how Changesets affect the workflow. This is a blocker for confident first contributions.
Fix: Ensure CONTRIBUTING.md is comprehensive and linked from the README. Include: local test commands (e.g., 'pnpm test' or 'make test' at the root and per-package), explanation of Changesets (when/how to add a .changeset file), code style/linting (eslint, prettier, vale), and a sample PR/review workflow. Link it prominently in the README as 'Contributing'.
- mediumOpen Door+8 pts if fixed
No code of conduct or security reporting mechanism.
While Apache 2.0 is clear, there is no CODE_OF_CONDUCT.md or SECURITY.md to signal values, community standards, or how to report vulnerabilities. This is a gap in signaling a safe, welcoming environment.
Fix: Add CODE_OF_CONDUCT.md (e.g., adapted from Contributor Covenant). Add SECURITY.md with instructions for responsible vulnerability disclosure (e.g., security@e2b.dev or equivalent). Link both from the README's 'Contributing' or 'Community' section.
- mediumFirst Impression+8 pts if fixed
README does not explain SDK variants or entry points.
The README jumps to 'Install SDK' without clarifying: Are there multiple SDKs to choose from? What is the relationship between the base SDK and Code Interpreter SDK? The 'Run your first Sandbox' section is great, but does not guide which SDK variant is appropriate for different use cases.
Fix: Add a 'Which SDK should I use?' section explaining: base SDK (simple sandbox commands), Code Interpreter SDK (Python/code execution), and CLI (template management, local testing). Provide decision tree or use-case examples so users pick the right entry point without confusion.
- lowOpen Door+6 pts if fixed
No help/support channel or community link in README.
The README links to docs and cookbook but does not mention where to ask questions (GitHub Discussions, Discord, email) if stuck. A newcomer hitting a wall has no obvious next step beyond trial-and-error or closing the tab.
Fix: Add a 'Getting Help' or 'Support' section to the README with links to: GitHub Discussions (if enabled), a community chat (Discord/Slack), email contact, or the main e2b.dev site. Example: 'Stuck? Ask in [GitHub Discussions](link) or join our [Discord](link).'
Show your score
[](https://latch.fyi/e2b-dev/e2b)Share this analysis
https://latch.fyi/e2b-dev/e2bFixed some issues? Re-analyze to measure your progress →
Copy the whole report
Grab the entire verdict in one go — a Markdown block for a README or an issue, plain text, or a prompt you can paste straight into an LLM.