I actually do enjoy writing code , it’s like a puzzle to be solved and I get a hit every time I solve it. But after we started generating all code with AI at work, I feel very inefficient writing code by hand on my hobby projects. I still do it but I have become too aware now of every little struggle, like a beginner, since I know I could just pull up a Claude session at any moment and get over with it by telling it as much as “finish this thing for me”. It will know exactly what I was doing just by looking at the working tree and likely won’t even need to ask questions. I also know that without asking AI for a review, I am almost certainly introducing bugs all over that the AI could prevent. And that my tests will never be as thorough as AI written tests. So I am not sure how long I will be able to keep writing even my hobby code by hand. Perhaps hand written code will become a super niche field for certain things and I will find a place where that is still needed, but that is pure speculation. From what I see right now, it’s a matter of a year or so for me to just not be able to endure the grind of writing code by hand even if I would like to. I think this will eventually catch up with everyone, not just me and most of the industry which already moved on to fully AI generated code… but even the last Mohicans, like the Zig guys, will have to eventually give up on their no ai stance.

Got that too... but on JS's defence, I think the JS behavior is the most "natural" unless you've been trained on the other approaches (where explicitly awaiting is required for anything to actually happen). Dart and Kotlin, for example, also do that (and are not mentioned in the article - would have felt nicer to be told I must be a Kotlin/Dart developer).

This is often brought up as if it were a problem, but I see async functions as something similar to IO in Haskell. Almost all asynchronous functions I write are asynchronous because they will do IO of some sort. Async functions end up being markers of where IO may occur, which is very useful. It is very rare that I need to change a function from being sync to async (and the inverse pretty much never happens), and when that happens it's usually not a big deal (the caller is highly likely to be an async function within a short stack distance, so only one or two functions in the middle normally need to change).

In summary, async is something that looks problematic in theory, but in practice it just works really well!

If you want to have annotations on IO code you could get it using attributes - and you could even go further by using more precise annotations like `network`, `disk`, etc. The problem with using the type system is that now you need to account for the distinction everywhere (ex. interfaces/traits must support IO-based implementations) only to carry this metadata which should not affect the behavior. In Haskell, IO exists not to track a behavior but to enforce it in a lazy language. In Rust is done due to the lack of a runtime.

I recommend reading https://degoes.net/articles/no-effect-tracking . In summary, most languages could do with the Go/Java virtual thread async model dropping async/await entirely.

This is only true in Javascript though - even though you have the same function coloring aspect in most other languages with async/await, the other ones do not come with this benefit since synchronous I/O is not only possible but the classical default.

Javascript's async-everything is really unique in a domain where async is almost always bolted on to synchronous-everything in some sort of incompatible subecosystem.

I mostly do this in Dart (though even Dart also has sync IO, it’s just not supposed to be used often), but yeah other languages may not have this benefit.

Agreed on async. You better know if a function does IO, hiding that can lead to nasty surprises.

Great comment. I don’t do everything you say but still get very high quality code out of Opus 5 with Claude. Fable 5 can be even better but I haven’t proven it enough to be confident yet. It may get off the rail if you’re a bit ambiguous about what you want , but that is only rarely a problem lately. We invested early in good AI instructions while still keeping the context small . We also have lots of skills the AI is instructed to use under different tasks (eg it must always span a subagent go review code, test creation skill, planning procedure etc). When all is done I just can’t believe any human could have done a better job.

As the author, I have been using worktrees due to AI agents. And I love Magit but didn’t know it handles git worktrees so well! Thanks for letting me know, will start using magit to manage my worktrees immediately.

They just need to leave a tiny gap around the plane the Earth follows around the Sun to avoid killing us. That would cost very little for them to do.

Where’s the contradiction?? X can be just Y, and X can be much more than Y. No contradiction, just an observation that you can use it one way or another.

What makes you think it will take a long time? AI seems capable of imitating any writing style if prompted to do so already, and I think it will get better on this quickly since the AI writing style is a main focus of AI labs right now. I can see no reason at all to believe this is a matter of years still, more like a few months.

The style you refer to is the "container" of the writing. The medium. Like the specific encoding of the message. What @arctic-true was talking about was the "content" of the writing, which is bounded from above[1] by the information content of the prompt.

So, I'm not sure if it's a question of time at all: if a LLM text contains some piece of information beyond the information that went into the prompt, where does this "extra" information come from? [Note, I'm not thinking about facts which could trivially come from the training corpus, I'm thinking specifically as information in the sense of intended message from sender (author) to receiver (reader)]

[1] cf. this comment where I explain this analogy between LLMs and noise channel in communication theory: https://news.ycombinator.com/item?id=49510244

You can have a great “writing style” and still put together really crappy long-form work. The problem is that AI writing, particularly creative writing, is too repetitive, too predictable, too trope-laden.

All of the things you say are very true in the near term for short form writing - a page or two of Claudeslop will probably be much easier to swallow in a year or two than it is now. But I don’t see a path to fully AI-generated novels or long-form investigative journalism becoming mainstream in the next couple of years.

If you get an AI to review the code especially for security, it does a very good job st finding issues. Better than any human reviewers I have worked with, and getting better. As someone who works in security , I feel much less worried about security bugs on code reviewed by a AI for security issues, be it written by AI or human.

extra reviews never hurt. But trusting only the AI to both code and review security-wise? not even close to usable

Global warming is much faster in the higher latitudes. It has not significantly impacted the region you mentioned much at all. Most impact has been due to intensification of natural cycles like the Indian Monsoons, the Atlantic hurricane season and El Niño, which are not really limited to that particular area of the Globe. The idea that the problem with global warming is that parts of the world will just become too hot to live seems to be mostly misguided.