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.

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.

The incident link is valuable, but I'd be careful not to let the timestamp do too much work. It tells you when a rule was added, not whether the failure is still reachable. I'd want each rule to point to a reproducible regression test or the specific structural condition it prevents, so pruning can be based on evidence rather than the age of the incident.

Fair, a test that reproduces the failure is the stronger version and the trailer is the cheap fallback for rules that can't be tested. If a rule can be pinned by a regression test or a structural check (a lint, a type that makes the bad state unrepresentable), the trailer should just name that test and the date becomes noise. The rules I'd still keep a dated incident note for are the behavioral ones, where there's no test to point at, and there the date at least tells you whether the underlying cause could have been patched out since. Pruning a rule whose test still fails without it is easy, pruning one with no test is where the guessing starts.

Search Hashnode

Good Agentic Workflows Are Born From Pain, Not Principles

Responses8