$ cat $(which whatsapp)
#!/bin/dash
# A kiosk is full-screen by design. You need to go to about:config and toggle
# full-screen-api.ignore-widgets to true to prevent our window manager from
# creating an actual full-screen window.
# Additionally, you need to set the name to "kiosk" which will set the app id
# under sway to "kiosk" so that in sway you can disable full-screen on
# startup.
firefox --name kiosk -P whatsapp --kiosk https://web.whatsapp.com/
IYKYK. Zero rice. Zero rizz. Sort of person who does things like this would have at least a little rice. Look at Tsoding’s i3status to see what I’m talking about.
This works great as long as you are not doing what the parent comment cautions you to not do: Let agents decide the architecture.
The moment you do that, why even bother producing a result.md? Just let the Bot execute on its findings, you realistically won't be able to judge them anyway.
I've built many things this year letting sota models design the architecture, and they've been well-reasoned about it.
I think what you describe is a lack of harness/infra/process around working with agents on a project. No effort to document ADRs. No effort to document invariants. No effort to design processes that ensure maintainable software even if it were five years ago and only humans were writing the code.
Just because you delegate important decisions to AI doesn't obsolete practices as trivial as maintaining a log of potential issues in your codebase that you'd want to work through, keep track of, and verify.
> There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, [...]
Why would they cover programming? That's what all the books on programming are for.
Also I see no need for signal processing to make programming a hard problem. Writing correct code is hard. Writing code that makes incorrect code easy to spot and hard to write is hard.
You can be great at local maximums, communication, establishing support for executing a plan or creating alignment on big efforts, and proceeded to still create a ball of mud. Bug ridden, hard to read, hard to debug.
A buggy big ball of mud that does mostly the right thing is still going to beat a high-quality, carefully architected solution that reliably does the wrong thing, though.
And for a huge amount of code, it's not very hard to make it good enough, because the requirements, once understood, are pretty straightforward and perfect correctness often matters much less than you would think.
"carefully architected solution" is not what they are saying. A "buggy big ball of mud" will not generally "do the right thing", if it did, it would not be a "buggy big ball of mud". Straightforward requirements do not imply straightforward solutions. In the early 2000s Facebook wanted a quick way to search for friends updates, a straightforward requirement. Turned out they had to build a full graph DB inside MySQL, not straightforward code at all.
Volkswagen is perhaps the greatest counter-example. The union in Germany converted every layoff initiative in whole or in part (more often in whole) into partial retirements, backfill stops, reduced working hours, compensation freezes.
>there is a real risk that what arises is labor immobility and blocking new entrants.
We're already doing that without uniuons. Older folk can't afford to retire and new grads cannot get a leg in to start their careers. we're talking something like a quarter of new grads who cannot get any job in their field out of college.
Wait a second, are you arguing that it’s better to just straight up fire people? In that case, the company is absorbing the lion’s share of the profits (or whatever profit is left) so you are effectively arguing in favor of shielding an entity over the livelihoods of the people who work within it.
To butcher a famous poem, it's better to have hired and lost than never to have hired at all. Restrictions on letting go of enployees mean that companies are afraid to hire. They double check and triple check, they reject everyone they feel even the tiniest bit suspicious of, they try to protect themselves with ultra long probation periods, etc.
I don't know about the US, but I spent 4.5 months trying to get a new job here in the EU as a senior dev. Everyone tells me that was quick.
reply