But LLMs are both really good at writing code _and_ reading code. However, they're not great at knowing when to stop - either finishing early and leaving stuff broken, over-engineering and adding in stuff that's not needed or deciding it's too hard and just removing stuff it deems unimportant.

I've found a TDD approach (with not just unit tests but high-level end-to-end behaviour-driven tests) works really well with them. I give them a high-level feature specification (remember Gherkin specifications?) and tell it to make that pass (with unit tests for any intermediate code it writes), make sure it hasn't broken anything (by running the other high-level tests) then, finally, refactor. I've also just started telling it to generate screenshots for each step in the feature, so I can quickly evaluate the UI flow (inspired by Simon Willison's Rodney tool).

Now I don't actually need to care if the code is easy to read or easy to change - because the LLM handles the details. I just need to make sure that when it says "I have implemented Feature X" that the steps it has written for that feature actually do what is expected and the UI fits the user's needs.

And it was good because it saved time.

(Same used to apply to iOS too)

My process, which probably wouldn't work with concurrent agents because I'm keeping an eye on it, is basically:

- "Read these files and write some documentation on how they work - put the documentation in the docs folder" (putting relevant files into the context and giving it something to refer to later on)

- "We need to make change X, give me some options on how to do it" (making it plan based on that context)

- "I like option 2 - but we also need to take account of Y - look at these other files and give me some more options" (make sure it hasn't missed anything important)

- "Revised option 4 is great - write a detailed to-do list in the docs/tasks folder" (I choose the actual design, instead of blindly accepting what it proposes)

- I read the to-do list and get it rewritten if there's anything I'm not happy with

- I clear the context window

- "Read the document in the docs folder and then this to-do list in the docs/tasks folder - then start on phase 1"

- I watch what it's doing and stop if it goes off on one (rare, because the context window should be almost empty)

- Once done, I give the git diffs a quick review - mainly the tests to make sure it's checking the right things

- Then I give it feedback and ask it to fix the bits I'm not happy with

- Finally commit, clear context and repeat until all phases are done

Most of the time this works really well.

Yesterday I gave it a deep task, that touched many aspects of the app. This was a Rails app with a comprehensive test suite - so it had lots of example code to read, plus it could give itself definite end points (they often don't know when to stop). I estimated it would take me 3-4 days for me complete the feature by hand. It made a right mess of the UI but it completed the task in about 6 hours, and I spent another 2 hours tidying it up and making it consistent with the visuals elsewhere (the logic and back-end code was fine).

So either my original estimate is way off, or it has saved me a good amount of time there.

They've hit the limits of iPhone sales - and upgrade cycles are slowing. Hardware products in general are "streaky" - ie. demand and sales drop in the period after a new product is released, so how often can you produce a new version and what happens if that new version isn't a hit?

Whereas subscriptions provide recurring revenue. And services, in general, can bring in more money without an equivalent increase in costs.

I recently read "Apple in China" and one of the things I hadn't realised is how many people at Apple came from IBM under Tim Cook's reign. What he's done for Apple is turn them into a predictable, consistent, revenue machine.

I do like Tailwind (I guess it fits with how I think). But to make good use of it you _do_ need to know how CSS works (for example, using variant selectors for picking out child elements, using container queries instead of global breakpoints etc).

One addition - I learnt a _lot_ about CSS by reading [Every Layout](https://every-layout.dev/).

But then, this is ruby and it's known for its unusual naming. Plus both also had sensible/boring aliases and they were for internal use only.

The older dog was sat on the stairs, sulking, as I played with the puppy (he was always very moody).

I showed her a squeaky ball; she liked the squeak so I tried to get her to bite it and make the sound. But she just wasn't getting it. Then the other dog charged down the stairs, stamped on the ball to make it squeak, then went back upstairs to continue his sulk.

But also privacy - it would be amazing to just be able to connect to any app or service you want, interact and react to stuff that's happening _over there_.

However, do you want any old app or service connecting to _your_ data, siphoning it and selling it on (and, at best, burying their use of your data in a huge terms of service document that no-one reads, at worst, lying about what they do with that information)? So you have to add access controls that are either intrusive and/or complex, or, more likely, just ignored. Then the provider gets sued for leaking data and we're in a situation where no-one dares open up.

I already do TDD a lot of the time, and this way I can be sure that the actual requirements are covered by the tests. Whereas asking it to add tests to existing code often gets over-elaborate in areas that aren't important and misses cases for the vital stuff.

Sometimes, when asking Claude to pass existing tests, it comes up with better implementations than I would have done. Other times the implementation is awful, but I know I can use it, because the tests prove it works. And then I (or Claude) can refactor with confidence later.

That kind of persistent nagging is the wrong time, with the wrong message at the wrong people.

(The other parts of marketing, IMO, are getting the right message across at the right time - to those right people. The storytelling is the message part).

Also the MacOS "Zoom" button makes so much more sense than the OSX/macOS green button - and I still miss window shading.

There are countless gems, libraries or packages out there that make your life easier and development so much faster.

But software (in my experience) always lives longer than you expect it to, so you need to be sure that your dependencies will be maintained for that lifetime (or have enough time to do the maintenance or plug in the replacements yourself).

But they still look kind of off when wearing them in public (slightly bigger than normal sunglasses, cable from one ear and other people can see the light from the screens from the side or back).

And the lack of integration is a pain - the phone has to be unlocked so is subject to random taps and swipes in my pocket.

However, an Apple-built Carplay-style projection into XReal type glasses could work very well - the question being how would you control it?

Building an iPhone app? Pretty much required.

Building an iPad app? Almost free when you're building an iPhone app (depending on your tolerance for UI/UX)

Building a Watch app? It's a popular device but is it worth the investment? Most people say no.

Building for a brand new platform where we have to live with Apple's rules? No thanks.

I'm guessing Apple and Sony would have invested in improving the process if it had hit expectations.

I read it a few months ago and was really impressed with how easy it was to read.

It starts out with simple stuff, like serialising data as JSON vs XML. But it moves into complex areas - like how replication and WALs work, including different ways of handling consensus when using leader-leader replication and how Spanner needs atomic clocks to handle it.

But even the complex stuff was explained in a way that I understood, which is an immense achievement.

It's a binary and you generally know the answer straight away.

Some people dislike it because they enjoy looking for answers and the freedom to change how things work. Others like it because they don't want to spend their time searching and mucking about with configurations.