MetaEditor, Open AI and ChatGPT - page 11
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Extremely doubt the above.
Creating ToR for AI without understanding what the AI has returned to you is a way to nowhere.
The same question, what should be the size of promt, that the AI would generate a medium-sized project.
Well, you have written a promt task for 100500 pages, the AI has given you the code, there are errors, what next?
The example above describes Shovels and Excavators.
Working as a master shovel you will make the hole that you need size, accuracy of edges, depth, and at the first time and without damaging communications.
Working with an excavator will not achieve this.
In general, this comparison in my opinion is not the most successful.....
AI is good at analysing data, but I don't think it will be able to create something, especially from programming, any time soon.
In any case, when the code created by AI brings 100500 losses, the customer will cross himself 100500 times and hire a person capable of fixing the errors.
And as practice shows, picking someone else's code, especially AI, is much more expensive than writing code from scratch.
There have always been amateur and professional programmers, so AI is a light amateur. When you need something working and reliable, it is the way only to the pros....
My point is not that pros are no longer needed - they are needed, and they are needed even more than before. But it's the other pros: the ones who understand the whole system, who test the AI, who see where it's hallucinating, who are able to take control when the model goes haywire. Those who remain "just a coder" with a shovel are at risk not because they are bad experts, but because an excavator has arrived nearby that digs 80% of typical holes cheaper and faster.
And perhaps this is our only real difference: you see AI as a tool stuck at the current level, while I just extrapolate the events that have happened over the last 2-3 years into the future. And this trajectory has clearly exponential growth.
But I think your position is relevant for a while yet - the window for such a view is closing pretty quickly.
We stopped releasing betas as we are implementing a Codex-like orchestrator to work on projects in Metaeditor.
We would also like to add a good vector database to it, so that functions and user classes could be catalogued and the solution could be searched for in the beginning through ready-made code. For this purpose we need to make smart chunking that would fit a logically complete piece of code into one chunk.
Also for local models it makes sense to split a query into several and give it for parallel calculation, it allows not to blow up the context window and get the overall result faster. If there will be smart splitting of queries (splitting into subtasks), it is possible to support several servers and GPUs on them.
With such functionality, it will be a boost in comparison to other solutions.
It will be possible to connect any LLMs
Think about some kind of internal AI subscription from the MQL account. A lot of people have a problem with this, as well as with withdrawal. There are two birds with one stone.
Let's see what we get!
I would also like to add a good vector database to it, so that functions and user classes could be catalogued and the solution could be searched for in the beginning through the ready-made code. For this purpose we need to make smart chunking that would fit a logically complete piece of code into one chunk.
Also for local models it makes sense to split a query into several and give it for parallel calculation, it allows not to blow up the context window and get the overall result faster. If there will be smart splitting of queries (splitting into subtasks), it is possible to support several servers and GPUs on them.
With such functionality it will be already a boost in relation to other solutions.
This is what the orchestrator is doing, and it will be assisted by mcp servers, both built-in and third-party.
Most likely we will open mcp servers for www.mql5.com and www.metatrader.com to extend the functionality of orchestrators. Our orchestrator will also be included in the terminal itself, which will allow traders to analyse the market and their transaction history right in the terminal.
Consider some sort of internal AI subscription from an MQL account. Many people have a problem with it, as well as with withdrawal. There are two birds with one stone.
You can use pretty much any LLM engine, including the fairly cheap Deepseek or your own instances on ops models.
All the power is in the orchestrator, which does deep tasking by repeatedly working with a particular LLM provider.
We don't even want to do paid public aggregators of api services, as this directly violates the terms of third party service licences and inevitably leads to account lockouts. This happens everywhere and constantly.
There are a huge number of semi-legal aggregators of this kind on the market.
How does MQ use AI to write its programmes now?
Only third-party auxiliary tools
For main projects only analysing and finding bugs. Orchestrator-analysers are written for that.
Third-party auxiliary tules only.
For main projects only analyses and bug finding. Orchestrator-analysers are written for this purpose.
Thank you. It turns out that 100% of the code written in MQ is human. And that's a company policy.