The term feels broken when adhering to standard naming conventions, such as Mechanical Engineering or Electrical Engineering, where "Agentic Engineering" would logically refer to the engineering of agents
Yeah, Armin Ronacher has been calling it "agentic coding" which does at least make it clear that it's not a general engineering thing, but specifically a code related thing.
I think “agent engineering” could refer to the latter, if a distinction needs to be made. I do get what you’re saying, but when I heard the term, I personally understood its meaning.
Lots of things already violate it. The normal Site Reliability Engineer isn’t building the tools for Site Reliability but rather applies the tools to other software.
You forgot a hope-driven development and release process and other optimism based ("i'm sure it's fine" method), or faith based approaches to testing (ship and pray, ...). Customer driven invluntary beta testing also comes to mind and "let's see what happens" 0-day testing before deployment. We also do user-driven error discovery, frequently.
Why did you assume I'm talking about a "provable best way"? I meant that it doesn't make sense to talk simply about "testing" without clarifying what one means by it. If you assume that the absence of a "provable best way" implies a lack of utility, let me remind you that there is no "provable best way" for training LLMs either. Does that matter in practice?
This isn't a good approach because it assumes there are no market makers on trading venues, and that they (as well as exchanges) do not compete for order flow. Also, maybe you haven't noticed, but stocks are often frozen during news announcements by regulatory request, so such pauses are already in place and are designed to maintain market integrity, not disrupt it with arbitrary fills.
At least it could add a theoretical bound on the expected hallucinations for a particular model/quant at hand? Although I'm very skeptical that companies would disclose their training corpus, and derivative models trained on top of foundation models are another level of indirection, it would still be interesting to have these numbers, even if just as rough estimates. The compression angle in this thread is spot-on, but yeah, operationalizing this is hard.
I believe Microsoft's usual "Embrace, Expand, Extinguish" strategy is at work here. For system stability and security reasons, you wouldn't actually want agents to dynamically discover tools without proper governance. Alternatives like PydanitcAI are lost in this steady MCP noise maintained by Microsoft - their "Embrace" phase for MCP, declared during Build 2025 event. Anthropic released this open standard with weak tooling and no governance for the specs, making it easy for Microsoft to dominate.
The next step would be Microsoft attempting to make their registry the de facto choice for developers and extending with Windows-specific verbs.
Then, by controlling what's considered "secure", they can marginalize competitors.
I assume he's just being over dramatic. I use Perplexity every day, multiple times per day, and it almost completely replaced Google for me in such areas as coding or technological research. Also, I never used nor planning to use ChatGPT or Claude (I use private open models instead - Mistral Nemo, Qwen, etc.). But I also feel like "I'm not unique in this regard", lol.
My understanding is that the dataflow user was talking about a notification which the server is supposed to receive from the OS in the case of a broken client connection. This notification is usually received, but cannot be guaranteed in a distributed environment.
The assumption that your server will always receive RST or FIN from your client is incorrect. There are some cases when these packets are being dropped, and your server will stay with an open connection while the client on the remote machine is already dead.
P.S. BTW, it's not me who downvoted you
I made no such assumption this will always happen though? That's why the comment was so much longer than just "isn't TCP RST enough?"... I listed a ton of ways to deal with this that didn't involve letting the program continue happily on its path.
Sorry didn't see your message.
What I mean is that if you are not getting RST/FIN or any other indication for your closed communication channel, you only left to the mechanism of timeouts to recognize a partitioned/dead/slow worker client. Basically, you've mentioned them yourself ("timeouts, lack of heartbeats, etc" in your post are all forms of timeouts). So you can piggyback on these timeouts or use a smaller timeout configured in the lease, whatever suits your purpose, I guess.
This is what I believe Kleppmann referring here to. He's just being generic in his description.
> What I mean is that if you are not getting RST/FIN or any other indication for your closed communication channel, you only left to the mechanism of timeouts to recognize a partitioned/dead/slow worker client.
Timeouts were a red herring in my comment. My problem wasn't with the mere existence of timeouts in corner cases, it was the fact that the worker is assumed to keep working merrily on, despite the timeouts. That's what I don't understand the justification for. If the worker is dead, then it's a non-issue, and the lease can be broken. If the system is alive, the host can discover (via RST, heartbeats, or other timeouts) that the storage system is unreachable, and thus prevent the program from continuing execution -- and at that point the storage service can still break the lease (via a timeout), but it would actually come with a timing-based guarantee that the program will no longer continue execution.
