AI Can Write the Code. Your Spec Is Becoming the Career Signal

AI coding portfolios have a visibility problem. The finished app shows what exists, but it often hides the decisions an employer actually needs to evaluate: whose problem mattered, which ambiguity you resolved, what the system must never do, why the acceptance test is fair, and what changed after a real person tried the feature. As agents make implementation faster, candidates need an artifact that preserves those decisions. A small, versioned specification can become that artifact.

This week supplied a useful trigger. Microsoft Digital described an internal move from ad hoc AI coding toward spec-driven development after finding that faster individual implementation did not automatically produce team-level gains. Its teams now treat a living specification as the primary artifact, capturing business intent and acceptance criteria before implementation and updating it alongside code and tests.^[1]

That is one organization's report, not proof that every engineering team is reorganizing around specs. The broader career lesson is still timely. A longitudinal preprint based on questionnaires from professional software engineers found a shift away from code creation and toward directing, evaluating, and correcting AI output, a category the authors call supervisory engineering work.^[2] Google has framed the same change from a tooling perspective: when agents can generate syntactically valid code quickly, review, verification, maintenance, architecture, safety, and reliability carry more weight.^[3]

The hiring implication is uncomfortable for candidates who have optimized their portfolios around output volume. A large repository, polished demo, or list of agent tools can leave the reviewer guessing about your contribution. Did you identify the right problem? Did you set the important constraints? Would the feature still be correct if a different model generated the code?

Your specification will not replace the implementation. It can make the thinking behind that implementation legible.

Faster implementation makes ambiguous intent more expensive

Traditional software projects already suffer when requirements are vague. AI coding raises the cost of that vagueness because an agent can turn a weak assumption into a large, coherent implementation before anyone notices that the team asked for the wrong behavior.

Imagine this request:

Add alerts for saved searches. Let users choose email or push and make the settings easy to use.

An agent can build something plausible from that sentence: a database table, notification preferences, a scheduler, templates, integrations, and a settings screen. The result may compile and look professional while answering none of the consequential questions.

What creates an alert: any new result, a material change, or a daily digest? What happens when a result disappears and returns? Which data can appear on a lock screen? Can an admin trigger messages? How does a user stop notifications when the settings service is unavailable?

Generated code can conceal these gaps because completeness of form looks like completeness of thought. The codebase contains routes, types, tests, and UI, so the project feels finished. Yet the most important product behavior remains accidental.

This is why current spec-driven tools put a structured sequence around agent work. GitHub's Spec Kit, for example, organizes the process into specification, plan, tasks, and implementation, with each artifact feeding the next.^[4] Its methodology treats the spec as a living source of truth that drives task breakdowns, checklists, implementation, and validation rather than a document filed away after kickoff.^[5]

You do not need to adopt that tool or turn every ticket into a formal requirements package. For career evidence, the useful move is smaller: choose one feature where ambiguity mattered, preserve the decisions before and during implementation, and let a reviewer trace the finished behavior back to the intent.

A spec reveals judgment that a repository can hide

A recruiter may never read a full specification. A hiring manager or interviewer can still use it to answer questions that code alone makes expensive to investigate.

First, the spec shows problem selection and boundaries. It identifies the user and consequence instead of beginning with a framework, then records what belongs in the first version, what remains out of scope, and which failure states need explicit behavior. This helps a reviewer distinguish an engineering project from a technology demonstration and forces prioritization into the open.

Third, it makes evaluation inspectable. Tests matter, but tests only prove something useful when they represent the intended behavior. OpenAI's 2026 audit of a coding benchmark found a substantial set of tasks with underspecified prompts, overly strict tests, low-coverage tests, or contradictions between the prompt and grader.^[6] The lesson for a portfolio is simple: a green check is weak evidence when nobody can tell whether the check measures the right requirement.

Finally, a versioned spec can show learning. The most persuasive line in the document may be the requirement you deleted after user testing, the edge case you added after a failure, or the metric you replaced when it rewarded the wrong behavior. Those changes demonstrate contact with reality.

