Discussion on "Good Agentic Workflows Are Born From Pain, Not Principles"

Thomas Portelange · 2026-09-19T19:58:57.284Z

Over the past few weeks, I have been experimenting with a more agentic way of building software projects. I started with a project template that Sol helped me generate. It seemed to cover all the typi

This really resonated with me, especially the idea that good agentic workflows are “born from pain, not from principles.” A lot of engineering decisions only make sense after you’ve actually experienced the friction they’re supposed to solve. I also liked the point about agents making unnecessary code so cheap to produce. That makes simplicity and maintainability even more important. The same thinking applies when building practical products such as CMS development services—the architecture should solve real workflow needs rather than introduce complexity just because a pattern is available.

This perspective really resonates. Many great workflows are not born from perfect theories or architecture diagrams, they come from real frustrations, repeated problems, and the need to make something work better.

The best automation usually starts with a painful manual process that someone deeply understands. Without that pain point, it is easy to build something technically impressive but practically unnecessary.

Agentic workflows especially need this mindset. The goal should not be adding AI just because it is possible, but using it where it can remove friction, improve decision-making, and give people more time for meaningful work.

I think the most valuable AI systems will come from builders who have experienced the problem firsthand and design solutions around real needs rather than chasing trends.

Great article. It is a good reminder that innovation often starts with a problem that refuses to go away.

The "audit the rules as well as the code" section is the part I'd push on hardest, because in my experience that's exactly where these efforts stall -- by the time AGENTS.md is forty rules deep, nobody remembers which incident produced rule seventeen, so nobody dares remove it. What's worked for me is tagging each rule with a one-line trailer naming the incident and date it came from ("added after an agent reimplemented locking in the in-memory adapter, 2026-03"), so an audit becomes a question you can actually answer -- has this situation recurred, or is the underlying code now structurally incapable of it -- instead of a vague fear of regressing something you can't name anymore. Costs almost nothing to write and turns rule pruning from a judgment call into something closer to a changelog review.

Ah yes, six months later, nobody remembers the pain :-) but adding a timestamp is not a real solution either: a rule should have a recoverable reason for existing. And that's the point, because once your agents.md grows too big, then you might need to refactor it. What stays is a simple rule, and a good reason for it. This rule might move to another document, or be merged with another one.

The date's doing less work than the incident description sitting next to it -- that's the part meant to carry the recoverable reason. The timestamp is just there so you can tell whether the thing that produced the rule could still happen today or got patched out since. Agreed the whole file needs to stay refactorable rather than just prunable line by line, the trailer's only useful up to the point you're merging or moving rules around, not as an argument against ever restructuring the document.

The metric-becomes-something-to-satisfy pattern in your parameter-count example is exactly what we hit with test coverage as a CI gate. An agent under pressure to move a percentage will add tests that call the function and assert nothing, technically raising the number while making the suite worse at catching regressions. Turning coverage into a review signal instead of a merge gate fixed it for us the same way your rule change did for the Options object. The "agent had to guess here" observation is the other one that's held up: those moments turned out to double as real onboarding-doc gaps for the humans too, not just interface gaps for the agent.

Search Hashnode

Good Agentic Workflows Are Born From Pain, Not Principles

Responses(6)