30-60-90 Day Codebase Ramp Plan for Non-Engineer Hires

Non-engineers are already committing code, and the volume is growing fast enough that engineering leaders no longer get to decide this happens, only how well it goes. That alone might be a curiosity. The share of CPOs and CEOs using an AI feature inside Linear jumped from under 10% to more than 30% in six months, and that held true even at large companies, which is what makes it a mandate. Telling the CPO the same thing is a different conversation entirely.

The proof that this can go well, rather than badly, comes from epilot. In February 2026, the company opened 219 repositories and over a million lines of production code to PMs, designers, project managers, customer success, and support. Intercom's experience points the same direction: a large rollout of Claude Code to non-engineers produced a significant share of active weekly users, which rules out epilot as a lucky one-off.

None of this works by accident, though. The manager.dev account of an ungoverned rollout describes a designer who opened a pull request believing a feature was complete, when Claude had actually mocked the backend logic rather than building it. The PR was enormous, and nobody had reviewed it closely enough to catch the problem before it landed. That is the failure mode this piece is built to prevent. Whether non-engineers belong in the codebase is settled. It is how to get them there without turning the repository into a minefield, and a structured 30-60-90 ramp, built on progressively deeper access and the right query tools, is the mechanism that does it.

What codebase literacy means for someone who isn't writing code

Codebase literacy for a non-engineer has nothing to do with writing production code. It means being able to query the codebase precisely enough to get a trustworthy answer, understand what a given PR changes at the feature level, and know which team or service is responsible for a particular behavior. That is a narrower, more achievable target than "learn to code," and it is the target this entire ramp plan is built around.

Three roles need three different flavors of this literacy. A PM has to trace a feature from its ticket to its implementation, understand what a proposed change would touch before it ships, and read a PR diff well enough to know what it actually does. Support and customer success need something more diagnostic: telling whether an issue is a bug or a configuration problem, locating the service or endpoint responsible, and reading an error log clearly enough to write an escalation an engineer can act on immediately rather than having to decode it. Designers and go-to-market staff need a narrower but still real competency: finding the component or copy string that controls a given UI element, making a bounded change to it, text or style, and reading a PR preview well enough to know if the change actually worked.

Different as those three profiles are, they share one foundation. All of them need to be able to ask a plain-language question about the codebase and get back an answer grounded in what the code actually does, without pulling a senior engineer away from their own work to translate. That shared capability is the entire point of the ramp.

It is worth taking seriously how much this understanding is worth. Cortex's developer onboarding research found that engineers who report a high degree of understanding of their own code feel 42% more productive than those who report low or no understanding. There is no reason to think the mechanism is specific to engineers. A PM who understands the system she is shipping into carries less anxiety and less friction into every decision than one navigating by guesswork, and the same logic applies to a support rep or a designer moving through adjacent code. Literacy of this kind isn't switched on in a day. It deepens in stages, and each stage builds the mental model the next one depends on. A 30-60-90 structure, rather than a single onboarding session, is the right shape for this problem.

What has to be in place before day one, access, tooling, and the instruction layer agents need

The most common failure in this entire process happens before day one even starts. Handing a non-engineer a repo URL and a Claude license and calling it onboarding is how you end up with the manager.dev scenario: a massive, unreviewed PR mixing harmless cosmetic edits with mocked backend logic nobody flagged as fake. Access without structure is a delayed failure. It is a delayed failure.

Three things need to exist before anyone gets a login. Read access should be scoped to the repositories that actually touch someone's work. Second, there needs to be a working sandbox or preview environment; epilot's engineering team identified their one-click preview, auto-generated on every PR, as the single decision that drove adoption more than any other choice they made. Without a way to see a change actually render, a non-engineer is coding blind. Third, every non-engineer needs a specific engineer paired to them for review. The alternative, an open Slack channel where "whoever wants to" picks up review duty, fails reliably: PRs go stale, nobody owns the outcome, and review quality drops exactly when it matters most.

An instruction layer, AGENTS.md, is what most of this rollout depends on. It's read natively now by OpenAI's Codex CLI, Cursor, Aider, Devin, GitHub Copilot, and Windsurf, among others; Claude Code added limited support for it in September 2026, though only as a fallback when no CLAUDE.md file exists; Gemini CLI uses its own GEMINI.md instead; and Amazon Q isn't confirmed to read it natively at all. It reached this near-universal status after OpenAI donated the format to the Linux Foundation's Agentic AI Foundation in December 2025. The best implementations stay disciplined about it, keeping the file under 150 lines and including only what an agent genuinely cannot infer by reading the code itself, conventions, repo orientation, prose style.

AGENTS.md has a hard boundary, though, and it matters. It cannot tell an agent which API calls which service, who owns what, or what a proposed change would break downstream. That kind of knowledge has to live in a structured, continuously updated context layer alongside the markdown file, not inside it. Skipping that layer causes a non-engineer asking a vague question against a million-line codebase to exhaust the agent's available context before it produces anything useful. Anthropic's own guidance for enterprise-scale agent operation lists CLAUDE.md files, hooks, skills, plugins, Language Server Protocol integrations, subagents, and MCP servers as the components that make this work at scale. The rule of thumb is simple: AGENTS.md tells the agent how to behave, and the context layer tells it what is actually in the codebase.

Epilot's onboarding model, three one-hour sessions, one each for design, support, and go-to-market, focused entirely on tooling and access rather than code itself, deserves direct copying. PMs didn't need a dedicated session at all; they were already ramping through their existing engineering relationships. Day one should be a scheduled, structured event with a name on the calendar.

Days 1-30: orientation, safe queries, and the first meaningful codebase question

