I don't know any bad stories about ai-translated apps. Partially because it's a relatively new trend, but also because a big amount of usual vibe code fail modes are not applicable here.

This will be the next step, and it will be nasty: changing our workflows to "agent-friendly" even if they less convenient for humans. And then - yes, partial replacement.

It was impossible to fix, but it required some experiments and deep research about very specific behaviors.

Or this ticket: https://code.djangoproject.com/ticket/35289

Author proposed one-line solution, but the following discussion includes analysis of RFC, potential negative outcomes, different ways to fix it.

And without deep understanding of the project - it's not clear how to fix it properly, without damage to backward compatibility and neighbor functionality.

Also such a fix must be properly tested manually, because even well designed autotests are not 100% match the actual flow.

You can explore other open and closed issues and corresponding discussions. And this is the complexity level of real software, not pet projects or simple apps.

I guess that existing attention mechanism is the fundamental blocker, because it barely able to process all the context required for a fix.

And feature requests a much, much more complex.

Automated tests partially solve the case, but in real world no one writes tests blindly. It's always manual work, and when the failing trajectory is clear - the test is written.

Theoretically agent can interact with UI or API. But it requires deep project understanding, gathered from code, documentation, git history, tickets, slack. And obtaining this context, building an easily accessible knowledge base and puring only necessary parts into the agent context - is still a not solved task.

Testing a fix in a big application is a very complex task. First of all, you have to reproduce the issue, to verify steps (or create them, because many issues don't contain clear description). Then you should switch to the fixed version and make sure that the issue doesn't exists. Finally, you should apply little exploratory testing to make sure that the fix doesn't corrupted neighbour logic (deep application knowledge required to perform it).

To perform these steps you have to deploy staging with the original/fixed versions or run everything locally and do pre-setup (create users, entities, etc. to achieve the corrupted state).

This is very challenging area for the current agents. Now they just can't do these steps - their mental models just not ready for a such level of integration into the app and infra. And creation of 3/5/10/100 unverified pull requests just slow down software development process.

Comments URL: https://news.ycombinator.com/item?id=41741538

Points: 1

# Comments: 0

Am I right, that the following 2 services solve the same product in a similar way: https://github.com/logspace-ai/langflow , https://github.com/FlowiseAI/Flowise ?

It's absolutely ok if the answer is "Yes", I think that in this hot market each product will find a place. And competition is also motivate :)

It would be also nice to add Rivet here: https://github.com/kyrolabs/awesome-langchain#low-code

It has a layer selector with temperature, wind, pressure and precipitation.