Starting a career when AI can do the first draft

New entrants can attempt more, sooner. Employers still owe them a real route to expertise.

A candidate arrives at an interview with a dashboard, a research brief and a working prototype, all prepared with AI. The interviewer changes one assumption and asks what happens next. That’s the moment that counts.

My advice to people starting out: use the tools seriously. Explore, build and attempt work that used to be out of reach. Be clear about what you understand and what you still need to learn.

Employers carry the other half. We can’t raise the expectations of junior roles and quietly remove the support that helps people meet them.

Read the skills signal carefully. McKinsey’s HR Monitor exhibit shows rising top-five future-skill mentions for digital literacy, problem-solving and creativity (15, 9 and 6 percentage points) between 2025 and 2026. These are reported priorities, not hiring data, and country coverage changed between the surveys. My reading: tool fluency has to come with the ability to frame a problem, weigh options and explain a decision.

Finishing a task and learning it are different outcomes. A finished output can hide a gap. Does the person know why the calculation works, which assumptions matter and what would make the answer unreliable? Shen and Tamkin’s experiments with developers learning an unfamiliar coding library found weaker learning with AI assistance and no significant average efficiency gain, though some engaged ways of using it preserved learning. It’s one bounded coding study. The customer-support research by Brynjolfsson and colleagues also reports learning, with uneven productivity effects.

Some routine work should go. Some of it is where judgment forms. Separate the two before changing an entry-level role. The aim is real practice and proper feedback, not manual effort for its own sake.

For people starting out, I’d suggest one small project:

Understand the work: map a role’s tasks, language and stakeholders. Use AI to surface questions, then verify the important answers with documentation and practitioners.
Build and check: create a narrow prototype with public or synthetic data. Test awkward inputs and fix a real weakness before adding features.
Find the weaknesses: ask for counterexamples and test them. Agreement from another model doesn’t replace checking a source or running a reproducible test.
Explain it to a person: describe the result, its limits and the next decision. Then try a variation with less assistance.

Keep a log of what AI contributed, what you checked and what changed after review. Label simulated work as simulated, and never present AI-generated experience as work you performed. Use non-sensitive material, and at work follow the approved tools and data rules. This is a development exercise, not unpaid production work.

For employers: write role specs that state both the contribution expected and the learning you’ll support, and plan the review time. Build assignments where a newcomer attempts a case, compares approaches with an experienced colleague and handles a variation with less help. Candidates should ask which tools are approved, who reviews a new starter’s work and what they should handle independently after three months. Selection shouldn’t mistake money, time or networks for potential.

AI can help a newcomer contribute sooner. It can’t supply every relationship, the business context or the experience of owning a result that went wrong. Bring energy, evidence and a willingness to be corrected. Employers need to meet that with the chance to learn the job properly.

Sources: McKinsey · Building expertise in the age of AI: Who trains the next generation?; Shen & Tamkin · How AI Impacts Skill Formation; Brynjolfsson, Li & Raymond · Generative AI at Work