If you are tailoring this evidence for a role, CoreCV's role and job-description tailoring workflow can help you emphasize the relevant parts of the same truthful project. A product-minded role may care most about user stakes and scope. A platform role may care about constraints, failure behavior, and traceability. The underlying evidence should remain the same.

Use the SPEC framework to build a career artifact

A useful feature specification can fit into four sections: Stakes, Parameters, Examples, and Checks plus change record. Together they form the SPEC framework. The goal is not exhaustive prose. It is a compact contract that makes the consequential choices reviewable.

The SPEC framework keeps consequential product choices visible before implementation begins.

Stakes: define the person, problem, and consequence

Start without mentioning AI, your preferred stack, or the feature you want to build. Describe the user, the current situation, the friction, and the outcome worth improving.

Weak:

Build a smart notification system with an AI-powered search experience.

Stronger:

People monitoring a narrow set of listings repeat the same search several times a day because new results appear unpredictably. They need a way to receive a bounded summary of newly matching results without exposing sensitive search terms on a lock screen or sending duplicate alerts.

The stronger version gives the implementation a reason to exist. It also gives the reviewer a basis for challenging the feature. If users do not repeat searches or do not value immediacy, alerts may be the wrong intervention.

State one desired outcome and one counter-metric. You might track whether users inspect genuinely new results alongside the duplicate or unwanted notification rate. Avoid inventing a target without baseline data. Define what you would measure and report only the evidence you collected.

Parameters: decide the boundaries before the agent fills them in

Parameters cover scope, constraints, assumptions, permissions, dependencies, and explicit exclusions. This section prevents a coding agent from quietly making product policy through implementation convenience.

For saved-search alerts, the first release might support one daily email digest. Push, real-time delivery, administrative sends, marketing messages, and sensitive query text stay out of scope. Only confirmed addresses are eligible. If result freshness cannot be established, the system sends nothing and records the reason.

That boundary is more credible than a multichannel demo because the candidate can explain the delivery promise, privacy choice, data dependency, and failure behavior.

Separate product constraints from implementation decisions. "A user must be able to stop messages from the email itself" is product behavior. "Use a signed token with a seven-day lifetime" is one implementation choice. A reviewer should be able to challenge the second without losing the first.

Name unknowns rather than allowing the agent to resolve them silently. For example: should one account receive separate digests for each search, or a single combined digest? Mark the question as unresolved, name who could answer it, and choose a reversible assumption for the prototype.

Examples: make normal and uncomfortable behavior concrete

Abstract requirements encourage everyone to imagine the easy case. Examples force the team to confront state, time, identity, duplication, permissions, and failure.

Include at least four:

• A normal case that represents the main user journey.
• An edge case involving time, state, scale, or ordering.
• A failure case involving a dependency or missing input.
• An abuse or privacy case involving an action the system must reject.

For the alert feature, the normal example could show three new results arriving before the daily cutoff. The edge case could show a listing removed and republished with the same identifier. The failure case could show the search index returning an incomplete watermark. The privacy case could show a shared account with an unverified address and a sensitive query label.

Write expected behavior, not just input data. If a result reappears with the same stable identifier, the system should not describe it as new. If the freshness watermark is missing, the job should stop and create an observable failure instead of sending a possibly duplicate digest. If the address is unverified, no notification is scheduled.

Checks and change record: connect acceptance to intent

Acceptance criteria should cover user-visible behavior and consequential boundaries. Some checks can be deterministic: schema validation, deduplication by stable identifier, unsubscribe token behavior, scheduling rules, and idempotent retries. Others require observation: whether the digest is understandable, whether users can predict what counts as new, or whether a privacy label is sufficiently clear.

Do not make a subjective question look settled by automation. A snapshot test can show that text rendered, not that the message was useful. A model-based grader can help sort cases, but it should not become the only authority for a claim you cannot inspect.

Pair each important requirement with evidence:

Requirement	Acceptance evidence
Only genuinely new results appear	Fixture set covering new, repeated, removed, and republished identifiers
Unverified addresses receive nothing	Integration test plus delivery-provider log from a sandbox run
Users can stop future digests from the message	End-to-end unsubscribe test and visible confirmation state
Missing freshness data prevents delivery	Failure-path test and observable job status
Digest meaning is understandable	Five moderated walkthroughs with questions recorded, not a universal usability claim

