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.
I don't think you should avoid sharing it in any forum. Like I said it seems like a reasonable idea but I would just suggest being very I suppose blunt in 2026 because people skim and won't read things thoroughly. I would preface the article with "this is not battle tested"
Lest someone be frustrated when their stream aligned team accidentally exposes your whole company's email addresses on their new web app that whoops they forgot put it behind a login.
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
The 'reading effort : meaning' ratio of this post is a bit painful.
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.
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 agree with you.
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.
The complexity was real, and honestly that’s a good callout
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.
It's sort of a form of corrective antithesis (or "negation-antithesis") I think. A bit like "it's not x, it's why". Really grinds my gears.
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?
lol - it's probably going to just get worse. AI will continue to generate ghetto code and nobody cares so it will just degrade even further.
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.
(Op here)
I genuinely think that multi-agent is a probable future to enable coding at the scale of a big corporation.
I agree and I did not see it work yet, but the trial were most likely on small scale where it is simply over engineering.
(Btw : I do not sell tokens. I I think distributed the work through agents in a plateform is a way to control costs by optimizing specialised agents)
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.
I don't think you should avoid sharing it in any forum. Like I said it seems like a reasonable idea but I would just suggest being very I suppose blunt in 2026 because people skim and won't read things thoroughly. I would preface the article with "this is not battle tested"
Lest someone be frustrated when their stream aligned team accidentally exposes your whole company's email addresses on their new web app that whoops they forgot put it behind a login.
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
In real life only a minority of teams achieved good results according to Circle CI report.
And there is one notable anecdotal source proving that it is possible - https://ideas.fin.ai/p/2x-nine-months-later