I didn't say to skip any kind of problem modeling. I just didn't emphasize it.

The goal _should_ be to avoid doing traditional software engineering or create a system that requires typical engineering to maintain.

Agents with leading edge LLMs allow smart users to have flexible systems that they can evolve by modifying instructions and tools. This requires less technical skill than visual programming.

If you are only taking advantage of the LLM to handle a few wrinkles or a little bit of natural language mapping then you aren't really taking advantage of what they can do.

Of course you can build systems with rigid workflows and sprinkling of LLM integration, but for most use cases it's probably not the right default mindset for mid-2025.

Like I said, I was originally following that approach a little ways back. But things change. Your viewpoint is about a year out of date.

▲

bonzini 2 days ago | parent [-]

I understand that. You didn't answer the important point, which is that you can't be sure that what you have works if you don't encode the process. And encoding the processes isn't really software engineering; abstractions for business rules management have existed for decades and can be reused in this context.

You're YOLOing it, and okay that may be fine but may also be a colossal mistake, especially if you remove or never had a human in the loop.

▲

ilaksh 2 days ago | parent [-]

What I suggested was to use an actual agent. I also did not say there was no human in the loop.

The process is encoded in natural language and tool options.

I'm not YOLOing anything.

	▲	bonzini a day ago \| parent [-]
		If there is a human in the loop, TFA does say that agents can be the solution. In fact that's pretty much the conclusion that the author makes. By saying "you should just use agents", anyone who has read the article will assume that you're talking about the case where there's no human in the loop.