Skills Engineering Is Becoming Its Own Discipline

The loudest phrase at AI Engineer World’s Fair 2026 was not “agent.” It was “skill.” For TPMs running AI programs, that reframe matters more than any model capability curve. The contrarian claim was that skill engineering is becoming its own discipline, and the programs that pretend it is just prompt writing are already falling behind. That framing came from two voices you do not normally hear agree on anything: Paul Bacchus, the open-source maintainer behind Impeccable, and Garry Tan, the president of Y Combinator, in his closing keynote. The leverage in your agent program is moving from the agent to the loop, and the loop now runs on skills.

The number that matters

The number is five. Of the five dominant trends at AIEWF 2026, four sit downstream of one shift: skills are now the platform primitive, and every agent platform is being rebuilt around them. That is not a feature note. It is a staffing note. The framing comes from this week’s AI Daily Brief episode, “5 AI Engineering Trends for Non-Engineers”, which distilled Richard MacManus’s full Latent Space recap.

What changed at AIEWF 2026

Two definitions landed at the conference and they rhyme more than they should.

Addy Osmani described skills as the encoding of the workflows and quality gates senior engineers already use, packaged so agents can follow them consistently. Skills package the judgment senior engineers have. Skills make that judgment portable. Philipp Schmid of Google DeepMind added the operational discipline: skills reduce the need for orchestration code, but only if you ship them with evals. Without evals, you have shipped a vibe.

Paul Bacchus took it one step further. In his AIEWF interview with Latent Space, he argued that skill engineering will become its own discipline. The implication is not that prompt writing is over. It is that prompt writing is now the entry-level task in a field that has its own senior role. Garry Tan, in his closing keynote, tied skills directly to what he called being “AI-native.” His argument was that AI-native companies do not just use agents. They invest in the discipline that makes agents reliable.

The counterpoint came from Tyler Brown on X: skills need re-implementation every model release. He compared it to parenting a kid that grows from middle school to high school. You have to change the curriculum. That is the part most TPMs underestimate.

Why this is a TPM problem, not an engineering problem

The standard framing of skills engineering is “engineering problem.” That framing is wrong for what just shipped. The right framing is program management problem.

A skill is a contract between your team and your agent. It encodes the judgment a senior engineer has earned. It enforces the quality gate that review is supposed to enforce. It documents the workflow that tribal knowledge used to carry. If skills are written informally, you ship an agent that drifts every time the model changes. If skills are written as a discipline, with evals, with owners, with versioning, you ship a program that survives the next model release without a rewrite.

This is the same shape as every other platform discipline your team has built. Design systems. Build pipelines. Test suites. Runbooks. The discipline did not start in those places. It started in the place where the work became too painful to repeat by hand. Skills engineering is crossing that line right now.

The four-part skills engineering framework

If you are a TPM whose agent program is shipping but drifting, here is the operating model to put in front of your engineering lead this week. Do them in order. The first two are the strategic items. The last two are the operational items that turn skills from a wish into a deliverable.

1. Name the skill owner. Every skill needs a named human who is responsible for its correctness, not just its presence. The owner is the person who updates the skill when the model changes, when the workflow changes, or when an eval fails. Without a named owner, you have a folder of markdown that will drift. With a named owner, you have a discipline.
2. Treat skills as a platform primitive. Stop writing skills inside feature branches. Move them to a shared, versioned, evaluated registry that every team can pull from. This is the design-system move applied to skill content. The earlier you make this move, the cheaper it is to roll back a bad skill.
3. Ship every skill with an eval. Philipp Schmid’s talk at AIEWF is the operational playbook here. The eval is not optional. The eval is the contract. If you cannot write a test for the skill’s expected behavior, you do not yet understand the skill well enough to ship it.
4. Plan a curriculum refresh every model release. Tyler Brown’s parenting analogy is the right cadence. Each major model release is a grade change. The skills you wrote for the last model are not the skills you need for this model. Budget the refresh. Calendar it. Make it a program milestone, not a fire drill.

The four-line framework is the program. Anything else is prose.

What this does not solve

I will be specific about the limits, because the enthusiasm around skills engineering is real and the gap between “we wrote skills” and “our agent is reliable” is wide.

Skills engineering does not solve agent behavior drift on its own. Skills are one layer of the harness. The full harness, including permissions, retries, fallback models, and observability, still has to be engineered. Skills without the rest of the harness is a partial solution pretending to be a complete one.

Skills engineering does not solve model upgrade risk. The same Tyler Brown caveat that justifies a curriculum refresh also means skills are an ongoing operating cost, not a one-time investment. Budget for the recurring refresh, or your skills will rot.

Skills engineering does not solve governance. A skill that encodes bad judgment will ship bad behavior at agent speed. The eval is the safety net. Skills without evals are how you ship a confident mistake.

The signal that matters most

The signal that matters most is Garry Tan’s closing keynote framing. He tied skill engineering to being AI-native, and he did it from the YC stage, which means the framing is now in the room with every founder pitching this fall. The TPM implication is concrete: when a startup says they are AI-native, the next question is whether they have a skill engineering discipline or whether they are running on prompt files. If you are reviewing those startups, or building inside one, this is the line that separates the companies that will scale from the companies that will stall.

The next six months are the window. Skill engineering is still cheap to formalize. The early movers are documenting their skills, naming their skill owners, and shipping evals alongside every release. The laggards are writing prompts into chat threads and calling it a strategy. If this is useful, forward it to the engineering lead who is about to ship your next agent feature. The framework is the next deliverable.