Clojurians Log v2

slop grenade, don't paste the ai, don't be a meat proxy... I've seen this idea expressed so many times recently, and agree with it

I'm not reading a wall of text someone pastes me from their LLM convo

I recently had a well-meaning colleague ask for detailed feedback on something so that they could go back and prompt Claude with this feedback. I explained that this is the same as me talking to Claude directly, but with extra steps.

In the spirit of AI disclosure, I like when people prefix something with 'an llm-assisted review surfaced that ...', but expect a human-authored problem summary to follow.

I do sometimes do this; but more in a <I have this problem> and <AI came up with this plausibly looking solution, do you agree> style.

I guess there is a difference between using LLMs as a possible tool, and to be literally proxying it to an LLM (at least, for me)

In my case, I happened to know that my feedback would be unreadable nonsense to the person. Since I knew that he wouldn’t be interested in digesting it, but rather just wanted to hand it on to the model, my reasoning applies. If the person had been someone interested in and capable of understanding the feedback, then giving it to the human still serves a purpose.

The sad thing is, their growth is being stunted. Their handing your answer to an AI means it skips the system 2 thinking necessary to build the neural connections to understand more complex patterns.

Yes, but in this case it was a non-dev building some prototype functionality and asking if it would be OK to include in main, behind a feature flag. I said, “yes, after fixing these things:“. He asked for more detail to hand to Claude, which I declined. Had the same person been inclined to learn about those technical specifics, I would have been super happy to carve out the time to teach them.

Fair enough. They were replacing a junior programmer with a BA effectively

Or even.. you.. eventually.

Well, yeah. In this case they were on a different mission: prototyping something to try out the UX of it, not to deliver production-ready code. Nevertheless, it intersected some code where it created a bit of a mess, which I was not happy with.

So in this case: better that they go back to UX and I handle the cleanup directly. The indirection would just have complected our purposes for no particular reason. He’s not tasked with keeping the code sane anyway, and can’t reasonably be expected to know the difference, while being able to try out simple things in real code is a net win for the company, even as it increases the burden on me.

This verges on the #C068E9L5M2Q domain rather than skepticism, but we’ve set up access to the production code for our non-devs. Many of them do experiment with things directly in the code now, as opposed to writing it down or paper or drawing it. It doesn’t yield anything production ready, but it does mean that their ideas are much more solid by the time we evaluate them for “real” implementation.

I don't typically mind "claude says <short human summary>" especially in triage situations, but a full copy paste is quite rude

I'd much rather they flag that they used AI to get the data in that case anyway

I hold my fellow devs to much higher standards.

Me too. Esp the devs who have been lobbing slop grenades. They get the full brunt of my wrath

I'll hold the people that should know better to higher standards (e.g. I expect an experienced dev to actually test the hypotheses and such before providing the summary). I can't really fault the juniors that wake up before me to have gotten as far as they could. They already know I'm expecting them to at least extract the info and take a best guess (just tell me what you did/found and what methods you used, in human terms)

An unfortunate side effect: since it’s possible to make something that’s appears to work correctly, it sometimes leads to me having to explain why something that took two hours to vibe needs another day and a half to bake properly. And since giving an accurate description of “why” is often technical in nature, the explanation often boils down to: “trust me, shipping this as is would be catastrophe”. It’s even worse when that catastrophe wouldn’t happen immediately, but a month in the future, and only under load, for example.

For us, we've pulled back on letting non-devs have code access for the most part after a security incident with leaked git credentials caused a bunch of problems.

Can't even have slack-based agent-mediated readonly code access going on anymore

Non-devs can still make their own prototypes, just not integrated with existing code, which also helps with the whole "integrating this needs a lot more effort" conversation

i've worked exceedingly hard to send this reply because i do slack as effectively as my nana. what i wanted to ask is that i can write unsafe code in any language — with or without and mcp server. an mcp server is just a basic, mechanical json-rpc service so what is your point?

are you against web apis’s also?

I'm against insecure web APIs

we share that

do you write them?

Feeling trolled. Blocking you

ok. im sorry my friend. i enjoyed our talks

In another thread Dan mentioned that the question was meant as a rhetorical one. In any case, I tried reading the article and maybe it's just me not being in the know enough, but I have no idea what to make of it. If you have an MCP server that has capabilities of doing things you don't want to be done, and those capabilities are exposed directly or indirectly, and you have a model that talks to that MCP server, then it doesn't matter what you do with that model. Whatever guardrails you set up, there is a path that will make something do something unwanted.

The easy flippant response is don't use software you can't trust. Servers that cache credentials are a security nightmare in general. I have a friend who is working on a project to put agents in a super strong jail. No MCP servers involved — instead each action the thing wants to take is funneled through a very strong layer that authorizes the agent based on not just the fact they are interacting with that service, but also what parameters they are allowed to send, how often they are allowed to interact, and more. But then you get to the point where you wonder — is policing these things more trouble than it's worth? I honestly have no idea. But at this point it feels so very Wild West to me.

My sister in law, who works in insurance security, told me that the tool I just mentioned is a gold mine.. they are doing all the protection I just mentioned by hand and having an absolutely terrible time reining in all the terribly secured LLMs