In my previous article, I argued that empiricism is a better fit than idealism when it comes to AI engineering.
The ability to draw boundaries between abstractions that make up your overall architecture are inherently blurrier with AI-driven software development.
One must feel the need for the abstractions more deeply before reaching for them.
For example, there are plenty of skills that I see released on a recurring basis, and I could grab one of these skills that configure it with my harnesses (e.g. Claude Code, Codex). However, it is very easy to overlook how skill may duplicate what an LLM already handles for you.
As soon as I move away from the natural behavior of an LLM, I impose some sort of structure that I then have to maintain. The risk is if that structure becomes outdated, and I don’t recognize it because I’ve blindly trusted in skills that seemed to be a good abstraction at the time.
For instance, I had installed a “taste” skill that steers models to produce less sloppy UI designs out of the gate. It would be very easy to “set it and forget it” with this skill. And if I do set it and forget it, then I risk the imposed structure (“taste”) to guide UI designs becoming out of sync with the progress of an LLM’s design abilities.
Borrowing such a skill doesn’t put me through the process to really feel out what good taste is and how to describe it effectively to an LLM.
For this reason, I envision that the sharing of skills, personalities, and libraries is going to become much less prevalent than in times past. Before, the advantages for using someone else’s abstraction were:
You don’t have to maintain the code in your codebase. You can delegate it to someone else.
You can implicitly trust the lower-level details of the abstraction.
LLMs make those advantages go away, so why not optimize for maximal clarity on what you are using and why it is needed? Build your own skills, personalities, and libraries, referencing openly-shared ones as inspiration. Monitoring your X feed for open ideas is now more impactful than monitoring open-source repositories.
This isn’t the only approach, of course. Many YouTubers take the approach of automatically adapting emergent skills, personalities, and other tools and tips. You can max out on the use of open-source abstractions/tools with an implicit trust that it is going to be superior than slowly building things out yourself.
That’s a respectable approach, and it likely works for content creators that do not feel the weight of various tradeoffs.
However, people working within a larger engineering organization, or people that just want to have the sanity of knowing what they are using, how it is working and why it is needed, may do better to cherry-pick ideas that resonate with felt needs and implement those ideas themselves.
The question with skills or AGENTS.md is: does this information belong outside the model? The taste skill (https://github.com/Leonxlnx/taste-skill/blob/3c7017d636c3a4aad378433ea6d0cfa6c921da4a/skills/taste-skill/SKILL.md) is mostly context noise. Policy and instruction competition can degrade performance compared to the base model. I use no skills and a minimal AGENTS.md, yet agents routinely ignore instructions. Better models, smaller and higher-quality context, and external checks are more reliable than trying to add post-training in Markdown. What belongs in AGENTS.md or skills then? Only what the model couldn't reliably know through training: specific, local policies or procedures about how you run your project.
It depends how you're using skils/context. There is a way of making skills/instructions that just micro-manage the model. Sometimes that can help less-intelligent models. That's not the right way to use them. Where instructions/context have their value is in the consistent grammar/world/system they represent. They are like knives though. A dull knife is dangrous/harmful. A sharp knife needs to be maintained and tested.