Then preserve change. Record the previous requirement, the evidence that challenged it, the decision, and the consequence for implementation or tests.

Version 0.2 sent one message per saved search. Two of five walkthrough participants with multiple searches could not predict how many messages they would receive. Version 0.3 combines results into one daily digest while preserving search labels. The delivery and unsubscribe tests were updated.

This entry is modest. It does not claim market validation. It shows a decision, sample, observation, revision, and verification response.

Turn a vague build prompt into a reviewable spec

The contrast becomes clearer when the artifacts sit side by side.

Before: implementation-shaped intent

Build saved-search alerts in Next.js. Use Postgres and a queue. Add email and push settings, retries, analytics, and a clean dashboard. Write tests and deploy it.

This request specifies technologies and outputs while leaving the product behavior open. An agent will have to invent the missing policy. The resulting portfolio may show many components, but the candidate cannot easily prove which decisions were deliberate.

After: a one-page feature contract

User and problem: A returning user repeats the same filtered search several times a day to find newly added results.

First-version outcome: Deliver one daily email digest containing results that match an active saved search and have not appeared in an earlier successful digest.

In scope: Creating and pausing a saved search; one combined daily email; verified addresses; stable-result deduplication; unsubscribe; observable delivery failure.

Out of scope: Push, real-time alerts, marketing content, administrative sends, recommendation ranking, and guaranteed delivery time.

Open decision: Whether digest cutoff follows the user's time zone or a fixed account setting. Prototype uses an explicit account time zone and exposes it in settings.

Key examples: New results before cutoff; removed and republished result; missing freshness watermark; unverified email; user unsubscribes while a job is queued.

Acceptance evidence: Traceable fixtures for deduplication; queue retry and idempotency tests; sandbox delivery logs; unsubscribe end-to-end test; five walkthroughs focused on predictability.

Authority: The system can schedule and send a digest from approved result data. It cannot enable alerts, verify contact information, or change search criteria for the user.

Now the implementation plan has something to preserve. The candidate can choose a queue, schema, framework, and provider, then explain those choices relative to a visible contract. If the agent proposes push notifications in the first version, the candidate can reject the expansion for a documented reason rather than personal preference.

Before code generation, ask a peer to read the spec and narrate what they think the feature will do. If two careful readers predict different behavior, clarify it first.

Keep the spec smaller than the uncertainty

Spec-driven development can become ceremony. A 40-page document generated from a three-line idea may contain more words without resolving more uncertainty. It can also anchor the team to invented detail.

Right-size the artifact by risk and ambiguity. A local data-conversion script with one user, reversible output, and deterministic validation may need a short contract in the README. A feature involving identity, money, external communication, destructive actions, or policy deserves clearer boundaries and failure behavior. A broad product should be divided into smaller specs that can be reviewed and changed independently.

If the artifact describes a repeated operating process rather than one feature, use the broader approach for packaging an AI workflow another person can run. Keep the feature spec focused on user behavior and acceptance.

Use an uncertainty budget. Identify the three questions most likely to change the feature or invalidate the implementation. Resolve them through user input, repository research, prototypes, or explicit reversible assumptions.

Distinguish a spec from a plan. The spec describes behavior and constraints; the plan explains implementation. "I chose a queue because the job needed retry and idempotency behavior" shows reasoning. "The spec required Redis" may simply disguise an implementation preference as a user requirement.

Build a portfolio evidence chain, not a document dump

Do not publish a folder of generated Markdown and expect a hiring manager to reconstruct the story. Package a short evidence path.

Begin with a case-study page that explains the user stake and the decision you owned. Link to the sanitized spec, then trace one consequential requirement through the plan, implementation, test, and observed result. Show one failure or disagreement that changed the spec. End with current limitations and what evidence would be needed before broader deployment. That structure extends the same evidence-first standard used when presenting AI-assisted projects on a resume.

