I mean, to be honest, I'm the one who sets the precedent for most of the teams that I work with; that's one of my roles.
And personally, I don't necessarily follow a hard line with this. My Python API services run foregrounded in a terminal with uv run, but that doesn't mean that I'm using SQLite instead of Postgres. Any of the backend services I need that don't make sense to be foregrounded still run the same versions as prod containerized. And front end teams will tend to run a containerized API service since they're not modifying it as often.
Point being there is some conscious leeway here, but it's bounded and well-defined.
I would also add that the high-quality ones are quite expensive, and that I found incorporating an RJ45 switch with an SFP uplink was more economical for the cases that needed RJ45 (or gigabit) connectivity.
The concept of developing on a system which does not closely mirror your production environment died with virtualization and containerization over a decade ago. You will experience unforeseen consequences if your development environment does not emulate your production environment as closely as possible.
If you are implementing 10 GBE at distances less than 5-7 m, I highly recommend standardizing on DAC cabling. It removes the need for these kinds of conversions that create these kinds of heat signatures.
OpenClaw is an application, not a harness. Yes, it contains a harness, but it is a complete product.
When building an agentic workflow there are enough primitives that rewriting them from scratch every time makes zero sense.
What is a tool? How does the LLM understand the tool? Formatting a native function into a serializable input/output pattern makes sense to generalize and that does not need to exist repeated in everyones application code.
We use libraries to interact with the APIs themselves; nobody would say writing a spec-compliant API client was poor practice. Agentic harnesses are just one layer above: I need to call the API and I need to do it with certain expected conventions.
Yes, Python has decorators, but they're best used as "filters" that apply to functions or methods. Cache this, serialize the output of this function always, prepare this function to be used as a tool by an agentic harness. Not registration, not flow control. You may disagree but someone has to say it; FastAPI influenced the modern use of decorators far too much in the wrong direction.
Builder patterns are a Rust convention, because Rust has no named keyword arguments. A Python function already exposes a named contract. There is very little reason to ever to sequentially pass configuration parameters in chained method calls. If you need to add state that doesn't exist yet to a constructor or factory, that is not a builder pattern. That is registration. The one place where builder patterns should be tolerated is query builders. They iteratively build on a concept and having the additional "slot" for metadata (method name plus keyword arguments) is genuinely useful. Using methods which accept single parameter instead of keyword arguments is incorrect.
There are certainly edge cases where you want native USB and display, but after initial bring up, the device is on the network, and can be managed over the network.
So, sure, nerd out and add more hardware to your rack, but I need a physical keyboard and mouse attached to a machine in my rack like once per year.
But this is a blatant misapplication of the technology in an obviously sensitive use case with an implementation that's so exploitable the people driving it have certainly never heard the term "jailbreak" once in their lives.
Reminds me of a consulting call that I had with a very large internet provider about their new agentic chat support system.
"We're going to start with the request routing layer and move that to AI agents, and then work though the individual services."
I thought it was a wild architectural decision that they would choose to roll every single action that the system handled through an experimental layer. My advice was to start with a safe, repeatable process to validate the effectiveness in the wild, and then expand in the same manner, bringing edges in as they had "solved" the individual implementations.
So, while this is almost the exact opposite of that, choosing a high-value target with real repercussions as their leaf implementation still baffles me. Step zero of any AI integration plan should be prioritization. Companies are routinely failing at this very simple, not-even-technical aspect.
Losing two weeks while you try out a candidates fit has way less cost than bringing the wrong person on formally and spending the next year debating wether they were the right choice or not with all of the associated "soft" overhead.
This is my preferred proposal to new contacts as well (I set it up as a contract so there's a little less red tape, but even people that pursue me for traditional employment afterword usually land on an extended contract).
Two things it solves: You get to evaluate me, my ability to deliver, and how I interact with your team and I either bring real value within two weeks, or I don't. I can tell you verbally I am an indispensable asset or I can show you; other people have ruined the verbal trust layer which is why this whole debacle exists in the first place btw.
And more importantly, but less communicated, I get to evaluate you. How your team works, the level of talent present, management's ability to keep direction, and wether I genuinely enjoy what you have for me to work on.
Fast is a Netflix product so the fact that you've even heard of it is in direct relation to the weight of the brand that launched it.
speedtest.net has been the first search result on Google for "speed test" for decades. Partly the boost of domain SEO and partly the boost of it being an effective exit node for searches for that term for that long.
(Nobody searches "ookla" and nobody is going to search your tier-3 .com)
agentic AI dev tooling and workflows.
CI for your AI agent team: https://agent-ci.com
reach out: [email protected]