steve_adams_86

Whoa

This could explain needing to blow through my limits last week. So much of it’s outputs on xhigh needed serious revision, and took much longer than usual to meet specs.

I’m only prototyping so most of the code will be discarded, but even in this circumstances you can’t allow too much sprawl and decoherence within a single project. It makes prototyping cost so much more over time. It was pretty frustrating.

Huh, I thought I was paid on the lower end for my field. Well, I suppose I still am (working for a NGO), but £30-35k is absurd. That's not reasonable for any skilled role, really. Why do people accept it? Are salaries for software in the UK generally very low? Even lower than Canada? I find it hard to believe, but then, I have no data to go off of.

I totally disagree. I respect efforts made without LLMs, but if a person is enabled by one to express their creative ideas like this, that's awesome too.

I think one thing to note here is we've got different audiences. I built this for a team of scientists, not developers.

That aside, the MCP middleman in this case provides a few things:

1. Most importantly, it models and enforces the complex domains of the API and underlying data in a way that most people can't easily, so it maps English requests to sensible queries effortlessly. Claude uses discovery endpoints and constructs queries in seconds, is instructed to check parameters about each endpoint, and generally handles a lot of domain-specific concerns that users typically won't have a full grasp of.

Imagine a sensor network with dozens of stations and thousands of sensors. Which one should you query, for which type of data? What parameters does it take? How granular is the data? These are easy to keep track of if you're familiar with the station and have some API requests on hand that you lean on frequently. It's much harder when you want to know things about an area or type of sensor data you're less familiar with. The MCP server solves for this quite well. You can write things like "How much chlorophyll was in the ocean in the summer months of 2025 near Victoria, BC?" and it can map that to stations, then to sensors (some named chlorophyll, some named fluorometers, some named after the manufacturer's model name, etc). And yes, this can be done with a skill, but my experimentation with this was disappointing. The MCP server provides far more consistent results.

2. Less important, but the API doesn't presently differentiate between users. They have access or they don't. The writable endpoints should not be accessible to Claude, so handing it a token is not acceptable. The MCP server ensures Claude's use of the token is limited. This takes less work than rebuilding auth for the API. We could use a read-only proxy instead, but on its own, this wouldn't help my team much.

3. The API already does return consistent results. The problem lies more in the direction of knowing how to query it.

I suppose a followup point is that the code driving the MCP server is testable and provides some guarantees about the system's behaviour, which allowed me to progressively improve its end results and determinism. I don't know how to do that with skills. I'm also solving a problem for less technical users, so I can't set them loose with a skill and a terminal to begin with.

I used it for a project with okay results. The point was to share our org's data in an accessible yet very flexible manner via Claude. The idea is that the MCP server provides structured, reliable means of querying and then presenting the data in predictable and useful ways, with a bunch of checks and balances along the way.

It was possible without MCP, but arguably this convention made the whole thing a bit more reliable and consistent. It also provides some safe guards against how people might get this data alternatively. People can now ask "What was the ocean acidity like for January 2016 to March 2017 in the Salish Sea? And Claude will reliably draw up a graph for all stations in the Salish Sea monitoring this parameter, report which values have or have not been QC'd, show a map of the stations' locations, etc.

It works better than a skill. It allows me to integrate a protected endpoint more easily for the end users. It only knows about read-only endpoints. No risk of people handing credentials to Claude to make it easier. Overall it makes it pretty seamless to bundle a bunch of domain knowledge into the server, providing access and empowerment to a team of scientists who can but would really prefer not to write API queries when they have one-off questions about our data.

It could also be done with a CLI or something, but, the goal is to provide a powerful interface using simpler tools. An API or CLI would defeat the purpose.

> you get a six-pane interface that imho is pretty overwhelming

Agreed, and it probably doesn't need to be overwhelming but the design choices leave the intent and purpose of the UI fairly unclear. It requires a bit of clicking around to understand what it's all for, and it's quite flat and unappealing, leaving little drive to do that work.

What do you get out of T3? What's the appeal?

Remember when 200k was a HUGE context window, but you still had to be precious about how many files you'd paste into it?

We are kind of spoiled today. It's easy to forget how insane it is that you can write a program in Go or Rust and build a binary for all major operating systems with a single command. It's so nice

There are so many people using TLA+ and Lean via LLM without realizing that the proof might not even prove anything about your code

> They suck ass at troubleshooting systems

Given the right tools and instructions I find them to be consistently superhuman. It's unreal.

