Portfolio beats certificates.

Six months ago I finished a well-reviewed "Generative AI Professional" certificate, updated my LinkedIn banner, and started applying. The first real conversation I got was with a small team building internal agents. Twenty minutes in, the engineer asked a simple question that I still think about: "Can you show me an agent you shipped, and walk me through a trace where it failed and recovered?" I had a certificate. I did not have a trace. I did not have an agent. I had, it turned out, the wrong thing entirely, and I am writing this so you can skip the version of that morning where you find out the hard way.

Let me say the uncomfortable part plainly, because nobody said it to me and it cost me three months. The hireable skill is not prompting. It is orchestration. It is the ability to take a fuzzy task, break it into steps, wire those steps to real tools, catch the moments where the model is wrong, and recover. A certificate proves you sat through a curriculum. A portfolio proves you can do that loop. Guess which one an interviewer can actually inspect.

I am not a senior engineer. I am roughly six months into a career switch, learning most of this in public, and getting plenty of it wrong. So treat this as field notes from one rung ahead of you on the ladder, not a lecture from the top. A lot of what finally clicked came from people who were generous with their own notes, and I am trying to pay that forward here.

The shiftWhy "prompt engineer" stopped being the job

The single most useful thing I read during the switch was a piece from Tredence on agentic AI careers, and one engineer's honest description of their own evolution rearranged how I studied:

"I viewed AI as a prompt only tool. With time... I learned to build structured, resilient workflows where the AI completes complex tasks in logical phases." (Tredence, Agentic AI Career in 2026)

That is the whole shift in two sentences. The first version of "AI skills" was about coaxing one good answer out of one good prompt. The job that is actually being hired for is about building a system that keeps working when the first answer is wrong, which it constantly is. The same piece frames it as four disciplines that have to come together, and once I had this list I could finally see what my certificate had skipped:

"True enterprise AI seamlessly marries these four disciplines: prompt engineering, context engineering, error-recovery logic, and observability." (Tredence)

Read that list again and notice something. Only one of the four (prompt engineering) is what most beginner courses actually teach. The other three are the orchestration job. Context engineering is deciding what the model sees and when. Error-recovery logic is what happens on the rejection, the retry, the fallback. Observability is being able to look at a trace afterward and say what went wrong. My certificate gave me a quarter of the job and a lot of confidence about it, which is a dangerous combination on the other side of an interview table.

If you want the bigger map of how these capabilities stack up from "I can prompt" to "I can run agents in production," I found the levels of agentic engineering ladder a useful gut-check for honestly placing myself. Spoiler: I was a rung or two lower than my resume implied.

The roadmapFive weeks that taught me more than the cert did

After the rejection I threw out my study plan and rebuilt it around shipping, not collecting. I leaned heavily on a publicly shared agentic AI roadmap from Brij Pandey, who frames the stakes in a way that kept me going on the slow weeks:

"Agentic systems aren't 'future tech' - they're becoming the new layer that will reshape how products are built." (Brij Pandey, Agentic AI Roadmap 2026)

Here is the version I actually followed, compressed into the rungs that mattered. It is not the only path, and you should bend it to your own background. But this is the order that stopped me from drowning.

A few notes from walking it, because the diagram makes it look tidier than it felt. Weeks 1 to 2 were about resisting the urge to skip ahead. I made myself build one tiny command-line tool that called a model and printed the response, no framework, so I actually understood what a "tool call" was before a library hid it from me. Week 3 was the first time it felt like engineering: function calling, a basic ReAct loop, hooking the agent to one external API. Week 4 was multi-agent, where I learned a planner, an executor, and a critic are just three roles in a loop, not magic. Week 5 and onward was the part the courses never reach, which is making the thing safe and observable enough to trust.

One detail from week 4 deserves its own callout, because it is the idea I now lead with in interviews.

If you want a sharper breakdown of the underlying competencies rather than a week-by-week schedule, the agent programming stack lays out the skills as a layered framework, and it pairs well with this roadmap: the roadmap is the route, the stack is the map legend.

The portfolioWhat actually goes on the board

Here is where I want to be most concrete, because this is the part that changed my callbacks. After the roadmap, I stopped chasing more tutorials and built one end-to-end agent in a domain I cared about. The build does not matter as much as the checklist it satisfies. This is the exact list I now use to decide whether a project is "portfolio-grade" or just a toy.

Let me defend the two boxes that beginners (me, recently) tend to skip, because they are the two that interviewers actually probe.

The eval trace. An evaluation is just a repeatable way to check whether your agent did the right thing, run against a saved "golden" example of correct behavior. I used to think evals were a fancy enterprise concern, far above a junior. They are not. They are the single clearest way to show you understand that agents are non-deterministic and need checking. Anthropic's guide to demystifying evals for AI agents is the resource that made it approachable for me, and it reframed evals from "scary research thing" to "the test suite for your agent." When an interviewer asks to see a trace, this is what they mean: show me you measure your own agent, not just vibe-check it.

