21 ms·

I fear the conceptual churn we're going to endure in the coming years will rival frontend dev. Across ChatGPT and Claude we now have tools, functions, skills,

• hkt 1y ago
  The same thing will happen: skilled people will do one thing well. I've zero interest in anything but Claude code in a dev container and, while mindful of the lethal trifecta, will give Claude as much access to a local dev environment and it's associated tooling as I would give to a junior developer.
• LPisGood 1y ago
  Metastasizing is such an excellent way to describe this phenomenon. They grow on top of each other.
• mathattack 1y ago
  There's so much white space - this is the cost of a brand new technology. Similar issues with figuring out what cloud tools to use, or what python libraries are most relevant. This is also why not everyone is an early adopter. There are mental costs involved in staying on top of everything.
  • benterix 1y ago
    > This is also why not everyone is an early adopter. Usually, there are relatively few adopters of a new technology. But with LLMs, it's quite the opposite: there was a huge number of early adopters. Some got extremely excited and run hundreds of agents all the time, some got burned and went back to the good old ways of doing things, whereas the majority is just using LLMs from time to time for various tasks, bigger of smaller.
    • a4isms 1y ago
      I follow your reasoning. If we just look at businesses, and we include every business that pays money for AI and one or more employees use AI to do their their jobs, then we're in the Early Majority phase, not the Innovator or Early Adopter phases. https://en.wikipedia.org/wiki/Technology_adoption_life_cycle https://en.wikipedia.org/wiki/Technology_adoption_life_cycle
    • mathattack 1y ago
      There's early adoption from individuals. Much less from enterprises. (They're buying site licenses, but not re-engineering their company processes)
• kbar13 1y ago
  i’m letting the smarter folks figure all this out and just picking the tools i like every now and then. i like just using claude code with vscode and still doing some things manually
  • efields 1y ago
    same same
    • MomsAVoxell 1y ago
      Another filthy casual checking in. Let the kids churn, the froth rises to the top and anyway .. I've got a straw.
  • articsputnik 1y ago
    yeah, avoiding all the serialization and deserialization, as I'm already working in Markdown and open text for almost all my stuff. The Claude Skill only seems to make sense for people who don't have their data in multiple different proprietary formats, then it might sense to packaging them into another one. But this can get messy pretty quick!
• esafak 1y ago
  On the other hand, this complexity represents a new niche that, for a while at least, will present job and business opportunities.
• Trias11 1y ago
  Right. I focus on building projects delivering some specific business value and pick the tools that gets me there. There is zero value in spending cycles by engaging in new tools hype.
• dalmo3 1y ago
  For Cursor: cursorrules, mdc rules, user rules, team rules.
• catgary 1y ago
  These companies are also biased towards solutions that will more-or-less trap you in a heavily agent-based workflow. I’m surprised/disappointed that I haven’t seen any papers out of the programming languages community about how to integrate agentic coding with compilers/type system features/etc. They really need to step up, otherwise there’s going to be a lot of unnecessary CO2 produced by tools like this.
  • typpilol 1y ago
    I kind of do this by making LLM run my linter which has typed lint rules. The way I can get any decent code out of them for typescript is by having no joke, 60 eslint plugins. It forces them to write actual decent code, although it takes them forever
• awb 1y ago
  Hopefully there’s a similar “don’t make me think” mantra that comes to AI product design. I like the trend where the agent decides what models, tooling and thought process to use. That seems to me far more powerful than asking users to create solutions for each discreet problem space.
  • kingkongjaffa 1y ago
    Where I've seen it be really transformative is giving it additive tools that are multiplicative in utility. So like giving an LLM 5 primitive tools for a specific domain and the agent figuring out how to use them together and chain them and run some tools multiple times etc.
• iLoveOncall 1y ago
  Except in reality it's ALL marketing terms for 2 things: additional prompt sections, and APIs.
  • james_marks 1y ago
    I more or less agree, but it’s surprising what naming a concept does for the average user. You see a text file and understand that it can be anything, but end users can’t/won’t make the jump. They need to see the words Note, Reminder, Email, etc.
• deleted 1y ago
  [deleted]
• butlike 1y ago
  Just wait until I can pull in just the concepts I want with "GPT Package Manager." I can simply call `gptpm add skills` and the LLM package manager will add the Skills package to my GPT. What could go wrong?
  • dhamidi 1y ago
    That's already the case with https://docs.claude.com/en/docs/claude-code/plugins https://docs.claude.com/en/docs/claude-code/plugins
• libraryofbabel 1y ago
  You forgot mcp-everything! Yes, it's a mess, and there will be a lot of churn, you're not wrong, but there are foundational concepts underneath it all that you can learn and then it's easy to fit insert-new-feature into your mental model. (Or you can just ignore the new features, and roll your own tools. Some people here do that with a lot of success.) The foundational mental model to get the hang of is really just: * An LLM * ...called in a loop * ...maintaining a history of stuff it's done in the session (the "context") * ...with access to tool calls to do things. Like, read files, write files, call bash, etc. Some people call this "the agentic loop." Call it what you want, you can write it in 100 lines of Python. I encourage every programmer I talk to who is remotely curious about LLMs to try that. It is a lightbulb moment. Once you've written your own basic agent, if a new tool comes along, you can easily demystify it by thinking about how you'd implement it yourself. For example, Claude Skills are really just: 1) Skills are just a bunch of files with instructions for the LLM in them. 2) Search for the available "skills" on startup and put all the short descriptions into the context so the LLM knows about them. 3) Also tell the LLM how to "use" a skill. Claude just uses the `bash` tool for that. 4) When Claude wants to use a skill, it uses the "call bash" tool to read in the skill files, then does the thing described in them. and that's more or less it, glossing over a lot of things that are important but not foundational like ensuring granular tool permissions, etc.
  • Der_Einzige 1y ago
    Tool use is only good with structured/constrained generation
    • libraryofbabel 1y ago
      You'll need to expand on what you mean, I'm afraid.
      • AStrangeMorrow 1y ago
        I think, from my experience, what they mean is tool use is as good as your model capability to stick to a given answer template/grammar. For example if it does tool calling using a JSON format it needs to stick to that format, not hallucinate extra fields and use the existing fields properly. This has worked for a few years and LLMs are getting better and better but the more tools you have, the more parameters your functions to call can have etc the higher the risk of errors. You also have systems that constrain the whole inference itself, for example with the outlines package, by changing the way tokens are sampled (this way you can force a model to stick to a template/grammar, but that can also degrade results in some other ways)
