My clankers are instructed to use "Outside In development" with "red/green TDD" at all times.
They write really good Gherkin features and then work inwards writing unit tests as they go - checking that they fail before implementation so it's actually testing something worthwhile.
And the code they ship is decent quality (not as good as me most of the time - but a LOT better than me when I'm tired or I'm pissed off about something or the work is really boring).
I really liked the 12" MacBook (although my all time favourite computer was the 12" PowerBook G4 - chunky by today's standards but I just loved it).
I saw a review of the MacBook Neo where the reviewer was yearning after the 12" - but suggested that Apple has made UI elements so big with such ridiculous spacing and border radius that it would be almost unusable at anything less than 13".
Which would not surprise me in the least - I struggle with my 16" MBP and this crappy UI "framework".
I've only ever sat in a Ferrari, never driven one, but the interior looks exactly like what I'd expect from a modern Ferrari.
As for the exterior, I really don't like the front - but I think that's because a tall Ferrari is just wrong (for example, I think the Purosangue looks incredibly generic too).
The worst I would ever get was "here's our Access database - can you rewrite it". That was utterly useless to me.
What I needed to do was sit with a user (not a manager/the person buying my services) and ask them to show me the different things they did with the software. Then I could write a spec for the actual _feature_ and would only need to look at the existing codebase if they needed data transferring across[1]. I don't see why our new LLM-based future would be any different
[1] Of course this meant I would leave out edge-cases and/or weird quirks of the system - often this was actually a bonus as they were either no longer relevant or worked that way because that was the only way they knew how to do it
When I quit my day job and started Rails freelancing a big chunk of my work was from companies with "that tech guy" who had built a database in Microsoft Access that was vital to the department's operations. And then either left the company - or the app had started to fall apart under its own weight.
I would get called in to rewrite it, using a proper database, documented rules and ensure it stayed scalable - and everyone would be happy.
These Access "apps" were abominations from a technical point of view - but they got the job done without having to spend a load of money on off-the-shelf or bespoke software. And the "tech guy" made a valuable contribution to the company. It's only at a certain point that Access started to struggle.
I foresee the exact same thing happening in the near future - except we won't be building the replacement apps ourselves - we'll just know how to give the coding agents well-specified prompts and tell them when they're making a mistake.
Minor correction - Xerox knew they could not commercialise their invention so they wanted someone to take it off their hands. So Apple didn't copy - they paid for it (in stock, not cash) - and if you've ever used a Smalltalk environment you'll know that what Apple actually shipped (in the Lisa and then the Mac) is a _lot_ of work done over the top of what Xerox had.
If the account is to be believed that's not what happened. They asked the LLM to do something on the staging environment, it chose to delete a staging volume using an API key that it found. But the API key was generated for something else entirely and should not have been scoped to allow volume deletions - and the volume deletion took out the production database too.
The LLM broke the safety rules it had been given (never trust an LLM with dangerous APIs). *But* they say they never gave it access to the dangerous API. Instead the API key that the LLM found had additional scopes that it should not have done (poster blames Railway's security model for this) and the API itself did more than was expected without warnings (again blaming Railway).
I'd add in "code is easier to write than it is to read" - hence abstraction layers designed to present us with higher level code, hiding the complex implementations.
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.
As a long-time Mac user, "it just works" actually meant "it either works or it doesn't" - a *binary*. Whereas other OSes were shades of grey - it _might_ work if you spend time searching and trying random combinations in settings.
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 agree it's not just React - I think a lot of people simply do not know what CSS can do nowadays.
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).
I remember writing a function to convert a string from snake case to camel case and calling it `humpify`. And another that would take a string and locate the constant with that name called `constantinople`.
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.
(slightly off-topic) Many years ago, I got a puppy to keep my older dog company (it was as disaster as she was an over-excited nightmare and in the end I gave her to a friend, where she lived a happy life with two other over-excited dogs).
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.
My favourite way to use it is to write tests first, then say "make these pass". It will generate some code, run the tests, say "oh, there's an error here ... let's fix that ... oh, there's an error there, let's fix that ..." and (most of the time) it will reach a solution where the tests pass.
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.
People often mix marketing and sales. For me marketing is about "understanding your market". You wanted an iPhone because His Steveness knew what many people were looking for in a phone.
(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).
There's a whole section in the article about experimenting with different positions and weights of the haptic feedback as the dial is moved and how to tie them in to the display on the control itself.
They write really good Gherkin features and then work inwards writing unit tests as they go - checking that they fail before implementation so it's actually testing something worthwhile.
And the code they ship is decent quality (not as good as me most of the time - but a LOT better than me when I'm tired or I'm pissed off about something or the work is really boring).