Had a funny experience with this some weeks ago. I started developing a small side project and after a week I wondered if this existed already. To my surprise, someone had already built something relatively similar _with the exact same name_ (though I had chosen mine as a placeholder, still funny though) only 2 weeks before, and posted it in Show HN.
I took a look at the project and it was a 100k+ LoC vibe-coded repository. The project itself looked good, but it seemed quite excessive in terms of what it was solving. It made me think, I wonder if this exists because it is explicitly needed, or simply because it is so easy for it to exist?
Same here, I find most of these skills/prompts a bit redundant. Some people argue that in including these in the conversation, one is doing latent space management of sorts and bringing the model closer to where one wants it to be.
I wonder what will happen with new LLMs that contain all of these in their training data.
In the end this and all other 89372304 AI projects are just OpenAPI/Anthropic API wrappers, but at least one has 1st party support which maybe gives it a slight advantage?
I was also thinking this some days ago. The scaffolding that static languages provide is a good fit for LLMs in general.
Interestingly, since we are talking about Go specifically, I never found that I was spending too much typing... types. Obviously more than with a Python script, but never at a level where I would consider it a problem. And now with newer Python projects using type annotations, the difference got smaller.
In which way does native UI have the upper hand, do you think? To me it seems like a lot of users are largely indifferent to this aspect (e.g. so many applications nowadays being Electron/browser based). If browsers keep gaining capabilities then it seems like this gap will get even smaller.
At $WORK we have a Git repo set up by the devops team, where we can manage our junk by creating Terraform resources in our main AWS account.
The state however is always stored in a _separate AWS account_ that only the devops team can manage. I find this to be a reasonable way of working with TF. I agree that it is confusing though, because one is using $PROVIDER to both create things and manage those things at the same time, but conceptually from TF’s perspective they are very different things.
Maybe my initial message was overly harsh, I mostly agree with your points here. I think maybe the point of disagreement is exactly _how much_ extra prompt is necessary to approach 100% of the job, but this is quite hard to measure (obviously). Your point about latent space management is a good mental model to have IMO.
Ah do you mean sub-agents? I do understand that if I summon a sub-agent and give it e.g. code reviewing instructions, it will not fill up the context of the main conversation. But my point is that giving the sub-agent the instruction "review this code as if you were a staff engineer" (literally those words) should cover most use cases (but I can't prove this, unfortunately).