jordanbeiber

Papers in piles on a desk, where each paper is in active read/write mode can’t be optimal in any shape, way or form?

A tiling wm, or scrolling such as niri, solves this very well It’s of course designed for people actually using a computer for work rather than leisure.

Once you are used to it it’s hard to move back to windows being scattered all over.

What it used to be:

1. The rigidness of it all, which after a while is the main point ofc. Takes getting used to, but awesomeness for servers

2. The highly specialized filesystem layout requires some tinkering when trying to “just get things to work” that is not already packaged/wrapped for nixos

3. The language is… special. An acquired taste perhaps.

4. Flakes, home-manager, experimental flags galore.

LLM’s makes short work of it all, and having a devenv.sh setup of all your projects is :chefs-kiss:

My machines are essentially solid-state devices, and it all just becomes extremely predictable and stable.

I’ve been using NixOS exclusively the last few years. Its been a blessing and a curse!

My framework laptop, my NAS, my Home-assistant, etc

It’s how I’ve always envisioned “systems management”, but the struggle has been real.

Enter LLM’s - the barriers are kind of gone!

It’s actually making so much sense I don’t know where to start.

Just try it out, using a little bit of LLM support and you can reach a solid-state like setup for servers and workstations.

Well, if you work in an enterprise setting, and if this setting is just right, you can get paid well to build a lot of interesting things, and have all the choices in how to build.

Certainly not every enterprise setting is like this, but they do exist, or the setting can even be created if just enough people of the right stuff end up together.

I have kind of the same personal experience - a couple of days answering questions about the scalability and resilience of a fictional web app and enterprise integrations.

I’m very much a generalist and kept to standards and terms not specific to AWS infra. They ”passed” me but wanted a follow-up after going through some training packages to make sure I could translate everything to AWS.

At the time I was leaving a bigger software company , largely because I felt we completely locked down customers in solutions perhaps not in their best interest - so this put me off.

I realized AWS would be just the same, just on a different level.

And of course this makes sense - they want to sell their stuff!

I don’t want to sell stuff, I just want to build things.

Exactly this. Having spent almost three decades in enterprise context I see a lot of reinvention of something like a poor mans, unstructured, enterprise architecture - because AI agents.

I keep repeating ”what is good for humans in an organization is also good, or even required, for AI agents”.

Imagine every new instance of an AI agent as a new employee. With humans its ok to slowly accumulate knowledge through word of mouth, trail and error and the general inertia of larger orgs almost seem structured (or unstructured) knowledge-wise for this.

AI agents will never be useful in high value operations in a larger orgs without organizational knowledge available and reliable.

There’s a place for everything.

Most coding tasks take place outside of pure tech companies, if I’d venture a guess.

And let’s be honest, enterprises in general do not value that quality - and they face very little in terms of technical challenges that can’t be solved by code on stack-overflow or github.

What most enterprises lack is knowledge about themselves though - this is more a business problem than a technical one however.

This is most likely due to the fact that it is really bad at resetting blinker when the steering wheel is straight’ish again. Extremely annoying as any other car is much more sensitive (and sensible).

In a tesla an on-ramp to straight highway is rarely enough to stop the blinker, something I’ve never experienced in any other car.

Couple this with, IMO, the best baseline speaker system of any manufacturer… I’ve been driving with the blinker on for several kilometers at times!

Even if we still make a mess I think centralization of the mess is better than distributing it - what I mean is that polluting cities where millions sleep, eat, drink and breathe will probably be worse, net effect, than containing energy pollution to select places.

Running EVs in densely populated regions is probably a lot better for the population on the whole even if the net pollution would stay the same, IMO.

Still no EV is even better, but we’ve created a world where transport is often required so, one step at a time I guess.

Using AI doesn’t really change the fact that keeping ones and zeroes in check is like trying to keep quicksand in your hands and shape it.

Shaping of a codebase is the name of the game - this has always been, and still, is difficult. Build something, add to it, refactor, abstraction doesn’t sit right, refactor, semantics change, refactor, etc, etc.

I’m surprised at how so few seem to get this. Working enterprise code, many codebases 10-20 years old could just as well have been produced by LLMs.

We’ve never been good at paying debt and you kind of need a bit of OCD to keep a code base in check. LLM exacerbates a lack of continuous moulding as iterations can be massive and quick.

The problem is most likely not writing the actual code, but rather understanding an old, fairly large codebase and how it’s stitched together.

SO is (was?) great when you where thinking about how nice a recursive reduce function could replace the mess you’ve just cobbled together, but language x just didn’t yet flow naturally for you.

The argument is perhaps ”enshittification”, and that becoming reliant on a specific provider or even set of providers for ”important thing” will become problematic over time.

As go feels like a straight-jacket compared to many other popular languages, it’s probably very suitable for an LLM in general.

Thinking about it - was this not the idea of go from the start? Nothing fancy to keep non-rocket scientist away from foot-guns, and have everyone produce code that everyone else can understand.

Diving in to a go project you almost always know what to expect, which is a great thing for a business.