A strong work sample lets a reviewer follow one important requirement from intent to observed evidence.

A strong package might contain:

1. A two-minute overview: the user, problem, boundary, and outcome.
2. The versioned spec: concise enough to inspect, with sensitive details removed.
3. A traceability sample: one requirement connected to code, tests, and run evidence.
4. A decision record: an option rejected and the reason.
5. A change story: evidence that altered the requirement or acceptance check.
6. A boundary ledger: what the prototype does not prove.

This strengthens a technical work sample because the reviewer can verify more than presentation quality. It also demonstrates systems thinking without turning the resume into a wall of text: the detail lives in the portfolio, while the resume compresses the decisions and outcomes.

Preserve one evidence core, then adapt its level of detail for the portfolio, resume, and interview.

If AI helped draft the spec, say so. Explain which inputs you supplied, which questions the agent surfaced, what you rejected, and how another person validated the result. The goal is not to claim solitary authorship. It is to show that you remained accountable for intent.

Track the complete task rather than a flattering local metric. GitHub reported that shortening individual tool outputs could increase total task time and token use when missing details forced agents to reread or rerun work, a reminder that local efficiency and end-to-end value can diverge.^[7] For your case study, report whether the feature reached its acceptance evidence, how much rework occurred, and which assumptions survived. Lines generated and prompts sent rarely help a reviewer judge the outcome.

Translate the same evidence into resume language

The resume should not include the full SPEC framework. It should compress the problem, owned judgment, relevant implementation, and defensible evidence.

Tool-first:

Used Claude Code, Copilot, Next.js, Postgres, and Redis to build an AI-powered notification system.

Evidence-led:

Defined and implemented a saved-search digest from a versioned feature spec, including stable-result deduplication, verified-address gating, idempotent delivery, and observable failure paths; five user walkthroughs prompted a shift from per-search messages to one predictable daily digest.

Vague leadership:

Led requirements and development for an AI-assisted platform feature.

Specific ownership:

Resolved notification scope, privacy boundaries, and acceptance criteria before delegating implementation to a coding agent; traced four critical requirements through integration tests and sandbox delivery evidence.

Overclaimed efficiency:

Increased engineering productivity by 10x with AI coding agents.

Defensible process evidence:

Cut two prototype rebuilds by clarifying time-zone, deduplication, and unsubscribe behavior before implementation; recorded spec changes and regression checks in the repository.

Only use the final version if you observed and can explain those rebuilds. Do not convert a personal impression into an organization-wide productivity claim.

Tailor emphasis to the target role. Product engineers can foreground user behavior and scope decisions. Backend engineers can foreground contracts, state transitions, retries, and failure visibility. Security engineers can foreground permissions and prohibited actions. Technical product managers can foreground ambiguity resolution, acceptance, and cross-functional change ownership.

The pattern complements a broader evidence matrix for skills-based resumes. Each skill claim should point to an artifact or story that can survive follow-up.

Defend the spec in an interview

An interviewer does not need you to recite the document. They need to see how you used it when reality became inconvenient.

Prepare a two-minute story:

I started with a request for multichannel saved-search alerts. Before implementation, I narrowed the first version to one daily email because we did not have evidence that real-time delivery justified the privacy and operational complexity. I wrote normal, duplicate, missing-data, and unsubscribe cases, then linked each critical behavior to a test or sandbox run. During five walkthroughs, users with multiple searches could not predict message volume, so I changed the spec from one email per search to one combined digest and updated the delivery tests. A coding agent drafted parts of the implementation, while I owned scope, data boundaries, review, and acceptance.

Expect an interviewer to probe the omitted options and the reliability of your evidence:

• Why was a notification the right intervention?
• Which requirement was hardest to make unambiguous?
• What did the agent assume incorrectly?
• Which acceptance check gave false confidence at first?
• What did a user or teammate change your mind about?
• What would fail at ten times the current scale?
• Which part could you defend without the agent?

Answer with concrete tradeoffs. The strongest technical candidates explain tradeoffs, not just wins. A rejected design can reveal more senior judgment than a list of completed features.

