ashishmax31

My experience has been the opposite, the HN crowd seems more sketical of vibe-coding and not reading a single line of code.

The twitter(x.com) and linkedin crowd has drank the cool-aid and are now swimming in it; Wild posts from FAANG engineers and managers saying they or their engineers dont read any of the code the LLM generates.

>With Amazon, a carpenter can type in any furniture he wants and have it arrive in a matter of hours.

Sure but that doesnt require the person to be a carpenter though right? Anybody could do that.

i sometimes wonder how all carpenters or music producers in the world would react if tomorrow a magic box arrives where they type-in/dictate what they want and voila... out comes a table/composition.. Will the worlds music producers and carpenters just "accept" this new magic genie? I would hope they wont. Yet here we are as software engineers...ready to surrender our craft to mere "prompts" with reckless abandon.

>runtime that runs the LLM with tools

This "runtime" is what you are building with LangChain.. A harness like claude code/codex etc is general purpose and its env is a shell + tools. But with a custom runtime (basically a loop where we ask llm what to do next), we can give it specific tools which we define in code. This can help with things like authorization since, well its custom code you own.. so the runtime gets the tools scoped to the users permissions etc.

The installer script installs k3s which is a lightweight distribution of k8s which runs in a single binary. It has a low resource footprint and is well suited for running on VPS boxes. While its not as light as plain docker/docker-compose, its a small price to pay for the ecosystem and tooling k8s brings.

Exactly. I've come to describe k8s as a distributed operating system for servers.

K8s tries to abstract away individual "servers" and gives you an API to interact with all the compute/storage in the cluster.

+1 to this. Especially with go, most of the (non-integration) tests I end up writing are behaviour driven tests. I'm not really sure how one can write these sort of tests without interfaces and mocks.

Could you elaborate a little bit more? These days i write a lot of go code and i end up using mock objects for different interfaces to write unit tests. Is there another way to do this?

Care to explain the reasoning behind your "no"?

Ex machina