LegacyFixer

A GitHub App that detects outdated Python dependencies and can optionally open a pull request with verified updates

Comment

Inspiration

LegacyFixer began as an experiment in what sustained human–AI collaboration could make possible.

I do not have a formal background in software development. My background is in psychology, sociology, research, and fine arts, but I have always been strongly interested in technology. After years of working extensively with AI, I wanted to test whether someone without conventional software-development training, working closely with an AI system, could take a technically complex idea all the way from concept to a functioning, tested product — not merely generate a prototype.

Through our discussions, the idea gradually became more concrete. We chose software dependency maintenance as a problem worth solving, and LegacyFixer evolved into an actual GitHub App.

What it does

LegacyFixer is a GitHub App for Python repositories.

It detects outdated dependencies, evaluates whether an update requires action, and can optionally create a pull request with proposed changes.

Its behavior is deliberately conservative: detection, evaluation, and execution are separate steps, and an outdated dependency does not automatically trigger a modification.

How I built it

I built LegacyFixer through an iterative human–AI workflow.

Because I did not come from a programming background, much of the process involved understanding the architecture while building it: how the files relate to one another, how GitHub Apps work, how authentication and installations are handled, how the backend communicates with the database, how jobs are processed, and how the application is deployed.

The AI assisted with architecture, code generation, debugging, testing, and technical explanations. My role was not simply to request code and accept the result. I continuously evaluated whether the system behaved as intended, questioned design choices, detected inconsistencies and architectural drift, tested the application, and made the product-level decisions about what LegacyFixer should and should not do.

The resulting system uses Python, GitHub Apps and APIs, PostgreSQL, Google Cloud Run, Cloud SQL, Docker, and automated tests.

Challenges I ran into

The largest challenge was working in a technical domain I was learning while simultaneously building a real product.

I often had to understand enough of an unfamiliar system to decide whether an implementation was actually correct rather than merely plausible. As the project grew, keeping track of files, components, data flows, deployment infrastructure, and GitHub integration became increasingly important.

There were also substantial engineering challenges: dependency formats vary between repositories, installation and synchronization state must remain consistent, cloud components have to work together, and automated changes must not be triggered simply because a newer package version exists.

The project therefore became both a software-engineering problem and an experiment in how effectively a non-programmer and an AI can divide cognitive work.

Accomplishments that I'm proud of

LegacyFixer became a functioning GitHub App rather than remaining an AI-generated demonstration.

It can synchronize installed repositories, analyze Python dependencies, distinguish between cases that require action and cases where no action should be taken, and optionally create pull requests.

I also built and used dedicated test repositories for different dependency structures and update scenarios, deployed the application on real cloud infrastructure, created its public website, and took it through the practical steps required to turn a technical experiment into an actual product.

For me, an equally important result is methodological: the project demonstrated that sustained human–AI collaboration can allow someone without a conventional software-development background to understand, build, test, and operate a non-trivial software system.

What I learned

I learned a considerable amount of software engineering by having to make real decisions rather than studying it abstractly.

More importantly, I learned what AI assistance does and does not replace. It can provide technical capability extremely quickly, but someone still has to maintain the conceptual model of the system, notice when the work is drifting, question assumptions, test results, and decide what the product is supposed to do.

LegacyFixer also taught me a design principle that later became important in other projects: detection, evaluation, and execution should not be collapsed into a single automated step.

What's next for LegacyFixer

LegacyFixer is now less constrained by the question of whether it can be built and more by the question of whether it can find real users.

The next work therefore focuses on visibility, broader validation on real repositories, refinement of the dependency-evaluation logic, and observing whether developers find the product useful enough to adopt.

The technical system can continue to evolve, but the next experiment is no longer primarily about implementation. It is about whether a product created through this kind of human–AI collaboration can survive contact with an actual market.

Built With

Share this project:

Updates