KptMarchewa
Joined 7 years ago
Joined 7 years ago
- spending more time upfront working with agent on intent of the change, then design, so agent does not try to work around issues in a way that I don't intend to
- investing in ways in which agent can verify it's own change
- giving access to as much prod telemetry, etc so it can also verify the change post-merge
- obvious stuff, like automated review loops etc
But in the end I still read the "load bearing" parts of the code. Less closely, and I've long ago stopped looking at the tests. It's better for me than couple of months ago.
> Hospitals don't stop carrying backup power supply for life-saving equipment just because "the power grid downtime has improved."
When power goes down, there is an immediate harm to patients. The grid downtime would need to be really implausible. Also, batteries would probably be okay now.
When fire happens - which is rarer now - it also rarer blocks the exit in a way that causes harm now.
Good example is ETOPS - https://en.wikipedia.org/wiki/ETOPS - some time ago, we required flights over ocean to have three or four engines. Now, reliability improved a lot, and the engines got good enough that single-engine operation is not so catastrophic as before.
> FluxImp is an AI agent harness
That is a tautology
Even then, it would not solve any problems here, really.
You mean AM, right?
2030 though... isn't that like 8 years away?
No.
> How do we make sure that AI does not fake them by silently (by silent changes or by faking the test output)?
I have never seen this happen for a couple of months at least.