Nobody should be contributing anything in this first month. The goal is narrower and more foundational: the ability to ask a precise question about the codebase and judge whether the answer that comes back is actually trustworthy.

Week one is about building a mental model. Day one means attending the role-specific onboarding session, confirming sandbox access works, and opening the codebase in whatever AI query tool the org has standardized on. Claude Code's own "Common workflows" documentation ships prompt recipes built for exactly this kind of exploration, and Ready Solutions AI's 2026 guide found new engineers using those same prompts against a multi-repo codebase closed multiple tickets in their first sprint. The same prompts work just as well for a non-engineer operating in read-only mode.

Week two is where the real skill gets built, and it's harder than it sounds. Anthropic has documented the tradeoff directly: a vague question thrown at a large codebase burns through the agent's available context before it ever produces a useful answer. A good exercise is picking a bug or feature request the non-engineer already understands in plain product terms and asking the agent to find every file that touches it. For support staff, the equivalent drill is asking the agent to explain a specific error message: which service produced it, and what user action typically triggers it.

The non-engineer starts sitting in on code review, as an observer, for work in their own product area. Before each session, the practice is to have the agent pre-read the diff: what changed, what it would affect, and whether anything in it looks off. By the end of day 30, the bar is concrete and testable: can this person look at a PR in their area and write a one-paragraph, plain-language summary of what it does and why, without asking an engineer to walk them through it? Either they can or they can't, and both the non-engineer and their paired reviewer should be able to agree on the answer.

The paired engineer's job through this entire month is not to teach syntax. The win isn't that the relationship with a senior engineer disappears. It's that the engineer stops spending time on translation and starts spending it on judgment. Week 3–4 involves reading PRs and attending code review.

Days 31-60: from reading to reasoning, understanding change risk and codebase ownership

What comes next is harder: reasoning about consequences. The target for this phase is a non-engineer who can identify, unprompted, who owns a given service, what a proposed change would likely disturb downstream, and whether a reported issue is actually a bug or just a configuration problem.

The agent generates ownership maps for the services in a person's area: which team owns it, which repository it lives in, who the last meaningful committer actually was. A PM practices tracing a request from ticket to the exact files it would touch, without handing that trace off to engineering. Support picks its three most frequent escalation types and maps the entire path, from the user action that triggers the problem to the error log to the service responsible, then uses that map to write escalations that are actually useful rather than vague.

Some files, if touched without coordination, can break several services at once, and part of literacy is learning to recognize them before touching anything nearby. The habit to build here, for every role, is asking "what else would this touch?" before any change reaches a sprint, whether or not that person will ever write the change themselves.

For designers, this is where the exercise gets its hands dirty. The drill is a full bounded change, start to finish, and it means finding the file, making the edit through the agent (a copy fix, a CSS variable), opening the PR, and confirming it actually looks right using the one-click preview. It's small, deliberately so. The size of the contribution isn't what matters here. It's proof that the boundary between safe and unsafe is now something this person can feel, not just recite. High-risk files are introduced as files that, if modified without coordination, can break things across multiple services, and the Claude-Skills codebase-onboarding skill (v1.1.0, updated June 2026) surfaces the 20 most important files in a codebase and explicitly marks which are "dangerous to modify without coordination".

A quieter payoff appears here too, visible in how time gets spent. When a PM can already answer "what would this touch?" before a sprint planning meeting starts, the senior engineer's prep time for that meeting shrinks. When support hands off an escalation that already names the service and the relevant log line, triage moves faster. Nobody built this phase to reduce interrupts, but that's what it does. By day 60, the test is writing a technical scoping note, naming the affected services, the likely files, the owning team, and the downstream risk, good enough that an engineer would actually use it instead of rewriting it from scratch. Week 5–6 focuses on ownership and dependency mapping. Week 7–8 is dedicated to understanding change risk.

Days 61-90: active contribution, review participation, and setting the ceiling

Not everyone should be opening pull requests by day 90, and pretending otherwise would oversell what this ramp is for. The ceiling depends on the role and on the codebase itself; the real goal, for every non-engineer regardless of where that ceiling sits, is enough codebase literacy to operate independently and stop generating interrupt load for engineering.

The split by role is fairly clean. Designers making bounded UI changes, PMs iterating on copy or feature flags, and support staff improving internal tooling are reasonable candidates for limited PR contribution under review. Customer success, go-to-market, and executives sit on the other side of that line: their value is read access, fluent querying, and sharper escalations, not authorship. That's not a demotion. It's an honest match between a role's daily work and the literacy that role actually needs.

This is not a formality to relax once trust builds. The Faros AI Productivity Paradox study adds a useful wrinkle here: AI adoption skews toward contributors who are newer to the company, not newer to the profession, precisely because they're the ones navigating unfamiliar codebases. Review pairing isn't bureaucratic overhead layered on top of the ramp. It's the safeguard that makes the acceleration survivable. Review is not optional: the manager.dev case study documents what happens when PR review falls back to "whoever wants to" (PRs sit unreviewed, conflicts accumulate, and the 10,000-line monster PR becomes possible). Week 11–12 covers independent query fluency and self-service answers.

Most of the questions a non-engineer used to route to an engineer (what does this service do, what would this change break) should already be answerable through the query habits built using the AI agent to generate a plain-language architecture overview of what services exist, what they do, and which repositories own which parts of the product. That is the actual finish line for this plan. Not every non-engineer becomes a contributor, but the ramp removes them as a source of unplanned interruption, and it opens the codebase so it is no longer a black box that only engineers are allowed to understand. Week 9–10 centers on contribution with guardrails. For eligible roles, the non-engineer opens PRs only in their designated "safe zones" (the bounded areas identified during the day 31–60 phase), and every PR goes through the paired engineer for review.