It's got all the indicators of being AI generated, so really not surprising at all. I lost track of how many "this, not that" and "this, but also" within a few paragraphs. LLMs tend to prefer sounding clever over simple terminology.
Thank you for the feedback.
I actually use AI as a ghost writer, but I am guilty: I usually tend to add too many concepts for a single article (even without AI).
I usually follow Divio’s documentation to reference explanations and references, but it is not suitable for a blog post
"Building an application used to mean orchestrating roles over time: one person designed, another challenged the architecture, a third tested, a fourth deployed."
What? That's not my experience at all, this lost me very quickly.
I'm sure the author means well, but it comes off as someone who lacks real-world experience sharing what they think is an ideal team structure when building apps.
That's just my opinion, but yeah, the article doesn't resonate with my experience at all, and I've been at this a while.
I just came here to post that I couldn't read past 'The complexity was real, but distributed'. I can get past these LLM constructions when Claude uses them in chat. They seriously undermine the credibility of comment pieces or guides like this one when I encounter them. I absolutely hate it when I get them in a lengthy response to a simple question to a colleague about why we're going to do something a particular way.
With all the roles and harnessing and boiler plate, it kind of makes me wonder if we shouldn't just spend a year or two doing genuinely good software development and then everything trained on it would be good by default?
Every time I read in some blog about an unproven technique which is profitable for token sellers I'm reminded of those overpriced restaurants that became "instagram popular" because the cool kids got paid a bundle of money to promote them.
In real life the only time I saw somebody try this "multiagentic coding" the results were...underwhelming.
I like the topic and I think orgs are struggling with the question:
What do our teams look like now?
But I have some big concerns with your approach here. This post is written like an authoritative summary but you admit it's not been seen working. Why is there so much untested conjecture presented as best practice here? If you had tested it you would realize this proposal is not possible in most orgs. Their "platform" will not be extensive enough to prevent misshaps by teams comprised of non engineers.
Because as a consultant I see that this model (TT) is a proven solution to the problems of cognitive load that prevent models to scale.
It will require some adaptations indeed, but I trust that this is a missing piece in the integration of AI in organisations.
But I get your point and this is the reason it share it on a personal blog and not on my company blog or in a more trustworthy source of truth.
It would be nice to see some metrics. I think the missing layer here is evaluation. If agents are going to produce applications, the platform needs not only guardrails, but public-ish evidence that those guardrails actually catch failures
There are about 3 named concepts in every paragraph.
There are about 15 claims about named concept being the solution to a problem that's never explained.
At some point, if you try to make 20 different points, you make no point at all.