In early 2023, I spent about three months consulting for an engineering org that was, by most measures, doing everything right. They had adopted an LLM-assisted coding tool across the whole team, had run a proper rollout with training and champions, and had given it six months to show up in their velocity metrics. When I arrived, they brought me in because the velocity metrics were flat. The engineers were not happy about it.
Talking to engineers there, the complaint was consistent: the suggestions were often good for the immediate function but wrong in context. The tool would suggest a data access pattern that was already deprecated in their codebase. It would generate error handling that did not match the conventions in the files two levels up the call stack. It would propose tests that duplicated ones already in the test suite. Every suggestion required the engineer to do a second round of research to verify it was not breaking something downstream. The tool had shifted work from writing to reviewing, without actually eliminating it.
The context window problem is structural
The root issue is not that autocomplete tools are poorly built. It is that they operate at the wrong level of granularity for the problem engineering teams actually have. A function-level suggestion tool has access to, at best, a few thousand tokens of surrounding context. That is enough to understand the function you are in. It is not enough to understand the module, the service, the conventions that evolved over three years of team decisions, or the six other places in the codebase where similar patterns are handled differently for reasons that made sense at the time.
The engineers at that team were spending 40 percent of each sprint in review, specifically reviewing LLM-generated code suggestions. That is not a productivity gain. That is work that moved from writing to verification without decreasing in total volume.
I came away from that engagement with a question: what would a tool look like that starts from the whole repository rather than from the current file? Not in a "context window big enough to fit everything" sense, but in the sense of actually understanding the structure: the module boundaries, the import graph, which files change together, which test files exercise which source files.
Why a pull request, specifically
The PR format was not an aesthetic choice. It was a forcing function.
If you build a tool that suggests code inline, the output is invisible to the rest of the team. There is no record of what was generated, what was accepted, what was modified. There is no review step. There is no artifact that can be discussed or reverted cleanly. The code just appears in commits.
A pull request is a different contract. It is a named, scoped, attributable unit of change. It has a description explaining what changed and why. It triggers review. It can be accepted, rejected, or commented on. When it merges, there is a clear record. When something goes wrong after merge, there is a clear artifact to investigate.
From an engineering organization's perspective, a PR is also an accountability unit. If an autonomous agent opens a PR, a human engineer reviews it before it merges. That review step is not bureaucracy. It is the mechanism by which the team verifies that the change is correct, that it fits the codebase conventions, and that the stated intent matches the actual diff. Building Codepylon around PRs was a deliberate choice to keep humans in the loop at the decision point that matters: before the code lands in main.
Starting Codepylon in Los Angeles, bootstrapped
I started building Codepylon in the second half of 2023 in Los Angeles. I was three people for the first six months: me, Amara joining part-time while finishing other commitments, and Kwame coming on three months later. We did not raise outside funding, and we have not since. That choice shaped how we built the product.
When you are bootstrapped, you build things that work or you do not have a company. There is no runway that lets you ship something mediocre and iterate toward correctness over the next 18 months. We had to get the repository indexing right before we could open a PR on anyone's real codebase, because the first bad PR would be the last.
The first version of what became the context graph was embarrassingly simple: just an import graph, nothing else. Every Python module pointing to its dependencies. Traversed depth-first to assemble context for the agent. It worked well enough on toy codebases and completely wrong on real ones, where the import graph and the actual call graph diverge significantly because of dynamic dispatch, dependency injection, and the dozens of other patterns that real codebases use.
The evolution from that to the current context graph architecture, which tracks module boundaries, test coverage, change frequency, and call paths, took about eight months of working directly with engineers who were willing to let us run experimental jobs on their staging repositories. Their feedback was not "the code is wrong." It was "the code is technically correct but it is not how we do things here." Capturing "how we do things here" turned out to be the hardest problem in the product.
What we are still getting wrong
I want to be clear about the current limits because I find that honesty here builds more trust than overselling.
Codepylon handles well-defined, bounded tasks on codebases that have consistent conventions. "Patch this CVE." "Migrate this module from Python 2 to Python 3." "Add test coverage for this file." Tasks where the success criteria are clear and the scope is defined.
It handles poorly: tasks that require product judgment, tasks where the right answer depends on business context the agent cannot read, and highly customized codebases where conventions are so idiosyncratic that the agent cannot infer them from the code alone. We are working on all of these. But a tool that tells you it can do everything is a tool that will do your production incident for you eventually, and I would rather be honest about the current boundary.
The goal we are working toward is an agent that earns trust incrementally, one merged PR at a time. Not a magic box that rewrites your codebase overnight. The overnight rewrite story is what makes teams skeptical, and that skepticism is earned. The teams we work with that get the most value are the ones that treat Codepylon the way they would treat a new junior engineer: give it well-scoped tasks, review its PRs carefully for the first few months, and expand the scope as trust accumulates.
That is what we are building toward. It is slower than the magic-box story. It is also the only version that is actually true.