However I find their claim "I've lead teams of really competent engineers and I can leave them without supervision for months and come back and not feel like throwing away the entire code base." dubious. We all know how much effort it is to keep the quality of even small patches consistent.

Design, architecture, style and refactoring still require significant involvement. Providing only a description and a criteria will likely produce hopelessly messy code, which is also what you get with most corporate dev teams.

Having said that, I won't use AI for production system if I don't understand the programming constructs in enough detail.

My main issue has been the inconsistent quality across between model releases and the tendency to insert older APIs or documentation, especially with command line tools.

I can understand if the model struggles with a million line monolithic codebase with a decade of cruft but can't think of why it'd be too much of a pain with new codebases.

Then Australian real wages have also declined. So there is already low motivation to work beyond the minimum expectation.

Australia also has strong social security, at least until now, and there are plenty of odd jobs due to the real estate and tourism industries, so there is little pressure to survive unless you owe too much credit.

Automation and technology adoption also lags behind. For example, people still wait thirty minutes on a call to get an appointment with a doctor instead of making an online booking.

For all of these reasons productivity has been low and declining. An extra day off work is a strong stimulus for squeezing what gets done into the rest of the days.

In my opinion this is an extreme, just as the work yourself to death culture in India and China is. On a scale of a few decades economies where people worked agressively harder have grown tremendously but at the expense of the long-term wellbeing of the people. Places like Australia that were well off and felt little pressure to compete have sustained good quality of life but at the expense of having no competetitve edge anymore.

Comments URL: https://news.ycombinator.com/item?id=48176432

Points: 25

# Comments: 0

Not sure how the other makes this claim when the passage he himself cites is just another clever proof in the list of clever things that maths books throw at you:

> It is easy to convince oneself that there exist infinitely many prime numbers. Indeed, suppose the contrary, that the number of primes is finite. Then there must exist a greatest prime; let it be a. To refute this assumption, imagine the new number N formed by the rule N = (2·3·5·7···a) + 1, that is, the product of all the primes up to a, plus one… The first term is divisible by every number in the list 2, 3, 5, …, a, while the second (the unit) is not divisible by any of them. Hence there is no greatest prime, and so the sequence of primes is infinite.

I'm proud of fixing everything properly but I won't repeat it ever unless the company actually has that high a bar across the board.

Comments URL: https://news.ycombinator.com/item?id=47393300

Points: 2

# Comments: 2

1. The time spent to think and iteratively understand what you want to build 2. The time spent to spell out how you want to build it

The cost for #2 is nearly zero now. The cost for #1 too is slashed substantially because instead of thinking in abstract terms or writing tests you can build a version of the thing and then ground your reasoning in that implementation and iterate until you attain the right functionality.

However, once that thing is complex enough you still need to burn time on identifying the boundaries of the various components and their interplay. There is no gain from building "a browser" and then iterating on the whole thing until it becomes "the browser". You'll be up against combinatorial complexity. You can perhaps deal with that complexity if you have a way to validate every tiny detail, which some are doing very well in porting software for example.

1. The model's default world model and priors diverge from ours. It may assume that you have another car at the wash and that's why you ask the question to begin with.

2. Language models do not really understand how space, time and other concepts from the real-world work

3. LLM's attention mechanism is also prone to getting tricked as in humans

> Before writing code, first explore the project structure, then invoke the nextjs-doc skill for documentation.

Does the model even understand what this line even means?