• __loam 1y ago
  Langchain was the original sin of thin framework bullshit
• kelvinjps10 1y ago
  I found that the way that Claude now handle tools on my sistema simplifies stuff, with its cli usage, I find the Claude skills model better than mcp
  • jessmartin 1y ago
    Same. Was very excited about MCP but Claude code + CLI tools is so much nicer.
• lukev 1y ago
  The cool part is that none of any of this is actually that big or difficult. You can master it on-demand, or build your own substitutes if necessary. Yeah, if you chase buzzword compliance and try to learn all these things outside of a particular use case you're going to burn out and have a bad time. So... don't?
• siva7 1y ago
  It feels like every week these companies release some new product that feels very similar to what they released a week before. Can the employees at Anthropic even tell themselves what the difference is?
  • amelius 1y ago
    These products are all cannibalizing eachother, so a bad strategy.
  • zqna 1y ago
    I bet that most of those products are created by their own "AI". They must already be using AI product owners, developers, testers, as their human counterparts are only sitting their in their chairs and only busy training their AI simulation and moderating their output. Next logical step will be AI doing that with the human folks hitting the street, then recursively ad infinitum. They will reach the glorified singularity there really soon!
• zmmmmm 1y ago
  Yep, the ecosystem is well on its way to collapsing under its own weight. You have to remember, every system or platform has a total complexity budget that effectively sits at the limit of what a broad spectrum of people can effectively incorporate into their day to day working memory. How it gets spent is absolutely crucial. When a platform vendor adds a new piece of complexity, it comes from the same budget that could have been devoted to things built on the platform. But unlike things built on the platform, it's there whether developers like it and use it or not. It's common these days that providers binge on ecosystem complexity because they think it's building differentiation, when in fact it's building huge barriers to the exact audience they need to attract to scale up their customer base, and subtracting from the value of what can actually be built on their platform. Here you have a highly overlapping duplicative concept that's taking a solid chunk of new complexity budget but not really adding a lot of new capability in return. I am sure the people who designed it think they are reducing complexity by adding a "simple" new feature that does what people would otherwise have to learn themselves. It's far more likely they are at break even for how many people they deter vs attract from using their platform by doing this.
• SafeDusk 1y ago
  That is why a minimal framework[1] that allows me to understand the core immutable loop, but to quickly experiment with all these imperative concepts is invaluable. I was able to try Beads[1] quickly with my framework and decided I like it enough to keep it. If I don't like it, just drop it, they're composable. [0]: https://github.com/aperoc/toolkami.git https://github.com/aperoc/toolkami.git [1]: https://github.com/steveyegge/beads https://github.com/steveyegge/beads
  • scrollaway 1y ago
    Yeah Beads is a very nice experience. Useful, easy to set up, easy to drop.
• DrewADesign 1y ago
  Not to mention GANs, RAGs, context decoupling, prompt matrices, NAGGLs, first-class keywords, reverse token interrupts, agentic singletons, parallel context bridges… … jk… I’ll bet at least one person was like “ah, damnit, what did I miss…” for a second.
• eru 1y ago
  AI tools can help you with the churn. AI will help you solve problems you wouldn't have without AI.
• dyauspitr 1y ago
  All of these things seem unnecessary. You can just ask the general prompt any of these things. I don’t really understand what exactly an agent adds on since it feel like the only thing about an agent is a restricted output.
• nurettin 1y ago
  You can just ask an LLM to set it up for you. Slop in, slop out.
• solumunus 1y ago
  As usual, stick with the basic 20% which give 80% of the value.
• blitzar 1y ago
  Just need to add some use cases
• flutetornado 1y ago
  There are several useful ways of engineering the context used by LLMs for different use cases. MCP allows anybody to extend their own LLM application's context and capabilities using pre-built *third party* tools. Agent Skills allows you to let the LLM enrich and narrow down it's own context based on the nature of the task it's doing. I have been using a home grown version of Agent Skills for months now with Claude in VSCode, using skill files and extra tools in folders for the LLM to use. Once you have enough experience writing code with LLMs, you will realize this is a natural direction to take for engineering the context of LLMs. Very helpful in pruning unnecessary parts from "general instruction files" when working on specific tasks - all orchestrated by the LLM itself. And external tools for specific tasks (such as finding out which cell in a jupyter notebook contains the code that the LLM is trying to edit, for example) make LLMs a lot more accurate and efficient, efficient because they are not burning through precious tokens to do the same and accurate because the tools are not stochastic. With Claude Skills now I don't need to maintain my home grown contraption. This is a welcome addition!
• MomsAVoxell 1y ago
  It's fine, just use an AI to organise it all. Soon enough, nobody will need to know anything.