Other animals do get heart cancer, which is fascinating. It's still very uncommon compared to other cancers, but not virtually absent as it is in people.
I think the issue with Rails, as a long time developer in that ecosystem, is that much of the default assumptions are a) not common (not so far off-piste that a human can't get used to them, but outside the center of the bell curve), and b) not explicit. So it's very common to do things like install a plugin that has across-the-repo effects but that is only documented in e.g. the config directory and the bundle. Unlike, say, NPM, when you install a new package where you explicitly have to e.g. import it everywhere you want to use it.
As time has gone on Rails has gotten better about this, but it still means that "your rails" and "my rails" are different enough that AI could easily get confused.
As you say, the other aspect is the intense dynamism which works against AI, which again prefers to have everything explicit and reasonable about from the text.
So I ended up going back to Javascript after a brief 12 year digression into Ruby. I still love Ruby but it's just not the right language for the current environment and team structures - typescript is "worse is better" in the right ways that it's a much better choice for both frontend/backend being the same and better type systems.
We looked at the Solterra in 2025 and it was genuinely awful, I can't believe anyone who works at a car company looked at it and thought "this is substantially better and will sell more than the Pontiac Aztek despite aesthetically and practically being worse in many regards". The interior center console feels like a prank, almost.
Toyota, like many companies that succeed based on merits beyond the aesthetic, secretly dreams of being an aesthetics-first company like, say, Porche or Ferrari, and always tries their hardest to reject reality so that they can do the sexy-but-awful thing instead of the amazing-but-ugly thing.
You see this recently over the last couple years in tech where everyone is "an AI company" even when they make something totally unrelated - same impulse, different industry.
The problem with our economy is basically wealth concentration, partly funded by central banks and partly by lack of billionaire taxation. In a traditional economy, money was meant to always flow circularly, throughout the whole economy. Rich people could exist, but they could only exist by commanding a large upward flow of money from poor/middle people, so they had to offer something really good in return. These days the money mostly circulates between different rich people with only some loss back down to the poorer classes, so to get money they have to impress other rich people instead of poorer people. Companies who go full AI don't attract customers (unless B2B), they attract investors because the investors have all the money and the customers don't.
Bro it's so easy just save 20% of what you need above and beyond the basics of an upper middle class living, like maybe take one fewer trip to Bali each year, or cut back to only two cars per person, or timeshare your pool.
Winding your own transformer is really not that big of a deal. Especially if you work in R&D as a power electronics engineer. No one waits for the custom transformer to be delivered to your bench when you were designing a new power supply.
For high power stuff though, you need some equipment to do that since copper will hard to bend neatly.
My understanding is that wax motors are based on actuation - they are intentionally and deliberately either heated to extend or cooled to retract, and if ambient temperature is used as one endpoint, the other will not be ambient (i.e. a heating element or cooling peltier).
Thermostatic valves are ambient at both sides - they expand and contract naturally with the existing temperature, so they are not motors per se, because there's no actuation beyond the temperature.
Why does there need to be a thermal gradient? It seems like the action driving the actuator is the expansion of the wax due to temperature. You don't need a persistent heat flux to get that, the wax just needs enough heat warm up and change phase.
Edit: also, the actuation from the wax motor only happens while it is absorbing (or losing) heat, even if it later ends up in a steady state with no heat flux.
There needs to be a gradient or the wax won't move due to temperature. The motion is the change in state, as you say, but it won't change state if you don't heat or cool it.
That's why it's a motor, like in dishwashers, not a thermostat like in e.g. greenhouse windows or radiators.
It doesn't need to be persistent, but without some way to create a state that is different than ambient, it's not a motor.
Apples and apple seeds to me. The way I see it, the thermostat contains the motor (EDIT deleted the rest of explanation).
EDIT: the way I see it, talking about gradients here is nonsense. The wax motor works by expansion/contraction due to point temperature. No gradient is involved. Gradients are thermostat-level thinking, and even then, in the greenhouse scenario, there is no gradient to talk about, because the whole point is just to vent the heat from inside to outside when inside crosses certain absolute value of T, and the only "gradient" that matters is the assumption that outside side is less than T at all times.
I disagree, I think motor in this case only means “creating movement”. The motor is the thing creating movement depending on the ambient temperature.
Also you seem to have a miscommunication with the person replying to you where they are talking about a spacial thermal gradient and you mean it in a temporal sense.
no the material inflates proportionate to absolute temperature, causing motion, iiuc
things lietrally change its volume maintaining mass when its temperature changes, due to atoms moving more energetically, like something be 4x4x4 inches at 40F, but 4 1/16 x 4 1/16 x 4 1/16" at 200F
this isn't a Stirling engine with a displacer, just a sealed off piston
I think there's a pretty clear and wide gulf between "nobody could have seen that coming", or "I just wasn't on my A game", and frank negligence.
I once worked at a very large company, and one of my coworkers was like "eh, I'm not going to do any of this work, because I don't have to", and that was a clear indicator that the problem wasn't (just) with the system, but with him individually.
I've had a similar experience, also at a very large organization. In my case this person chose that kind of environment because it allowed them to work on side stuff while waiting for approvals, etc. A lot of people in very large companies don't view the grind of organizational friction inhibiting their actions as problematic.
You stop relying on the agents following instructions exactly.
You need two pieces:
a) prompts, that tell the agents what to do and how to do it (and ideally, the why, where, etc, the full picture) - that's the positive half, that drives behavior the way you want it.
b) deterministic tooling that prevents negative outcomes, like linters, compilers, static analysis, fuzzing, testing, the more the better. This side should either be firewalled off from the AI or very carefully watched so that it doesn't drift.
The part that you put in the deterministic side is the "never do x" stuff - I have lint for long comments (which AI hits every single time it commits), all my dev scripts are in typescript, precommit hooks, massive CI, and I lint even for things like redirecting error to standard out, tiny stuff, and also e.g. static migration analysis so the AI never ships an exclusive full table lock in a migration, for example.
You can’t deterministically keep them from making even a tiny fraction of all the possible errors they can and do make though.
You can’t keep humans from making those errors either but you also don’t let an error prone human crank out 20k LOC per day without forcing other humans to understand it.
C# Roslyn Analyzers[0], for example, are quite powerful and can identify complex patterns in code. One approach to deterministic enforcement would be to ensure that the project is set up with an analyzers library and mistakes that can be deterministically flagged are
Code analysis can’t detect a sizable fraction of all possible errors because for any Turing complete language the number of possible errors is infinite.
Each of these are just layers of control at different lifecycles of agent code generation. Analyzers are nice because it gives targeted, static analysis that can prevent certain classes of errors very early and at lower iterative cost (e.g. a build)
I would certainly consider Roslyn analyzers capable of covering "a tiny fraction" of possible errors :) They are quite capable of covering for many common types of structural coding mistakes.
I don't know if that's necessarily true in practice the way it is in theory. If you knock down 95% of the issues they create over a certain period of time, in practice you'll have better code than a human would write, and it's all upside from there.
I've been using languages with stronger type systems and that's also a huge boon.
Why would that be the case? You can run human written code through the same “linters, compilers, static analysis, fuzzing, testing” as you do agent produced code.
You would be surprised. Humans will do human things like be extremely inconsistent, ignore warnings (if they are not enforced as errors), skip steps because they are lazy (devs often chose to skip our pre-push hooks and preferred to run in CI and babysit the PR).
Agents can also do all of those things, but they are generally more compliant to instruction.
yes, this is a very helpful approach. I take a similar approach, partly because I find bringing up negative directions seem to bring the undesired action/direction into the agent's view and makes it more likely that they will go there
reply