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.
Same - I can sense the value here and I can see how I can transfer some of the ideas to my team (based on the image), but the volume of text diarrhea made me realise "this person took the lazy way out and didn't create something for their audience". I stopped reading at second paragraph.
What I mean to say is that AI ghost writing is fine (I see the comment by the author). Deciding not to read poorly written content is also fine (and there's a reason why writing style has been discussed as long as the printed page has existed).
With the speed at which HN readers can identify mass produced, AI-generated word salad, it is insightful to look at a what users aren't able to stand back from their outputs and view them from the intended audience perspective
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
And for the love of reading, please do not bold stuff all the time. It's the single worst thing for reading attention. I can't help but jump from bolded text to bolded text and in the end I'm not reading anything.
The author is advised go avoid falling for AI Loopidity. It's more valuable to just share the bullet points someone feeds a prompt to produce a blogpost than to wade through AI slop of a blog post that people have to use AI to summarize.
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.
"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.
It reveals the exact type of mindset that could produce an article like this. All they know is waterfall, so they see agentic coding and think: "you know what we need? More waterfall"
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?
I actually think it is people who write using these terrible short punchline sentences. In my experience, llms do better job at generating complicated sentences.
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.
Regarding your link I'd question any blog post written by a CTO. This is just fodder for their next job.
"Productivity is the efficiency with which resources (like time, labor, and capital) are converted into useful goods and services"
So they increased productivity "number of PRs".
Shipping more does not guarantee shipping better or more impactful features.
Many orgs are constrained by product decisions, not engineering speed.
If there was so much value to unlock through AI then why did Intercom/Fin sell to Salesforce?
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.
Please take my comments as friendly suggestions in your pull request. I am not intending to shoot you down friend.
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.
Same - I can sense the value here and I can see how I can transfer some of the ideas to my team (based on the image), but the volume of text diarrhea made me realise "this person took the lazy way out and didn't create something for their audience". I stopped reading at second paragraph.
What I mean to say is that AI ghost writing is fine (I see the comment by the author). Deciding not to read poorly written content is also fine (and there's a reason why writing style has been discussed as long as the printed page has existed).
With the speed at which HN readers can identify mass produced, AI-generated word salad, it is insightful to look at a what users aren't able to stand back from their outputs and view them from the intended audience perspective
Absolutely
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
> I actually use AI as a ghost writer
With all due respect, it shows. You have the ability to write way better than this.
I was halfway through and thought to myself, "Why is this so fucking hard to understand the author's point?"
The subject sounds extremely timely and important and is something HN readers really crave, but the rambling article just isn't doing it justice.
And for the love of reading, please do not bold stuff all the time. It's the single worst thing for reading attention. I can't help but jump from bolded text to bolded text and in the end I'm not reading anything.
The author is advised go avoid falling for AI Loopidity. It's more valuable to just share the bullet points someone feeds a prompt to produce a blogpost than to wade through AI slop of a blog post that people have to use AI to summarize.
It refers to Team Topologies, which is mostly that. Management literature fluff with little substance, but many claims.
Which then gives you great insights like
"a team can only be effective if it carries no more complexity than it can absorb."
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.
[flagged]
"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.
It's written by a large language model, I wouldn't expect it to mean anything
It reveals the exact type of mindset that could produce an article like this. All they know is waterfall, so they see agentic coding and think: "you know what we need? More waterfall"
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.
Please fix your writing and make it more user friendly to the users you want to read it. As of now, it reads like unedited AI slop.
I actually think it is people who write using these terrible short punchline sentences. In my experience, llms do better job at generating complicated sentences.
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.
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
Regarding your link I'd question any blog post written by a CTO. This is just fodder for their next job.
"Productivity is the efficiency with which resources (like time, labor, and capital) are converted into useful goods and services"
So they increased productivity "number of PRs". Shipping more does not guarantee shipping better or more impactful features. Many orgs are constrained by product decisions, not engineering speed.
If there was so much value to unlock through AI then why did Intercom/Fin sell to Salesforce?
ref: https://www.salesforce.com/news/press-releases/2026/06/15/sa...
(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.
Please take my comments as friendly suggestions in your pull request. I am not intending to shoot you down friend.
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.
And thank you for your comment, no offense taken. I post here to get valuable feedback like yours.
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
I fully agree
[dead]
[flagged]