I think the binaries wind up being somewhere around 70mb. That's insane, but these are disposable tools and the cost is negligible in practice.

With Go you can compile binaries with bindings for other binaries, like duckdb or sqlite or so on. With deno or bun, you're out of luck. It's such a drag. Regardless, it's been quite useful at my work to be able to send CLI utilities around and know they'll 'just work'. I maintain a few for scientific data processing and gardening (parsing, analysis, cleaning, etc) which is why the lack of duckdb bundling is such a thorn. I do wish I could use Go instead and pack everything directly into the binary.

You look at libraries like Effect, and it's genuinely incredible work, but you can't help feeling like... Man, so many languages partially address these problems with first-class primitives and control flow tooling.

I'm grateful for their work and it's an awesome project, but it's a clear reflection of the deficiencies in the language and runtime.

I've been thinking about similar systems for tissue cultures but I can't seem to find a way to generalize and still get good training data or effective results. Once you lose track of white balance, species, optical clarity and distortion from the vessel, etc... Results decline quite a bit in my experience. It makes it a neat yet fairly useless system outside of itself.

Granted, I have no idea what I'm doing and these could be solvable problems. Certainly much easier to solve by focusing on a single species.

I'm impressed with how well it classifies based on the image examples. A little over a million images is probably what makes it possible. My experiments have been much smaller. Maybe with more material I could overcome those limitations I mentioned, but I have a feeling the multi-species pipeline really drags it down.

Have you found that light temperature no longer skews feedback after so much training data? For me it really matters, causing classification to confuse light sources with actual plant condition (hence the colour card for white balance helping so much)

I used to dislike JavaScript a lot after learning it and PHP, then using languages like C#. Then TypeScript came along making JS much easier to live with, but has actually become quite nice in some ways.

If you use deno as your default runtime, it's almost Go-like in its simplicity when you don't need much. Simple scripts, piping commands into the REPL, built-in linting, testing, etc. It's not that bad!

Of course you're welcome to your opinion and we'd likely agree about a lot of what's wrong with it, but I guess I feel a bit more optimistic about TS lately. The runtime is improving, they've got great plans for it, it's actually happening, and LLMs aren't bad at using it either. It's a decent default for me.

Some of my top strips are the ones where Calvin and Susie Derkins are grown up and Calvin is having successive crises about everything she says or does.

I brought a surprise!

Let's hope it's a divorce...

https://i.redd.it/myocdlddt02d1.jpeg

And frankly, the bigger things, the more substantial things; those are fewer and farther between. They're harder to populate a map like this with. They're certainly preferably in some ways, but realistically, it's not the primary stuff of surveys like this.

Along these lines, an interesting category of work is when I have an LLM do something I could do myself. I totally understand the code, I instruct it all the way, I have it redo things, revise, rejig, etc... But I don't actually write any code. How responsible am I for any of that?

At work there are a ton of small scripts I use for piping data around ad-hoc, and this is often how I do it. Claude can make dumb pipes really well and remarkably quickly with reasonably clear specs given to it. I compose all kinds of specs, reports, plans, etc. using this workflow. And I find myself wondering... How much of this is me? How much credit do I deserve? The code is gone, the outputs remain, and I can't quite tell how responsible I am for the end product. It's a strange experience.

We saw what Claude Code looks like inside, and it's objectively bad-to-mediocre work, but the takeaway seemed to be 'yeah but it works and they've got crazy revenue'.

That's where we're at. The harness is kind of buggy. The LLM still wanders and cycles in it sometimes. It's a monolithic LLM herding machine. The underlying model is awesome and the harness works well enough to make it super effective.

We can do so much better but we could also do worse. It's a turbulent time. I'm not super pleased with it all the time, but it's hard to criticize in many ways. They're doing a good job under the circumstances.

I see it kind of like they're at war. If they slow down to perfect anything, they will begin to lose battles, and they will lose ground. It's a highly contentious space. The harness isn't as good as it could be under better circumstances, but it's arguably a necessary trade off Anthropic needs to make.

It's fascinating to see so many ideas and so much enthusiasm. I sometimes wonder if the fervor will die down as people realize it's still really hard to make truly fantastic software, but it's hard to say. There's a ton of inertia behind the vibe coding rush.

I also wonder if vibe coding is actually somewhat incompatible with the states of mind and contemplation that's often required to figure out how to solve problems properly. It isn't clear if you can brute force great solutions without putting in the initial domain distillation and idea incubation and so on. I'm sure there are exceptions but I have a feeling it'll never be trivial to come up with truly good and novel ideas for software, and vibing to get there might not make it any easier.

I can't imagine having such uninspired thoughts and actually writing them down while in a role of such diverse and worthwhile opportunities. I'd like to ask "how the hell do these people find themselves in these positions", but I think the answer is literally what he wrote in his diary. What a boring answer. We need to filter these people out at every turn, but instead they're elevated to the highest peaks of power.

I agree that good models have more value because a harness can't magically make a bad model good, but there's a lot that would be inordinately difficult without a proper harness.

Keeping models on rails is still important, if not essential. Great models might behave similarly in the same harness, but I suppose the value prop is that they wouldn't behave as well on the same task without a good harness.

  Location: Victoria, BC, Canada
  Remote: Flexible
  Willing to relocate: No
  Technologies: TypeScript, Node.js, Deno, Go, SQL, React, Vue, Next.js, Astro, Docker, CI/CD, Full-stack
  Résumé/CV: https://steve-adams.me/resume
  Email: steve@steve-adams.me

Lately I'm deep in the spaces between data science and engineering reliable, high-performance, resilient, yet highly-usable tools for scientists and other developers, across the stack. It's a lot of fun.

I'm also very interested in harness development and creating more deterministic agents with safety and behaviour guarantees. It's an awesome learning experience.

My work experience is diverse, ranging from SaaS to science to a bit of robots, and I'm interested in just about anything so long as it's genuinely useful, challenging, and the team is excited about it.