Too many smartasses commenting on the skills (or lack thereof) of others just because of "AI".
2. "What a spurt of productivity!" = a petty personal snide that's not in good faith at all.
3. You provide nothing in terms of what this article gets wrong or the technicalities of it. If you want to discuss flaws with the article, be specific instead of "this screams AI! clickbait rags!"
As someone who works with a LOT of AI-generated content, I'm pretty sure this is not AI-written.
So either his prompt is making the writing more palatable, or maybe he's just prolific.
In either case, I would count this as a w
10k words for "migrating code and data is a headache". Yeah. Next.
Could be shorter though, and the title might not be 100% spot on and a bit clickbaity indeed.
Also, it does not shout "AI generated" to me. The style is pleasant enough (but for the repetitions).
I honestly can't relate this comment with that article. Have we read the same thing?
Makes me think - what if all of this was written by an LLM agent?
It's just one of the signals - not the primary one.
My biggest problem with the article is the title, which is somewhat the inverse of clickbait--functional programmers are his apparent intended audience but the content is much broader.
> the author has written five engineering articles in the last week
considering you can only see when the articles are published, not written, I'd say you're trying too hard...
If it looks like a duck...
It isn't impossible that it's AI, but assuming writing and publishing happen at the same time would also lead you to conclude that Anne Frank wrote from the afterlife.
Plenty of people out there are happy to let AI do most of the work while claiming it as their own.
Even if it is, or isn't ai, the content is in fact correct.
There is no 'one' state of your application, unless you literally do maintenance window deploys and 0 queues and keep everything sync.
> Message queues are version time capsules
> Event sourcing: the version problem as a way of life
> Temporal and bitemporal databases: time as a first-class citizen
> Semantic drift: the type didn’t change, but the meaning did
> Knowing what’s running changes everything
> What if the old code just kept working?
> The right tools, pointed at the wrong level
Presentation matters as much as content. Particularly if you want somebody to read 10,000 words, making that reading go down smoothly is a good thing to strive for. If this was by chance written by a human who happened to have absorbed LLM-like writing tendencies, I would still find fault in this article for how it is written, and would suggest they spend more time revising it rather than publishing a 5k-10k word technical article daily. Much like writing code, sheer lines written is not the goal; the actual goal is to succinctly and clearly represent your ideas in as refined a form as possible. This article dragged on and on and on, with fatiguing prose, for an idea that can be well expressed without such length.
If you disagree and find this to be good writing, you are entitled to your opinion, but nonetheless this is my own feedback on the article.
> I felt as though this article was, through its headers and overuse of specific rhetorical devices, constantly trying to grab my attention in that same shallow manner.
I think perhaps you're quick to assess a certain type of writing, which many see as done quite well and in a way that's approachable and is good at retaining interest, as AI. Perhaps you just don't like this type of writing that many do, and AI tries to emulate it, and you're keying on specific aspects of both the original and the emulation and because you don't appreciate either it's hard for you to discern between them? Or maybe there is no difference between the AI and non-AI articles that utilize these, and it's just your dislike of them which colors your view?
I, for one, found the article fairly approachable and easy to read given the somewhat niche content and that it was half survey of the current state of our ability to handle change in systems like these. Then again, I barely pay any attention to section titles. I couldn't even remember reading the ones you presented. Perhaps I've trained myself to see them just as section separators.
In any case, nothing in this stuck out as AI generated to me, and if it was, it was well enough done that I don't feel I wasted any time reading it.
Good technical writing allows you to get to and understand the point in a minimum of time, has a clear and obvious structure, and organizes concepts in such a way that their key relationships are readily apparent. In my opinion this article achieves none of these things (and it also is just bad insofar as its thesis is confused and misleading in a very basic way—namely the relationship between functional programming philosophy and distributed systems design is far more aligned than it suggests, and it sets up a false dichotomy of FP versus systems, when really the dichotomy is just one of different levels of design (one could write the exact same slop article about what OOP "gets wrong" about systems—it gets it "wrong" because low level programming paradigms techniques are in fact about structuring programs, not systems, and system design is largely up to designers—the thesis is basically "why don't these pragmatic program-leave techniques help me design systems at scale" or in other words "why don't all these hammering techniques help me design a house?")
I came away with some additional understanding of the problem, and thinking there are various nascent techniques to address this problem, none of them entirely sufficient, but that it's being worked on from multiple directions. I'm not sure the article was aiming for more than that.
Thanks for clarifying, in this case it might be comparing apples to oranges as I'd be surprised if most people approach they're writing like he does