Do not hide technical gaps behind the spec. If you cannot explain the state model, retry behavior, data access, or tests in your own project, the artifact will collapse under follow-up. Specification skill and implementation literacy reinforce each other.

Run a seven-day spec-to-evidence sprint

You can build this signal around a small feature without launching a startup-sized project.

Day 1: observe and choose. Find one repeated user problem with meaningful ambiguity. Write the stakes without mentioning the solution.

Day 2: bound the feature. Define the first-version outcome, scope, exclusions, permissions, assumptions, and three unresolved questions. Ask one relevant person to review the boundary.

Day 3: write representative examples. Add normal, edge, failure, and abuse or privacy cases. Describe expected behavior for each.

Day 4: design acceptance evidence. Map important requirements to deterministic tests, observable runs, or human review. Identify any subjective claim automation cannot settle.

Day 5: plan and implement. Use a coding agent if useful, but preserve the spec-plan distinction. Record agent-proposed scope changes and your decision on each.

Day 6: challenge the result. Run the uncomfortable cases, ask another person to predict behavior, and test one dependency failure. Update the spec when evidence changes the intended behavior.

Day 7: package the evidence. Publish a sanitized case study, one traceability example, the most useful change record, an accurate resume bullet, and a two-minute interview story.

The sprint succeeds when another person can inspect your judgment. Shipping every possible feature is unnecessary.

Know what the spec does not prove

A good specification does not prove production scale, user demand, security review, team adoption, or deep expertise in every technology the agent touched. It cannot resolve product uncertainty without contact with users and domain evidence.

Keep a boundary ledger. State that the project used synthetic data, five walkthroughs, a sandbox provider, and one week of testing if those are the facts. Name the untested conditions, such as large message volume, multilingual content, accessibility with assistive technology, or provider outages longer than the retry window.

Avoid turning "spec-driven development" into another keyword badge. Employers benefit when a candidate can preserve intent across product discussion, agent delegation, implementation, testing, and revision. Include a disagreement or correction: a version history showing an assumption, failed case, and revision demonstrates actual use.

Preserve intent, then show the evidence

Coding agents will keep improving. The amount of implementation one person can generate will rise, and a finished interface will become easier to produce. That makes it harder for an employer to infer judgment from output alone.

A small, living spec gives the reviewer another route. It shows which user mattered, what behavior you protected, where you constrained the system, how you defined acceptable evidence, and which observation changed your mind. The implementation proves you can build. The trace from stakes to checks proves that you knew what should be built and stayed accountable when the first answer was wrong.

Choose one feature this week. Write the SPEC before the next agent run, keep it beside the code, and preserve the first meaningful change. Then carry that same evidence into your portfolio, resume, and interview.

When code gets cheaper to generate, preserving intent becomes more valuable. Make that work visible.

For a practical research breakdown like this each week, follow the AI Career Signals archive for guidance on AI-shifting resumes, portfolios, interviews, and job searches.

Disclosure: This article is authored by the CoreCV team. While we mention CoreCV.ai, the strategies and advice presented here are intended to be useful whether or not you use our product.

Sources

1. Microsoft Inside Track, Engineering the Frontier Firm: Sharing our AI-native approach to software development: https://www.microsoft.com/insidetrack/blog/engineering-the-frontier-firm-sharing-our-ai-native-approach-to-software-development/
2. Vella and Blincoe, The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study: https://arxiv.org/abs/2605.23135
3. Google Developers Blog, Why Go is an Ideal Language for AI-Assisted Software Engineering: https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/
4. GitHub, GitHub Spec Kit documentation: https://github.com/github/spec-kit/blob/main/docs/index.md
5. GitHub Blog, Spec-driven development with AI: Get started with a new open source toolkit: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/
6. OpenAI, Separating signal from noise in coding evaluations: https://openai.com/index/separating-signal-from-noise-coding-evaluations/
7. GitHub Blog, How we make AI coding more cost efficient without sacrificing task quality: https://github.blog/ai-and-ml/github-copilot/how-we-make-ai-coding-more-cost-efficient-without-sacrificing-task-quality/