I think Rodney Brooke’s three laws of robotics apply here, particularly how the appearance of the bot promises its capabilities. It might have better for an obviously automated response to come back. No one might be listening but would not have been promising human empathy while faking human attention.

LLMs tends towards closed-worlds and bias towards decidability. Risk assessment is terrible, as are creating opportunities — no animal instincts to draw from.

Despite having this in the training data, I am constantly having to remind my coding agents to reason and design with grammars. On the other hand, once all of that is settled, and the task is no longer open-ended, then they are very good at driving towards completion.

Crafting the automation itself can be fun. That is one of my favorite part of designing systems running on Kubernetes.

I have also come to the conclusion that, right now, AIs lack imagination. So designing human-AI collaboration that lets human imagination in the loop would be interesting.

If we’re going by water, land, etc as an argument against wasteful activities … Coming from the permaculture world, I can tell you just how wasteful the pre-AI world is. The ideas in the mainstream environmental-friendly practices are themselves very wasteful.

I have sometimes had to work in bed while running a low fever.

I do that because I believe in the mission and work is assessed by outcome.

The flip side too — I learned well before COVID that the Kanban principle of “make work visible” applies to WFH

I wonder if the employer is in violation of ADA laws, and whether exemption from monitoring is “reasonable accommodations”.

Not that I think the broader practice for monitoring remote workers is something I think is a good idea.

Code as documentation works better when the code is declarative or a DSL. These capture intent and promises (as in promise theory) better.

When it is not, it has to be reasoned out and does not work well for documentation.

Other things that code and tests alone do not capture well:

- promises (as in Promise Theory) made to other parties. Claude already has PT in its training data.

- Constraints-inducing-properites, as in Roy Fielding / Christopher Alexander. While tests, and property testing can capture properties, there is no formal connection to the constraints that induces fhem. By constraints, I am not talking about business requirements and business value — those are better understood through Promise Theory. I am talking about things like at-least-once delivery or total ordering (from append-only constraint). Claude already has Fielding’s dissertation and Alexander’s works and ideas in its training data.

- grammars, as in pattern panguages (not just patterns) a la Alexander / Fielding are also not captured in code alone. These tell both humans ans AI how to extend a pattern, and how to identify anti-patterns (when they violate a constraint-inducing-property)

- LLMs are trained with many different worldviews and bounded contexts at the same time, and is very capable of translating across it. However, these need to be soelled out, otherwise it would talk in whatever it infers

Specifications written for the exact way components are wited together run into that stale doc problem. Although it takes much more human attention and token burn to describe things in terms of pattern language and promise theory, it becomes easier over time. The actual implementation plan tends to fall out more cleanly when all those other stuff are at least considered. This is where I have been spending most of my time.

If people are happy with Actions API, that sounds great.

I’m not happy with the Actions API. I think Gitlab’s cicd design is much better, and I’m not fighting it all the time when I use it.

i'll echo this sentiment. historically there's been a lot more flexibility with GL CI yaml syntax, including real yaml anchors https://frenck.dev/github-actions-yaml-anchors-aliases-merge...

sys-admin-ing gitlab can be a bit of a maze of web menus tho.

I find this recommendation funny, because I completely agree from a sysadmin perspective.

I used to use Gitlab at work, and small teams would run into so many footguns with CI that we had to throw up guardrails to prevent mistakes. Far too many links to gitlab issues that were not fixed even after >8+ years of being open ended up biting us. With GHA I haven't had that experience, and same for all of my self hosted Forgejo instances. I used to hate using GHA from about ~2018 to 2021, but they've fixed a lot of things I disliked since then.

What do you need real anchors for? Sharing of pipelines?

Maybe I’ve been burned too much by pipeline maintenance (because we didn’t have yaml anchors?) but I rather have builds defined in make /bazel/etc than in yaml. So the only thing the pipeline does is optionally restoring caches, kicking off the build system, uploading PR validation results, and saving cache. Pushing artifact etc is all done from inside the build system.

There is no “setup” like installing packages because we make the build image seperately.

Smalltalk also had extensibility for one. But it largely missed the explosion of collaboration when open source code became shareable and people can work on it together.

People also shared Hypercard apps.

I think it is less about client/server and more about how ideas can be shared. Sometimes, data might be shared.

I think as we see more AI participation in code, github stars are going to matter less.

Maybe they got sucked into the cool tech?

I remember my first pass reading of Stephenson’s Snow Crash and Diamond Age, I was bedazzled by some of the tech … it was later readings that the comments like “biomass” (the recent echo in AI “meat proxy”), or how the Primer was ultimately a failure sank in later readings.