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.
Side note: I recently suffered from a tennis elbow due to sub optimal desktop setup when working from home. Copilot has drastically reduced my keystrokes, and therefore the strain on my tenders.
I'm not sure I spend less time actually coding stuff (because I have to review the Copilot code). But the cost of the code I write is definitely reduced, because:
- the review from my peers is faster (the code is more correct)
- I come back less to the code (because I have thought about all the corner cases when checking the copilot code)
- As I care more about naming & inline docs (it helps copilot), the code is actually cheaper to maintain.
It's smarter than that. It suggests things that have never been written. It actually creates code based on the context, just like GPT-3 can create new text documents based on previous inputs.
I have used IDEs with good knowledge of the types and libraries I'm using (e.g. VSCode with TypeScript). They offer good suggestions once you start typing a function name.
But nothing gets close to Copilot. It "understands" what you're trying to do, and writes the code for you. It makes type-based autocompletions useless.
I guess you miss the point. It's not trying to suggest the perfect code. Only you know it. It's saving you time by writing a good (sometimes perfect) first solution based on method/argument names, context, comments, and inline doc. And that is already a huge boost in productivity and coding pleasure (as you only have to focus on the smart part).