Executive reading · ~60 seconds

When artifacts become cheap, authorship appears in the chain of problem, decision, transparency about AI, verification, bounded outcome, and learning that changes the process.

AI has made it simple to generate polished interfaces, texts, APIs, notebooks, and presentations. A portfolio that only shows the final result has lost part of the power to differentiate authorship, judgment and professional capacity.

The new portfolio doesn't need to prove that you did everything without AI. You need to show that you know how to direct a process with AI and be responsible for the result.

Executive summary

For each project, show six pieces of evidence:

  1. problem and context;
  2. decisions and alternatives;
  3. AI use and limits;
  4. verification and evidence;
  5. result and impact;
  6. learning and next change.

The final artifact remains important. What differentiates the work is the chain that links intention, execution, verification and reflection.

Why the isolated result was weaker

A screenshot does not reveal:

  • whether the problem was real;
  • which part was difficult;
  • what trade-off did you choose;
  • how you dealt with errors;
  • whether the system works outside of the demo;
  • what would you do differently.

This has always been true. Cheap generation increased the volume of artifacts and made process evidence even more valuable.

A layered case

1. Problem

Explain the situation, the person affected, the restriction, and the success criteria. Remove sensitive data and don't invent customer, revenue or adoption.

2. Decisions

Show two or three material choices:

DecisionAlternativesCriterionConsequence
architectureA, B, Crisk and simplicityassumed limit
UXshort or explanatory flowuser testingobserved trade-off
modeloptions evaluatedtask evalcost/quality

It is not necessary to publish every thought. Select decisions that demonstrate judgment.

3. Collaboration with AI

Declare:

  • in which steps AI helped;
  • which tool or model class was used;
  • what context was provided;
  • what remained under human decision;
  • which outputs were rejected;
  • what risk has been controlled.

Transparency does not diminish authorship. Authorship is in intent, selection, judgment, verification, and accountability — not in hiding tools.

4. Verification

Include evidence commensurate with the work:

  • acceptance criteria;
  • negative tests and cases;
  • accessibility audit;
  • threat model;
  • quality assessment;
  • performance measurement;
  • user feedback;
  • links to sanitized commit or demo.

An attestation can link artifact and build provenance, but it does not prove semantic correctness. The delivery chain needs to allow independent verification and keep the claim limit visible. [R2-C2]

5. Result

Separate states:

  • implemented: exists in the code or artifact;
  • verified: checks support declared properties;
  • operation: actual usage was observed;
  • outcome: effect on the recipient was measured.

Don't promote a state because the project seems ready. An honest portfolio about limits conveys more maturity than an inflated case.

6. Learning

Show a real error or change:

  • what you believed;
  • what evidence contradicted it;
  • what changed in the system;
  • how you will avoid recurrence;
  • which question remains open.

Hindsight is not confession. It demonstrates that you can improve the process.

Portfolio for different profiles

Engineering

Prioritize contracts, architecture, testing, observability, security, diff and trade-offs.

Product and business

Prioritize problem, hypotheses, alternatives, decision, metrics and market learning.

Design

Prioritize research, flow, rejected explorations, accessibility, testing, and form-to-result relationship.

Data and AI

Prioritize dataset, quality, baseline, eval, error per segment, cost, risk and monitoring.

The format changes; the evidence contract remains.

What not to publish

Never turn a portfolio into a leak. Remove:

  • secrets and keys;
  • personal data;
  • prompts with confidential information;
  • names and numbers without authorization;
  • architecture that increases risk;
  • raw internal logs;
  • unproven commercial claims.

Use synthetic data, reduced diagrams, hashes, class descriptions, and aggregated results. When the restriction prevents showing evidence, explain the method without pretending to public verification.

A one-page template

Título + outcome
Contexto e restrição
Minha responsabilidade
Como usei IA
Três decisões
Como verifiquei
Resultado e limite
O que aprendi
Links seguros

Start small. A dense case is better than ten cards with no substance.

Signs of strong authorship

  • you explain why an option was rejected;
  • distinguishes fact, inference and hypothesis;
  • shows negative case;
  • declares AI assistance;
  • binds claim the evidence;
  • preserves limit and validity;
  • updates the case when it learns something new.

Strong authorship does not require permanent certainty. Requires traceability of the trial.

What this article proves — and what it doesn't prove

Provenance, review and Evidence Pack practices support portfolios that show process beyond outcome. There is no evidence that a single template maximizes hiring or replaces conversation, experience and context.

A portfolio is evidence selected by the author himself. Those who evaluate still need to check and ask.

Conclusion

When anyone can generate a first version, the difference shifts to problem, decision, quality standard, verification and learning.

Don't try to prove that you worked without AI. Prove that with AI you kept thinking.

Previous reading: After the pyramid. Next suggested reading: Junior in the age of AI.

Editorial and responsibility note

Research cutoff
Last review
Recorded corrections
No corrections recorded.

The cutoff above applies to the canonical claims. Additional sources and their access dates are identified in the article body.

This article combines cited sources, analysis, and the author's professional experience. Verifiable data and factual statements are linked to their respective sources. Interpretations, hypotheses, projections, recommendations, and opinions represent the author's professional point of view at the time of publication; they do not constitute proven facts, a promise of results, or legal, financial, or technical advice applicable to a specific case. Consult the original sources and qualified professionals before making decisions.

Claims and sources

R2-C2

Auditable delivery must bind an artifact to its build provenance and allow independent verification; a successful CI status without source binding is weaker evidence.

Limit: An attestation proves the declared provenance chain, not the semantic correctness of the artifact. This is a research-synthesis design input; it does not prove product adoption, operational maturity, independent attestation or outcome.

  • OpenSSF SLSA — OpenSSF SLSA, CC-BY-4.0 specification; analysis-only excerpts
  • GitHub — GitHub, CC-BY-4.0 documentation; analysis-only excerpts