Who maintains the skill layer?

We're in an LLM-coding junior bubble

Everyone can build things now. You type a sentence into Claude or Cursor and get working code back. People who never wrote a pipeline are shipping pipelines. People who never touched an API are wiring up integrations. The output looks real. It runs.

Development-naive management sees the thousands of generated lines and calls it productivity. Engineers see the same thousands of lines and call it poorly-scoped, heavy on review work and future tech debt. Both are talking about the same code, but only one of them is about to experience the joys of owning the lifecycle of code.

"It runs" was always the junior bar. The senior bar is: does it handle credentials correctly? Does it read current docs or hallucinate an API that changed six months ago? Does it sample before doing a full load? Does it iterate, or ship the first draft? Nobody's talking about that part yet. The ability to produce something went from scarce to abundant overnight, and the conversation is still stuck on "look what I can build now." The part that actually matters in production, the senior craft, is missing from the narrative.

This isn't new. Software went through the same thing every time a new abstraction lowered the floor. Python brought its own wave of coders who treated programming as a means to an end and never picked up the engineering layer around it. The more people could build, the wider the gap between coding and software engineering got. In data, we mostly embrace that gap: experiments and POCs don't need the same rigor as production.

Agentic skills suffer from the same rules of existence as any software: dependencies, maintenance, cost of ownership. The difference between a skill and a classic automation script is less in what it is and more in how the industry currently treats it.

A skill is automation written for a different runtime. The runtime is the model. The job is the same as every CI job, config policy, or helper script your team has ever owned: make the machine do it right every time instead of hoping it figures it out. The one difference is that nobody has developed lifecycle rigor around it yet.

Skills that wrap software are software

Not all skills are equal. A skill for "writing a blog" or "doing a code review" is closer to a style preference - it encodes taste, not product behavior. A skill that says "call dlt.secrets to check if credentials work instead of reading secrets.toml directly”, and “always sample with add_limit to check responses before a full run", or “ensure dev_mode is set to False before deployment” is closer to technical documentation, like a tutorial or a how-to, meant to be executed rather than read. It's tightly coupled to a library and when the library changes, the skill must change too.

Every engineer already knows the cost of dependencies - unglamorous but load bearing. Skills that wrap a library inherit that same need, and the cost doesn't disappear because the file is markdown instead of Python.

Maintaining your own skills looks the way maintaining anything LLM-shaped looks. The first result generates fast. Then the questions start. How do you know what the agent is doing under the skill? Do you have a plan? Did you write the plan, or did Claude? Is the plan actually good? Is it being followed? And if you're not already an expert on the thing the skill wraps, how would you know what you're missing? Are you going to create your own eval and check Claude traces for actual LLM process?

We eval our skills. We iterate on the rules and the surrounding context until the agent presses the right buttons reliably. The honest framing is: leave the library-wrapping skill to the people who ship the library, and keep your attention on the part only you can write, such as business logic.

Otherwise, do you want to do the vendor’s interface maintenance work? Once you take that question seriously, you're back where the decision started. If you picked dlt, you already decided not to re-invent a loader you could get for free from OSS. That's the same decision on the skill layer now.

Vendor maintains theirs, you maintain yours

The answer to "who maintains the skills" is the same answer every library ecosystem already gives you for code: the vendor owns the product surface, you own the integration.

The vendor slice covers how the product should be used. It might change with the same cadence as the library or its docs because it's functionally part of the release. When dlt changes, the skills change.

The user slice covers how the product meets your environment: dlt with Airflow, dlt on Kubernetes, your folder layout, your naming conventions, your review gates, a specific client's API quirks. They're your integration layer, the same as every internal lib and deployment script your team has always owned on top of third-party dependencies.

An anti-pattern is doing your own skill for a vendor library - it’s like maintaining your own fork - degrading over time by design. You miss upstream fixes and teach the agent a parallel reality that diverges from the product you're actually running. The same reasons that that make forking a library a bad idea, makes forking its skill a bad idea.

Skills are where the “tool usage knowledge” now lives

The senior bar is "it runs for the right reasons, with the right process, every time, across releases, across teammates, across clients, across the thing a new model does differently next week".

That bar didn't move when agents arrived. The reflexes that used to live in a senior engineer's head like “don't ship the first draft” now have to live somewhere the agent actually reads. That somewhere is the skill.

You already decided not to re-implement a loader because OSS dlt ships one. The skill layer asks the same question one level up: do you want to maintain the vendor slice yourself, or do you want to take it from the people who ship the library and keep your attention on the part only you can write?

Here’s where you can try our agentic toolkits:

• Docs: The LLM native workflow (ingestion to usage)
• Education: Agentic data engineering with dltHub