career bridge
Someone else's systems
Deploy into a codebase you did not write and cannot rewrite, and let strangers review it, because the review thread is the evidence.
You can build a pipeline and an agent that hold up when you attack them. Every one of them so far has run in a repository you set up, with your choices, your dependencies and your data. The job is the opposite of that, and the difference is not technical skill. It is constraint, and constraint is its own skill.
What you do
Deploy into a codebase you did not write and cannot rewrite. Pick a real open-source project with actual users, something with a working test suite and unglamorous code, and add a genuinely useful AI feature to it without reshaping the project around your feature. That constraint is the entire exercise. Read the contributing guide properly. Match the existing style, the existing configuration pattern, the existing error handling, including where you would have done it differently, because in a client's codebase you will not get to. Add no dependency you cannot defend in a single sentence. Make the feature optional and off by default, because the maintainer's users did not ask for it. Handle the case where the API key is missing, the provider is down, or the response is slow, and make certain the rest of the project behaves exactly as before in each case. Write the tests the project's conventions expect, not the tests you would have written. Then open the pull request and let strangers review it. The review is the point. Respond to every comment, including the ones you disagree with, and change what you should change. If it gets merged, excellent. If it does not, the thread is still evidence that you can work inside someone else's constraints, which is most of this job.
Done when
- A pull request is open on a project you do not own, adding an AI feature its maintainers can read and follow.
- The feature is optional, off by default, and the project behaves identically when it is disabled.
- Every new dependency is defensible in one sentence, and the count is as low as you could get it.
- Failure paths are handled: no key, provider down, slow response, malformed response.
- You have responded to review comments and pushed at least one change you did not initially agree with.
What you end up with
A public pull request on a project you do not own, with the review thread attached. The conversation is the evidence, merged or not.
If you get stuck
The common failure is picking a project so small that nobody ever reviews it, which removes the only part that mattered. Pick something with recent commits and a maintainer who answers. The other failure is rewriting the project to suit your feature, which reads to a maintainer as somebody who does not work well inside other people's systems, and that is precisely the opposite of the signal you were trying to send. When you disagree with an existing pattern, follow it anyway and explain why in the thread.