I can strongly agree that OpenAI should not have put Kenyan workers in the position in which they were. I can also agree that they should take steps to ensure that it does not happen again. Hao's frequent retelling of the story in interviews tells me nothing about what is being done to address this concern.

The criticisms of potable municipal water usage by datacentres in the book are hard to fault, but they have little to do with what most people think of as generative AI. Again, it does little to aid understanding of the resource usage of contemporary datacentres and the politics of their siting.

Hao's other frequent complaint about the generality of large language models also doesn't land with me, because it is their very generality and ability to draw on a plethora of fields (often unexpectedly and without prompting) that makes them so useful to me and many others. Combined with the ability to research and treat these as jumping off points, the generalized models become tools for broadening ones' horizons.

Perhaps I should have had more faith in Opus's ability to complete tasks like these, but it just hasn't been my experience to date. Opus and 5.5 work great within constrained user story type tasks, but I just don't have confidence in them to complete a large unbounded task like: "find out why the shared dependabot automerge component isn't working on this one repo, then formulate a strategy to roll it out across these 90 other repos, ensuring that Python, Rust, Typescript, go, sensible, and GitHub actions are all correctly updated. Address any CI failures, codex and codescene review comments in your PRs, then merge on green."

Some of that can be done mechanically or trivially, and Fable knows to write a script or deploy Sonnet for those instances, but other times there are complications that need to be overcome that need to be escalated. Then there are patterns that can be picked up in large migrations and fed into template repos or tooling.

I won't use Fable for everything, but if there is ground to be broken on a new concept, being able to build a prototype with Fable might be useful.

I also have some substantive migration tasks such as replacing a static front end with solidjs or moving from NLL to Polonius that I would like to use Fable for.

It certainly feels like over the last fortnight it has enabled a substantial amount of transformative change in my codebases.

- Shaping work so it is more decomposable, legible, verifiable and understandable

- Property testing, formal verification (exhaustive proofs, and bounded model checking), and test verification (e.g. mutation testing)

- Understanding product market fit and opportunity space

- Application of product management techniques (e.g., constraint, risk, and management by exception)

- Hypothesis forming, validation and falsification

- Evaluation of systems (agentic systems and toolsets used by agents)

- Effectively shaping domain knowledge into agent context in a way that stays current

- A greater awareness of o11y and cost recovery

- User experience, developer experience and agent experience

I'm not suggesting that developers should replace UX engineers or product managers (in fact, I think that demand for experts in these fields will grow with the volume of software). I am also not suggesting that these growth areas are not things developers need to be mindful of now, but that the need for by default application of automated development rigor will grow.

I see this as more or less analogous to the DevOps shift of the mid 2010s. Developers will grow their horizons, become comfortable with achieving more and moving faster safely, and ultimately put more trust in observable and legible delegated systems rather than doing things by hand.

Claude.ai is pretty frustrating too. It will talk to me as if anything I ask for is below it. Could be the system prompt I use, but I did not have this issue with 4.6.

Yes, I tend to prefer GPT, but I can't remember having GPT ever refuse a direct instruction that wasn't an obvious ToS violation.

https://github.com/adamraudonis/prylint/blob/main/harness/ch...

Having pylint reimplemented in Rust seems like a very useful thing to have from my perspective. I get another several x speed up, and I can stop having to worry about a separate python interpreter used for one tool that is a few Python versions behind my codebase.