IMO that is not a rockstar developer, but a junior developer rocking LLM agents.
Completing each individual programming task is easy. Engineering the system in a sustainable way that changes can be traced, understood and reasoned about is difficult.
The problem is, as many other comments have pointed out, typically the business doesn't value this.
Automation should always be the serialization of understanding of the system, which can execute on its own under normal conditions. When it breaks, your reaction should not be removing the automation and asking humans to get back to manual operation, that is the wrong approach. Instead, you should ask humans to leverage their understanding to step in, reason about the automation system, and fix it.
This is how I have been doing SRE for the past decade. And the inability to practice this under-the-hood reasoning is the main reason why I don't trust any modern AI based automation systems. They are helpers for some manual work, but they can't be automation.
If they are ok with shortcuts being vibecoded, maybe it's time to expose a proper programming language to the end users as well.
All my automation shortcuts can be easily explained in pseudo code under 5 minutes, but it took me ages to put them together because that weird UI/UX forcing me to drag-and-drop squares around to manipulate data structures. Programmers hate it, non-programmers can't understand it, it is not designed for anybody.
It's funny how they went from AppleScript -> "oh writing scripts is too complicated for users, let's create Automator" -> "Automator is too simple, let's create Shortcuts" -> now with shortcuts being generated by language models they need a structured scripting language again.
AppleScript even had "dictionaries" declaring their commands and everything, would have been perfect way teach LLMs how to automate applications.
I've never been more frustrated programming something than when I tried to build a non-trivial Shortcut. Things that I could have expressed in a quick script took me literal hours to compose and debug using the WYSIWYG interface. And since there's no version control, any mistake runs the risk of dislocating an element or messing up an input/output connection and breaking everything permanently.
I never care about AI usage disclosure, because I don't believe that human produced code is necessarily better than AI produced code, unless it's someone I personally know.
People need to be responsible for code they commit and push anyways. This has never changed. Whether the code is written by hand, by their cat walking over keyboard, or by AI, is not my concern.
A project's code quality can decline for all kinds of reasons. I don't think it's productive to laser-focus on whether it's produced by AI or not. That's a distraction. If a person just want to find excuse to criticize AI, and another person wants to fight back and defend AI, sure, go for it. But that's not how you would want to assess a project's code quality.
something as simple as requiring sign-offs like the DCO maybe relevant to people who care. I do think the driveby stuff may get smaller. People dont need to get stuff upstream. I have lots of patches I am keeping downmstrea and instead have a trigger system when new packages updates drop into debian and i rebuild the package with my patches on top using quill. Other systems like gentoo basically always supported this flow.
So - why bother forking or going upstream? maybe its selfish. I think publishing the patches are cool but I feel less of a need to force other people into doing what I want or even writing every possible configuration or solution. I just hack it for me
I think they meant in terms of karma/reputation for the individual, and the project. Traditionally open source is heavily based on these social currencies.
It would be nice if I could talk to my parents in person everyday, feeling their touches and temperature. But we live in different countries, so instead I talk to them over FaceTime everyday. TBH, even if they live next door, I may not always find time to visit them everyday. So having a way to use a device in my pocket to talk to them is nice. It's a compromise I accept.
On the other hand, if I live in 150 years ago where telephone had not been invented, I may never make such decision to live so far away from my parents at all.
> every single manufacturer that wants you to install their app and use their ecosystem
That's good. I don't want a single company to control everything in my house. Having multiple vendors with different implementations is healthy for the industry.
The real problem is there's nothing "smart" about those "smart home devices" to begin with. They are just remotely controlled devices. Technically, someone or something still has to control them because these devices can't really make decisions on their own. And then, to make those decisions remotely (either in the cloud or in a home local controller), every home installation needs to be highly customized. There are several light switches in my house that I never need to touch -- their states are automatically shifted based on like ~15 conditions: time of day, light conditions, occupancy, human activities(iOS focus modes). Non technical people can't do that.
I would want those devices to make simple decisions on their own (I have a few "dumb" light switches with motion+light sensors and they are pretty good already), and for complex decisions, they expose some APIs for other devices/controllers to call. Matter seems to be the right direction, but it is still controlled by a handful powerful players.
> That's good. I don't want a single company to control everything in my house. Having multiple vendors with different implementations is healthy for the industry.
Imagine that every vendor would have different implementation of TCP/IP stack.
the business does not make money unless they sell your data. open software/hardware need to be treated as public goods like utilities. thats the only way to keep monopolies out and provide the fertile ground for competion.
It just takes time to design your hardware/software stack to be able to survive reboots and recover back to ideal states. I guess nobody really enjoys rebooting machines, but at the same time, I don't think people should be afraid of doing it.
Vibe coding is fun, but I can't trust it to make any serious decisions. Like, it knows what's the best way to do a thing, but when encounters challenges, it started to make all kinds of excuses to cut corners, just like humans. "but honestly, it's cluster internal traffic so unencrypted traffic is fine". "Given the urgency and tight timeline, your best option is bypassing the pipeline and deploying it manually". "Per my research, XXX also did this so you are fine".
If I don't have disciplines or principles, or if I am just technically incompetent, its suggestions would sound so reasonable.
One mistake I see across many organizations is that sometimes they overthink how much order should matter.
Sure, your application has a dependency on that database, but it doesn't necessarily mean you can't deploy the application before having a database. If possible, make it acceptable for your application to stay in a crashloop until your database is online.
I agree with you and further will add that modularity+atomicity are the ideal state for the vast majority of software applications… but in reality, most organizations can not afford to rewrite their software to the extent required to achieve this, if it wasn’t planned from the start.
> Probably the most common change among tmux users is to change the prefix from the rather awkward C-b to something that’s a little more accessible.
I like the awkwardness of the default prefix key. I have almost never activated it by accident.
> Intuitive Split Commands
> Another thing I personally find quite difficult to remember is the pane splitting commands." to split vertically and % to split horizontally just doesn’t work for my brain.
This is super intuitive to me. two ' in parallel means splitting horizontally. two ° split by an almost horizontal line means splitting vertically.
> Easy Config Reloads
I reloaded config over a few hundreds of times in my first week learning tmux a decade ago. I only reloaded config once in the last 5 years if I recall correctly. It's not something you should memorize.
> I like the awkwardness of the default prefix key.
I am 100% in agreement with you. It takes all of 5 seconds to add:
unbind-key -T prefix C-b
set-option -g prefix C-s
To your .tmux.conf on your local laptop (where I use tmux 99.99% of the time) - without worrying about conflicting on that once-in-one-year event where you start up tmux remotely.
Completing each individual programming task is easy. Engineering the system in a sustainable way that changes can be traced, understood and reasoned about is difficult.
The problem is, as many other comments have pointed out, typically the business doesn't value this.
reply