The problem with the "if it works who cares what the code looks like" mindset for agentic work is that it assumes the agent has a perfect understanding of "works." Realistically, things are underspecified, agents make bad assumptions, etc.
To be fair, agents are pretty good at unit test coverage. They're pretty bad at designing human experiences (API, CLI flags, etc.), especially cohesive ones for future roadmap plans they may not have visibility into (unless your backlog is perfect and vision fully laid out, which I doubt). They're bad at knowing where performance matters and what type (CPU vs memory tradeoffs). They're bad at where compatibility matters and where it doesn't (and tend to err on the side of preserving it without further guidance). Etc.
Unless you have this ALL specified, you can't possibly claim "it works" without taking a look and thinking about it.
@mjovanovictech This is maybe not needed for registration as it can be maintained by the system administrator, but if the user has a feature to save and send an offer to the customer, then it's good to know if the email was actually sent.
@mjovanovictech The outbox pattern is very useful but comes with additional considerations. Committing the transaction does not guarantee that all steps are complete. If the background job for sending the email fails, the system must notify the user and provide options for how to proceed.
@davidfowl To me, the problem with the first one appears when you have more complex type with a longer name. Then usually I go with the third approach that wraps nicely.