I have an automated system responding to issues occurring on oceanconnect.ca, and every single diagnosis has been correct for months. Of course I still verify, I tune solutions, I review everything. But it's right. It's not a trivial system. It has a fairly large frontend, a large-scale model processing pipeline on the backend, a fairly complex database, and a queue for getting new data into the system. Claude does a stellar job of navigating and understanding problems, even when they're not 'real' or as they initially appear to be; things like quirks in old versions of Safari, or the model pipeline fails due to data integrity issues from the providers.

I've rarely encountered cases where I need to steer a frontier LLM much when troubleshooting. They're exceptional.

Is anyone else finding that it doesn't pick up Claude Code agents? My Agents pane stays empty no matter how many instances I start and work in. Appears to continue to work fine in herdr, though.

I don't know, strange things happen. The other day I had to rotate a bunch of credentials because a coop cloned a private repo, made it public, and checked in a .env file with production database credentials... 5 years ago. And they still worked. No idea how that wasn't exploited, honestly.

(I wasn't around for this, I just found it)

A little sad in a way, but this seems like the right call. I haven't used Pico in a very long time, and I don't think I'd choose it today.

My comment wasn't meant to imply anything of the sort. I think you can adopt AI aggressively without being a total dickhead, more or less. Doing it at direct expense to others' well-being is clearly a problem. I'll read the nested article to see how wrong I am, but the initial post that's linked didn't seem to indicate Proton have gone to the dark side. I'd need more evidence to judge them like that.

I wasn't aware of cruelty; just that they are opting to use AI. The tracking of AI produced code is tough; I have that at my org too, but it's more so to get a sense for who's using it, so we can find out why, help them use it better, etc.

I also only read the initial post and not the entire 404 article. I suppose if I could edit my comment and have it maintain some posterity, I'd say something like "going all-in on AI doesn't make you evil", but I concede that these guys could certainly be assholes if there's more to it (I'll read the nested article).

This doesn't make them bad guys, though.

edit: stating this based off of the linked post, but will read the article linked in the post as well.

edit edit: Okay, yeah. This seems like an awful place to work.

Where I work, we take on way more exciting and ambitious projects than we would have when I was hired. It's exhilarating at times. Genuinely, AI in general (not just LLMs) has radically transformed the types of work we can conceivably pursue and deliver on. We're an NGO so we have different staff than a regular tech company, but we're highly tech-driven. I don't doubt that this is the case at many orgs like ours.

And it's measurable. We don't just feel more productive; we get grants, we build systems, and we make plans we simply couldn't have before.

In trying to understand how this was possible, I read a bit about how the underlying system and safety protocols work. It's remarkable how much the operators got wrong here. My instinct was to think that this was bad engineering, but no, the system's only flaw here is that it allows operator discretion in degraded security modes. In this case, wow, they made some really poor choices. Unreal.

Likewise, I was left feeling like this is just more fodder for the circus. Tesla's stock is attention-driven more than anything at this point. By that measure, this car makes sense. By any other, it's more grift and gimmick.

That's okay, though. Agents are an abstraction no one will really need to understand. They will still benefit from it when they press a button to 'do the thing' which previously required a human.

> Maybe this time is different

It is in the sense that you performed tasks for people, and knew which tasks needed to be performed. The advent of agentic programs now means those same tasks can be deduced by the agent and also performed by it. There's a very thin moat between you and that, now.

Rather than attempt to be random, knowing that I'm not, I wanted to see how well it can predict Math.random:

    setInterval(() => {
      const num = Math.round(Math.random() * 10);
      const ball = document.querySelector(`.typed-pad .ball-${num}`);
      if (ball) {
        ball.click();
      }
    }, 1000);

This isn't very interesting, but it scratched an itch I had to see what would happen.

    The house's record

    The house called 18 of your 190 scored numbers: 9%.

    Blind guessing would average about 21.1 of them (11%).

    Only 1 of the 206 people in a psychology study was more random than you. The house found you extremely hard to read.

I really want to know who was more random than a RNG

I understood what it was after a moment of looking at it, but had to sit and wonder why they thought it was a good idea. What am I missing here? This looks weird.

They did push it for gaming at one time, but it fizzled out since then. At one point Arcade was pushed pretty hard, and they presented Apple TV as the premier place to play it.

I've used it for a total of a few hours in many years, almost exclusively for mini motorways. It never made sense to play over the Switch or PS5. I'm not sure who's using it.

I ran into similar problems. My analytics became so useless that I threw them out.

Most of the world disagrees and eats/enjoys tons of beans.

Lots of people = almost all people in the USA, according to research I’ve seen. I’m not sure of exact numbers, but I recall it being somewhere close to 95% of people being deficient to some degree, with the majority of that group being quite deficient.

Related, the healthiest sources of protein are very affordable and typically come with a ton of fibre. You can have both very easily