Then don't hit on people. Go there with no expectations other than enjoying the activity, it makes you a better and more interesting person anyway. The people who get banned are the creepy ones who go purely for the sake of hitting on people.
"steering rules" is a core feature baked into Kiro. It's similar to the spec files use in most agentic workflows but you can use exclusion and inclusion rules to avoid wasting context.
There's currently not an official workflow on how to manage these steering files across repos if you want to have organisation-wide standards, which is probably my main criticism.
There are many licenses with mortality clauses but they are general not popular because the ambiguity and "supply chain risk" of having such a license in a dependency tree tends to limit adoption of any projects that use them.
They could definitely add a maker-checker process (similar to code review) for new versions and make it a requirement for public projects with x number of downloads per week.
I'd say the software is an asset more than the code itself, much like an interstate is an asset rather than the concrete that it consists of. The quality of the concrete impacts the depreciation (reduction of value) of the asset and how much operational expenditure is required to upkeep the asset which would again impact the asset value. There's probably also a risk management angle which should be considered.
Really depends on the region and any pre-existing constraints at the time of electrification. A better distinction is probably rapid transit (metro, subway, the Tube, MTR/MRT) vs commuter rail.
These donuts can be replicated an unlimited number of times for free without depriving the creator of the donuts of their donuts. The analogy doesn't work.
The real question is whether the value of these donuts is diminished by being ingested by the AI and it's still not clear.
With diagrams, it's still worth getting the code for the same reason we ask LLMs to write software using a programming language rather than directly giving compiled output.
Ideally there should be some first line who deals with BAU customer support but completely separating value delivery from support bakes moral hazard into the org design.
