My take from working at a Big Corp is that individuals using coding agents can increase velocity substantially and produce good quality work, assuming they are proficient with the tools. But it falls apart quickly when you have a team trying to work together.
imo we either need to centralize the agent and and submit plan, spec, reference doc MRs rather than submitting code changes. Or develop SCM systems/workflows that incorporate plan/spec/reference/prompt metadata with code so intent can be factored into merges.
I do the same. Codex manages a per project flake.nix and uses `nix develop` for all testing. nix-direnv for my own convenience. I generally have it generate dockerfiles or other deployment assets at some point.
The distinction is scale. "AI Datacenters" are a new level of scale with new levels of power consumption and heat generation. Sure you could run regular compute and w/e in them but it's not practical to build these mega sites for regular compute. GPU Compute / AI workloads require network/interconnect bandwidth and latencies where distance matters so you're forced to solve problems you wouldn't otherwise have to. Those problems are mostly solved with money.
I'm building the same stuff I've always built. Just faster and with less dependence on others. Not having to argue with devs that have their own agendas has been my biggest benefit from coding agents.
> Not having to argue with devs that have their own agendas
Agendas like, "let's not check our API key into a public github repo" or "Let's not store passwords in plaintext" or "Don't expose customer data via a public api"?
Did you install the network connector Orca slicer prompted you to download? It's a closed source blob that runs on your PC which I'm presuming you haven't air-gapped as well.
TBF this was the case prior to the firmware change. It wasn't a bait and switch. It just wasn't obvious to someone buying a printer they thought worked with open source slicers.
There's a few dimensions you can look at for gpu load. Probably the easiest indirect metric to watch for gpu load is power usage.
But if you really care about this, you should actually profile your application. nsight systems makes this pretty simple to do. Dunno how many actually care about having a TUI.
Power is useful as a second-order metric and can help catch drastic underutilization, but it has similar problems to SM Active (DCGM) -- it tends to overestimate utilization and doesn't distinguish between useful compute and memory traffic. It's very possible to be in a memory-bound workload with high power even though underutilizing compute utilization. Our goal was to separate these bottlenecks out so there's more visibility into where to optimize.
On nsys, agreed it's great, but we wanted something that could run continuously instead of an offline analysis tool. We think there's room for both to be useful.
I previously worked at a managed database as a service company. On more than one occasion during my time there, a junior engineer deleted a customers database and at least one time one of our most senior dbas made it unrecoverable. Never got such straight forward confessions out of them.
reply