Soon we will have a skills marketplace that allows you to sell you skill of being able to make the AI more skilled.
Claude Skills are awesome, maybe a bigger deal than MCP
251–260 of 383 posts
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#252We're doing something like this internally. Our monorepo context files were much too big, so we built a progressive tree of fragments to load up for different tasks. I am struck by how much these kinds of context documents resemble normal developer documentation, but actually useful and task-oriented. What was the barrier to creating these documents before? Three theories on why this is so different: 1) The feedback…
It is primarily a principal agent problem, with a hint of marshmallow test. If you are a developer who is not writing the documents for consumption by AI, you are primarily writing documents for someone who is not you; you do not know what this person will need or if they will ever even look at them. They may, of course, help you, but you may not understand that, have the time, or discipline. If you are writing them…
Your LLMs get rid of comments? Mine add them incessantly.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#253Earlier quoted context omitted.
What if the great boon of AI is to get us to do all the thinking and writing we should have been doing all along? What if the next group of technologists to end up on top are... the technical writers ? Haha, just kidding you tech bros, AI's still for you, and this time you'll get to shove the nerds into a locker for sure. ;-)
It might not be that wrong. After all, programming languages are a way to communicate with the machine. In the same way we are not doing binary manually, we might simply not have to do programming too. I think software architecture is likely to be what it should be: the most important part of every piece of software.
You’ve got it wrong. The machine is fine with a bit soup and doesn’t care if it’s provided with punch card or python.
Programming was always a tool for humans. It’s a formal “notation” for describing solutions that can be computed. We don’t do well with bit soup. So we put a lot of deterministic translations between that and the notation that we’re good with.
Not having to do programming would be like not having to write sheet music because we can drop a cat from a specific height onto a grand piano and have the correct chord come out. Code is ideas precisely formulated while prompts are half formed wishes and prayers.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#254This is a fairly negative comment, but putting it out there to see if other people are feeling the same thing If you told the median user of these services to set one of these up I think they would (correctly) look at you like you had two heads. People want to log in to an account, tell the thing to do something, and the system figures out the rest. MCP, Apps, Skills, Gems - all this stuff seems to be tackling the wr…
What is a "deep problem" and what was the cadence with which we addressed these kinds of "deep problems" prior to 2023, when ChatGPT first went mainstream?
For a very tiny slice of these deep problems and how they were addressed, you can review the usenix conferences and the published papers there.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#255Earlier quoted context omitted.
What is a "deep problem" and what was the cadence with which we addressed these kinds of "deep problems" prior to 2023, when ChatGPT first went mainstream?
For a very tiny slice of these deep problems and how they were addressed, you can review the usenix conferences and the published papers there. https://www.usenix.org/publications/proceedings
I've been a Usenix reviewer twice, once as a program chair (I think that's what they call the co-leaders of a PC?). So this doesn't clarify anything for me.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#256This is a fairly negative comment, but putting it out there to see if other people are feeling the same thing If you told the median user of these services to set one of these up I think they would (correctly) look at you like you had two heads. People want to log in to an account, tell the thing to do something, and the system figures out the rest. MCP, Apps, Skills, Gems - all this stuff seems to be tackling the wr…
I'm not sure what you mean. What is the "real problem"? In the pursuit of making application development more productive, they ARE solving real problems with mcp servers, skills, custom prompts, etc... The problems are context dilution, tool usage, and awareness outside of the llm model.
> The problems are context dilution, tool usage, and awareness outside of the llm model.
These is accidental complexity. You’ve already decided on a method and instead of solving the main problem, you are solving the problems associated with the method. Like deciding to go in space with a car and trying to strap a rocket onto it.
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#257We're doing something like this internally. Our monorepo context files were much too big, so we built a progressive tree of fragments to load up for different tasks. I am struck by how much these kinds of context documents resemble normal developer documentation, but actually useful and task-oriented. What was the barrier to creating these documents before? Three theories on why this is so different: 1) The feedback…
> 2) The tools can help build them. Building good docs was always hard. Especially if you take the time to include examples, urls, etc. that make the documentation truly useful. These tools reduce this cost.
I would just be a little cautious about this, for a few reasons: (a) an expectation of lots of examples and such can increase the friction to capturing anything at all; (b) this can encourage AI slop bloat that is wrong; (c) bloat increases friction to keeping the key info up to date.
> 3) Many programmers are egotists. Documentation that helps other people doesn't generate internal motivation. But documentation that allows you to better harness a computer minion to your will is attractive.
There are also people who are conflicted by non-ideal trust environment: they genuinely want to help the team and do what's right for the business, but they don't want to sacrifice themselves if management doesn't understand and value what they're doing.
> Any other theories?
Another reason is that organizations often had high-friction and/or low-trust places to put documentation.
I always emphasize low-friction, trusted engineering docs. Making that happen in a small company seems to involve getting everyone to use a low-friction wiki (and in-code/repo doc, and when to use which), migrating all the doc that's strewn all over random SaaSes that people dropped it, showing people how it's done.
It must be seen as genuinely valuable to team-oriented, mission-oriented people.
Side note: It's very difficult to try to un-teach someone all the "work" skills they learned in school and many corporate jobs, where work is mostly directed by appearances. For example, the goal of a homework essay is to have what they deliver look like something that will get a good grade from the grader, but they don't care at all about the actual quality or value of it, and it has no other purpose. So, if you drop that person into a sprint with tasks assigned to them, the main goal will be to look good on what they think are the metrics, and they will have a hard time believing they're supposed to be thinking beyond that. (They might think it's just corporate platitudes that no one believes, like the Mission Statement, and nod their head until you go away.) And if they're told they're required to "document", the same people will go into that homework mode, and will love the generative-AI tools, and not reason about the quality/value/counterproductiveness of dumping that write-only output in whatever enterprise SaaS someone bought (decided in often another example of "work" done really understanding or caring what they were doing, but for appearances).
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#258Earlier quoted context omitted.
For a very tiny slice of these deep problems and how they were addressed, you can review the usenix conferences and the published papers there. https://www.usenix.org/publications/proceedings
I've been a Usenix reviewer twice, once as a program chair (I think that's what they call the co-leaders of a PC?). So this doesn't clarify anything for me.
To out it more clearly. You take a domain (like OS security, perfomance, and administration) and you’ll find those kinds of problems that people feel important to share solutions with each other. Solutions that are not trivially found. Findings you can be proud your name is attached with.
And then you have something like the LLM craze where while it’s new, it’s not improving any part of the problem it’s supposed to solve, but instead is creating new ones. People are creating imperfect solutions to those new problems, forgetting the main problem in the process. It’s all vapourware. Even something like a new linter for C is more of a solution to programmer’s productivity than these “skills”
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#259[flagged]
Re: Claude Skills are awesome, maybe a bigger deal than MCP
#260Earlier quoted context omitted.
It is primarily a principal agent problem, with a hint of marshmallow test. If you are a developer who is not writing the documents for consumption by AI, you are primarily writing documents for someone who is not you; you do not know what this person will need or if they will ever even look at them. They may, of course, help you, but you may not understand that, have the time, or discipline. If you are writing them…
Your LLMs get rid of comments? Mine add them incessantly.
I have to yell at Gemini to not add so many comments it almost writes more comments than code by default.