sornaensis

I don't like skills. It's a really annoying form of technical debt, especially when people try to fill up company repos with random skills they think are so cool. Same goes for polluting a repo with custom instructions.

I only want the model to have the tools it needs to get the job I ask of it done.

The same reason computers keep getting faster but software keeps getting slower.

I'm curious what issues you had with haskell? I have had the opposite experience and find them dreadful at Java et al.

Surely, denser languages should be better for LLMs?

I just made MCP servers that wrap the tools I need the agents to use, and give no-ask permissions to the specific tools the agents need in the agent definition.

Both OpenCode and VsCode support this. I think in ClaudeCode you can do it with skills now.

The other benefit is the MCP tool can mediate e.g. noisy build tool output, and reduce token usage by only showing errors or test failures, nothing else, or simply an ok response with the build run or test count.

So far, I have not needed to give them access to more than build tools, git, and a project/knowledge system (e.g. Obsidian) for the work I have them doing. Well and file read/write and web search.

Without access to Opus, it seems to me that the limited context size you get isn't worth the subsidy, especially once you blow through the included requests, the cost seems kind of hard to predict because it's 'request' based not token based.

I just opted for ChatGPT Pro; I'm trying to take advantage of the increased usage limits they are offering, and from what I heard, Claude Pro was also having bad rate limiting for many people.

I define tools that perform individual tasks, like build the application, run the tests, access project management tools with task context, web search, edit files in the workspace, read only vs write access source control, etc.

The agent only has access to exactly what it needs, be it an implementation agent, analysis agent, or review agent.

Makes it very easy to stay in command without having to sit and approve tons of random things the agent wants to do.

I do not allow bash or any kind of shell. I don't want to have to figure out what some random python script it's made up is supposed to do all the time.

Good thing I had just finished migrating all of my workflows to OpenCode for the time being!

It's a shame because the VsCode copilot experience is quite good out of the box compared to all of the other harnesses I've used. But with typical lack of transparency, and sudden, harsh changes... What are they thinking?

After the restrictive rate limiting they've already instituted, I'm simply cancelling and continuing by using providers directly.

IMO the solution is the same as org security: fine grained permissions and tools.

Models/Agents need a narrow set of things they are allowed to actually trigger, with real security policies, just like people.

You can mitigate agent->agent triggers by not allowing direct prompting, but by feeding structured output of tool A into agent B.

As a rule people do not read the linked content, they come to discuss the headline.

The first indication to me this was AI was simply the 'project structure' nonsense in the README. Why AI feel this strong need to show off the project's folder structure when you're going to look at it via the repo anyway is one of life's current mysteries.

It all depends on the tools. AI will surely give a competitive advantage to people working with better languages and tooling, right? Because they can tell the AI to write code and tests in a way that quashes bugs before they can even occur.

And then they can ship those products much faster than before, because human hours aren't being eaten up writing out all of these abstractions and tests.

The better tooling will let the AI iterate faster and catch errors earlier in the loop.

Right?

I've been going heavily in the direction of globally configured MCP servers and composite agents with copilot, and just making my own MCP servers in most cases.

Then all I have to do is let the agents actually figure out how to accomplish what I ask of them, with the highly scoped set of tools and sub agents I give them.

I find this works phenomenally, because all the .agent.md file is, is a description of what the tools available are. Nothing more complex, no LARP instructions. Just a straightforward 'here's what you've got'.

And with agents able to delegate to sub agents, the workflow is self-directing.

Working with a specific build system? Vibe code an MCP server for it.

Making a tool of my own? MCP server for dev testing and later use by agents.

On the flipside, I find it very questionable what value skills and reusable prompts give. I would compare it to an architect playing a recording of themselves from weeks ago when talking to their developers. The models encode a lot of knowledge, they just need orientation, not badgering, at this point.

Weird clone of OpenFront but with no UI .. ? Custom game doesn't work, tons of errors, can't even see where I am, or understand what is going on.

Doesn't seem like you played your own game before submitting it.

Trying to go the Spec -> LLM route is just a lost cause. And seems wasteful to me even if it worked.

LLM -> Spec is easier, especially with good tools that can communicate why the spec fails to validate/compile back to the LLM. Better languages that can codify things like what can actually be called at a certain part of the codebase, or describe highly detailed constraints on the data model, are just going to win out long term because models don't get tired trying to figure this stuff out and put the lego bricks in the right place to make the code work, and developers don't have to worry about UB or nasty bugs sneaking in at the edges.

With a good 'compilable spec' and documentation in/around it, the next LLM run can have an easier time figuring out what is going on.

Trying to create 'validated english' is just injecting a ton of complexity away from the area you are trying to get actual work done: the code that actually runs and does stuff.