Built for the codebases that autocomplete ignores
Codepylon was started in Los Angeles in 2023. The problem Ryan kept running into: engineering teams with decade-old Python 2 pipelines and hundreds of unresolved CVEs, using AI tools that understood only the file currently open in the editor.
Why legacy modernization is slow, and what we did about it
In early 2023, Ryan spent three months working alongside a 50-person engineering team at a logistics company in Los Angeles. Their situation was familiar: a Python 2 analytics pipeline that needed migration, a Rails 3 monolith that needed modularization, and a backlog of 200 tech-debt tickets that had sat untouched for two years.
They tried Copilot. They tried GPT-4 with custom prompts and context-stuffing. The problem was always the same: the suggestion was plausible in isolation but wrong in context. The model had no idea that DataPipeline.process() was called in 14 different ways across 6 services, or that removing legacy_format_date() would break a webhook handler in a completely different module. Engineers spent more time reviewing and rejecting suggestions than they saved accepting them.
The observation was not subtle: the problem is not that AI cannot write code. The problem is that existing tools do not read the codebase before writing. Pylon reads first. Before every job, it builds a directed dependency graph of the repository: which modules import what, which tests cover which paths, which functions have zero callers, how recently each file was changed. Then it writes code that fits.
We are a small team in Los Angeles, bootstrapped, working with a focused set of early-access engineering teams. We ship carefully and document everything, which is the only way to earn trust with production code. Pylon does not open a PR it is not confident in. When it is not confident, it stops and says why.
Founded in Los Angeles, CA. Bootstrapped from day one.
Specialized agents: Migrate, Patch, Refactor, Test. Each purpose-built for one class of problem.
Lines of code Pylon can read and index per repository. Monorepo-ready.
Small team, focused problem
Ryan Osei
CEO and Founder
Amara Diallo
Agent Systems Engineer
Kwame Asante
Infrastructure and Indexing Engineer
The constraints we build inside
Pylon stops rather than guesses
If the dependency graph analysis is ambiguous, or if the agent cannot determine that a proposed change is safe, it stops and surfaces what it found. It does not open a PR with a "TODO: verify this" comment inside it. Your team reviews decisions, not cleanup.
Your repository content is not our training data
Repository content is loaded for the duration of a job and deleted when the job completes. It is not retained, not logged beyond the job audit record, and not used to fine-tune any model. This is a design constraint enforced at the infrastructure level, not a policy that can be changed by a checkbox.
We say what is done and what is not
Our security page says "SOC 2 Type II in progress, expected Q1 2027." Our changelog documents when something broke, not just when we shipped. An engineering team trusting us with production code deserves accurate status, not optimistic framing.
Four agents that actually work
We are not building a platform with 40 integrations and a marketplace. We are building four agents that do one class of codebase work each, deeply and correctly. Pylon-Migrate should handle a Rails 4 to Rails 7 migration without human intervention. That takes focus, not feature count.