The README rejection. This is the one nobody tells you to do, and it is my favorite. In the README, write up a real case where your agent got something wrong, and exactly how your code caught and recovered from it. This does two things at once. It proves you can build error-recovery logic, and it proves you are honest about failure, which is most of what "senior" actually means. A documented failure is worth more than a flawless demo, because the flawless demo is probably hiding the failures rather than handling them.

If you are wondering what the actual moving parts inside such a project look like, the primitives are smaller than they sound. I found the hooks and skills explainer genuinely helpful for getting the vocabulary straight before I tried to wire any of it together, because a lot of "advanced" agent code is really just a few of these primitives composed.

The archetypeOne stack that ticks every box

You do not have to invent a portfolio project from scratch. There is a well-worn archetype that hits all five boxes naturally, and studying an existing one taught me more than any course. The shape is: an orchestration layer on top, real tools wired through a standard protocol in the middle, and a model underneath, with an eval harness watching the whole thing.

For a concrete reference I could read line by line, I leaned on an open-source example: a LangGraph plus MCP crypto research agent on GitHub. I am not endorsing crypto as a domain, and you should pick a domain you actually understand. The value was seeing how a real repo wires the orchestration to MCP tools and structures its loop. Clone something like it, understand every file, then rebuild the same shape in your own domain. That "rebuild in my domain" step is what made it a portfolio piece instead of a fork.

On frameworks: do not agonize over LangGraph versus CrewAI versus rolling your own. I burned a week on that comparison and it taught me nothing hireable. The orchestration concepts (state, tools, a planning loop, a critic) port across all of them. Pick one, ship with it, and be ready to say why you chose it. Interviewers care that you understand the shape, not that you backed the winning library.

The interviewHow to talk about the board you built

Having the portfolio is half of it. The other half is being able to walk someone through it without either underselling or bluffing, and this is where I stumbled even after I had something real to show. So here is the script that worked once I stopped narrating features and started narrating decisions.

Lead with the failure, not the demo. When I open with "here is a case where my agent picked the wrong tool, and here is the critic that caught it," the whole conversation changes. The interviewer leans in, because now we are talking about engineering judgment instead of a screen recording. Every line on the portfolio checklist is really a prompt for a story: the eval trace is your "how do you know it works" story, the README rejection is your "what do you do when it does not" story, and the MCP integration is your "how do you connect to the real world" story.

Be honest about the boundary of what you know. I am six months in, and pretending otherwise gets exposed in about two follow-up questions. What I learned is that "I have not run this at production scale, but here is how I reasoned about it" reads as maturity, while a confident wrong answer reads as the thing they are most afraid of hiring. The whole point of the rejection-loop framing is that good engineering is mostly about handling being wrong gracefully, and that applies to you in the interview just as much as to your agent in the loop. Saying "I do not know yet, here is how I would find out" is, weirdly, one of the most senior things you can say.

Map your one project to the four disciplines out loud. When you can point at your repo and say "this part is context engineering, this part is error recovery, this is my observability," you are speaking the interviewer's language back to them, and you are proving you understand the shape of the job rather than just the syntax of one framework. That single mapping did more for my callbacks than any extra feature ever did.

Honest caveatsWhat the hype gets wrong

I want to be careful not to sell you the same overconfidence my certificate sold me, so here are the things I have learned to distrust.

The salary numbers are softer than the posts claim. You will see "agentic engineers earn 40 to 100 percent more" type headlines. Maybe, in some regions, at some seniorities. The numbers I have personally seen are far more modest and vary wildly by location and level. Build the portfolio because it gets you hired and makes you better, not because a viral chart promised you a specific multiple. Treat the premium as anecdote, not as a plan.

Framework churn is real, and it is fine. The specific tools will change. The one I learn this quarter may be unfashionable by the time you read this. That used to stress me out until I noticed that the fundamentals (managing state, calling tools, writing evals, handling failure) have not moved at all. Anchor your learning to those, treat each framework as a temporary vehicle for them, and the churn stops feeling like a treadmill.

Certificates are not worthless, just misranked. Mine was not a waste. It gave my early weeks structure and vocabulary when I had neither. The mistake was treating completion as the destination instead of the on-ramp. Use courses to get oriented fast, then leave them the moment they start substituting for shipping. The order matters: structure first, then build, then keep building in public.

Start smallThe one thing to do this week

If this is a lot, here is the smallest useful step, the one I wish someone had handed me on day one. Do not enroll in anything. Build a single agent that does one multi-step task in a domain you know, wire it to one real tool, and write a README that documents one time it failed and how you made it recover. That is it. One repo. One trace. One honest failure write-up. It will out-signal a stack of certificates, and more importantly it will teach you whether you actually like this work, which no course can tell you.

Certificates prove you finished a course. Portfolios prove you can finish a loop. Interviewers can only inspect one of those, so build the one they can read.

Thank you for reading to the bottom. I wrote this because the version of me from six months ago needed it and could not find it, and because the people who shared their own roadmaps openly are the reason I am employed now. If you are mid-switch and stuck, I am genuinely happy to compare notes. I am still learning this in public, one trace at a time, and there is room on the ladder.