Contribute Real Code as a Designer
Craft
AI
Computer Science
You meticulously designed a product experience. You thought through every interaction, state, and pixel. Then you handed it to engineering and hoped the details would survive.
The feature shipped. It worked. But the hierarchy was muddy, the spacing drifted, and important states were missing. The functionality was mostly there, but it was not the thing you designed.
Historically, you would annotate screenshots, run UI reviews, and argue to fit polish into an already packed sprint. That still has a place. But AI has made code dramatically cheaper. In the time it takes to document a deviation and convince someone else to fix it, you can often fix it yourself.
Earn access
How do you even get access to the production codebase?
Start by understanding the engineers you work with. They care about product quality, but they don't have your design eye, and they many concerns to juggle beyond design polish. They also carry the consequences when a change breaks production.
Build a real relationship with your tech lead before you need something. A weekly or biweekly one-on-one can help. Learn what they are trying to accomplish, where the team is under pressure, and what their posture towards design is. How design mature are they? Do they seek a higher design bar but lack the skills or time to implement it? Or do they not believe design is very important?
It actually doesn't matter which of those they believe. What matters is how you frame things based on their needs and motivations.
For example, you could frame your initial codebase access as:
I want to explore the codebase so I can understand our constraints and work with the team more effectively.
Or you could frame it as:
I want to ship design polish so we can meet our design bar more easily without burdening you and your team.
Many engineering teams have a new-hire setup guide. Follow it as far as you can on your own. Keep a short list of the permissions and errors that genuinely require help, then book one focused session to resolve them. Most things can be resolved via your AI tool of choice, but certain things require an admin to provision you access or credentials.
Trust opens the path to the codebase.
Be a good guest
Once the application runs locally, use your AI agent to build a working mental model. Tell it your technical proficiency and ask for concise explanations in plain English.
Useful questions include:
- What front-end technologies and conventions does this application use?
- Where do the components and styles for my product area live?
- What are the core entities in the data model, and how are they related?
- Create a diagram of the path data takes from the interface to the back-end and back.
- Look at the Git history. Who has worked on this area and what patterns did they follow?
Designers often delay action because they think contribution is gated on understanding everything. You do not need an exhaustive understanding of the system before you contribute. You will never understand everything. Experienced engineers still investigate unfamiliar parts of their own systems.
Instead, make the change smaller than your uncertainty.
Land your first change
Your first contribution should be small, visible, useful, and boringly safe.
Start with front-end polish on a small feature you already understand. Fix spacing, typography, responsive behavior, an interaction state, or an accessibility issue. Avoid changing architecture, introducing a new library, or quietly redesigning neighboring screens.
Start where mistakes are small and reversible.
Many, perhaps most, engineers are not thrilled to make endless styling tweaks. You're adding value and doing them a favor by taking that on.
Ask your tech lead what you and your AI should be prepared to answer before merging code into the production codebase. Different teams care about different risks. Get their standards first.
When your AI proposes an implementation, grill it against that list. Ask what existing pattern it copied, what alternatives it considered, how it verified the result, and what could break. Keep asking for simpler explanations until you can defend the decision in your own words.
The agent can write the code. You are still accountable for the change.
You'll need to use git to create a branch so you can track, organize, and then merge your changes.
If Git still feels opaque, start with Git for Non-Engineers. You need the mental model, not a collection of commands.
Your merge request should make approval easy:
- Solve one clearly stated problem.
- Show the visual result with a screenshot, preview deployment, or a video.
- Explain why the implementation fits the codebase.
- State how you tested it.
- Make sure CI is green. You can learn more about CI in my git blog post and workshops.
- Call out any uncertainty instead of hiding it.
The safest first contribution is useful, small, and easy to undo.
Grow your scope
The fastest way to earn more scope is not to ask for bigger projects. It is to make your current participation valuable to everyone else.
Learn to review other people’s front-end pull requests. Ask your tech lead what it would take for you to become a competent reviewer. You will get closer to changes that affect the customer experience, learn the team’s standards, and increase the team’s review capacity.
That creates reciprocity. You help engineers catch experiential issues. They have more reason and more capacity to review your changes promptly.
Over time, you can move from CSS polish to component behavior, then to small backend or full-stack changes in a product area you know well. Increase scope only as your understanding and the team’s trust increase with it.
Be mindful of the review burden you create. A change is not free because AI produced it quickly. Someone still has to understand it, test it, maintain it, and own the failure modes.
Every pass through the loop expands what you can own.
Keep it simple
Most changes designers want to make are front-end changes.
Engineers should spend their time on the work that most needs their expertise. Designers are professionally oriented toward experiential verification and refinement. When a designer can safely close the last-mile gap, the product gets better and engineering gets time back.
This only works if you keep the scope tight, respect the system, and build trust over time. Roll up your sleeves. Ship one piece of polish. Learn from the review. Then do it again.
The point is not to become an engineer. It is to become a designer with a larger sphere of influence and a more direct relationship with the thing you are making.
Start small. Who knows what you will be able to build from there?