Is "Agentic Engineering" is the new name for "Agent Experience"? If so, and even though I love Simon's contributions, there are many other guides to making codebases more welcoming to agents...
I don't agree with the premise that we pay a subscription because there is no better and cheaper alternative. We pay Slack subscriptions but we could get IRC for free. We pay Google Drive subscription but we could get rsync for free.
The reason we pay a subscription is because the company that built the software knows our business, knows how to get in touch with the decision maker, and knows how to market their product as something desirable. The actual software has little influence in that decision.
On the contrary, I think the price of SaaS subscriptions will go up as a result of AI. Because the only customers who will switch to a cheaper (or home made) alternative are the ones for whom the software is a commodity. These customers used to form the long tail of subscriptions, usually on the lower tier. When the entry pricer disappears, and the software editor has to generate a high return for their investors, the only way to keep profitability is to increase the price for the other tiers.
I think this article misses the most important point of MCP: Authentication. Granted, it wasn't in the initial spec, but it is now, and it really opens interoperability without compromising on security.
Think about how to provide your SaaS service to users of ChatGPT or Claude.ai (not only coding tools like VSCode). At one time, the user will need to allow the SaaS service to interact with their agent, and will have to authenticate in the SaaS service so that the agent can act on their behalf. This is all baked in the MCP spec (through OAuth) [1], and scripting can't beat that.
That's why the Extensions/Applications marketplaces of consumer AI assistants like ChatGPT Apps [2] are a thin layer on top of MCP.
Another domain where MCP is required is for Generative UI. We need a standard that allows third-party apps to return more sophisticated content than just text The MCP spec now encloses the MCP Apps specification [3], which is exactly that: a specification for how third-party apps can generate UI components in their response. On the other hand, scripting will only let you return text.
I've closed my share of AI-generated PRs on some OSS repositories I maintain. These contributors seem to jump from one project to another, until their contribution is accepted (recognized ?).
I wonder how long the open-source ecosystem will be able to resist this wave. The burden of reviewing AI-generated PRs is already not sustainable for maintainers, and the number of real open-source contributors is decreasing.
Side note: discovering the discussions in this PR is exactly why I love HN. It's like witnessing the changes in our trade in real time.
I love reading the posts in this thread. It seems the waterfall vs Agile debate is still vivid in the HN community, which surprises me.
I know that developers have different experiences with SDD, and there is no one-size-fits-all methodology anyway. It's interesting to read the feedback of people who really like it, especially when they describe their background and the type of project they use it for.
In my experience, SDD doesn't bring any value as I'm already using Plan mode before going to implementation. I have also never seen instances of a coding agent doing exactly what I had in mind in the first try (except for very simple cases), so there must be iterations, which defeats the purpose of the Big Design Up Front.
Finally, I really think coding agents pave the path for a new way to develop digital products, more productive and closer to the users' expectations. But I doubt that SDD lies anywhere in this path.
The article mentions XML, but the true revolution is JSX itself, which lets you describe any piece of logic as a React element. This opens the possibility to create DSL for everything, just like in Python.
This is nice, but I wonder about the actual use cases of such a service, given the very loose permissions:
1. Anyone can subscribe to a channel
2. Any registered user can publish to a channel
3. Only registered users can publish to their personal channel (@username)
The second point in particular is problematic. I don't want to add notifications to my app, only to have a script kiddie use is to spam my users.
OP is making a decision about a complex problem using only back of the envelope calculation and without looking for scientific studies on the matter.
We’re not obliged to take their advice.
Typing “AI Carbon Footprint” on Google Scholar brings much better info than this post.
Evaluating the quality of the responses of AI agents used to be tricky. It required knowledge of eval criteria as well as third-party tools like promptfoo, ragas or prometheus. Now openAI makes it ridiculously easy with a new API endpoint. It can grade a completion against a reference response, assess its format and tone, and you can even promt the eval to add your own criteria.