DEV Community: Agdal

AI, Financial Market Analysis, and the Search for an Edge

Agdal — Sat, 19 Sep 2026 00:21:06 +0000

AI tools for financial market analysis are appearing almost every day. Chart analysis, sentiment tracking, news processing, macro data, technical indicators — things that once required specialized teams and expensive infrastructure can now be put together by a single developer using a few APIs, a database, and one of the many AI models available today.

And that keeps bringing me back to one question:

If everyone eventually has access to AI that can analyze markets, where does the actual edge come from?

I have a personal reason for thinking about this.

As a developer, I have experimented with systems like this myself. I built a few tools that collected market data, calculated traditional technical indicators, pulled data from different APIs, added market sentiment and news, and then passed all of that through AI for additional analysis.

Mostly out of curiosity.

But if you are a developer, you probably know the feeling. Somewhere in the back of your mind there is always that tiny bit of hope that if you combine enough data, enough APIs and enough AI, you might accidentally build your own version of Aladdin.

Spoiler: I did not. Not even close. 😄

Some of those systems produced surprisingly convincing analysis. Sometimes they even got the direction right. But none of them were consistent enough for me to seriously trust them with real money.

And I think this distinction matters.

The problem back then was not that too many people were already using AI and destroying the edge. The problem was much simpler: extracting a stable, reliable signal from financial markets is extremely difficult in the first place.

You can combine RSI, MACD, volume, volatility, sentiment, news, social data and half a dozen external feeds. An AI model can then give you an extremely intelligent explanation for why an asset should move in a certain direction.

The market still has no obligation to agree.

That was the first problem.

Today, however, I think we are slowly creating a second one.

Suppose AI models become significantly better at finding useful market patterns over the next few years. What happens when that pattern is no longer discovered by one fund or one trader, but by thousands of systems at roughly the same time?

They do not need to produce identical answers. But if they use similar data, similar models and similar signals, their behavior can become correlated enough to matter.

If one system finds a profitable setup, another system will eventually try to enter earlier. A third will try to anticipate both of them. Information gets priced in faster and faster until the original signal loses much of its value.

At that point, prediction starts to consume its own advantage.

The Bank for International Settlements (BIS), often described as the “bank for central banks”, has discussed this risk in its work on AI and financial stability. In Artificial intelligence and central banks: monetary and financial stability implications, BIS points to risks such as similar algorithms, synchronized behavior, herding and feedback loops during periods of market stress.

And there is another side to this.

If enough systems respond to the same signal in the same direction, they are no longer just predicting the market. Their actions can become part of what moves it.

Buying pushes the price higher. The higher price triggers momentum strategies. Those strategies generate more buying. Short positions start closing. Leverage and liquidations amplify the move.

The same mechanism can work in reverse.

This is why AI could make markets both more efficient and more volatile at the same time.

The International Monetary Fund has made a similar point: AI can help markets incorporate new information into prices faster, while also increasing the speed and intensity of market reactions if many systems respond to the same information in similar ways.

That sounds contradictory at first, but it really is not.

A market can become better at processing information while also becoming more fragile when everyone reacts at once.

And this is where Aladdin becomes an interesting comparison.

BlackRock's Aladdin is often mentioned whenever people talk about technology and investing, but it is important to understand what it actually is.

It is not some giant AI sitting in New York generating BUY and SELL signals all day.

It is a large institutional platform that combines portfolio management, risk analytics, trading, data and operational workflows. Through Aladdin Studio, institutions can also integrate their own data, models and applications through APIs and development tools.

That illustrates an important point.

AI has democratized access to analysis.

It has not democratized the entire financial infrastructure.

I can build a useful system using market APIs, sentiment feeds and a modern AI model. A large financial institution can use AI on top of proprietary data, risk systems, better execution, deeper liquidity information, more capital and infrastructure built over decades.

We may have access to the same type of technology.

We do not have the same informational position.

That is why I do not think the future of AI in markets will simply be a race to answer:

“Where is the price going next?”

A much more interesting question may become:

“What will other models conclude when they see the same thing I see, and how will they react?”

At that point, you are no longer only trying to predict the market.

You are trying to predict the other predictors.

The most sophisticated systems will probably care increasingly about positioning, liquidity, crowding, forced liquidations, market structure and the behavior of other algorithms.

BIS has even discussed the possibility of AI trading strategies attempting to exploit weaknesses in the strategies of other algorithms.

That changes the nature of the game.

I no longer look at my earlier experiments as proof that “AI cannot predict markets.”

Future systems may become dramatically better than anything I built.

They probably will.

But even if we solve the first problem — finding genuinely useful signals — there is still the second one:

How long does a signal remain an edge once everyone can find it?

That, to me, is the real paradox.

AI may become much better at understanding financial markets without making trading any easier for the average person.

The faster information is discovered, the faster it gets reflected in price.

And the more people use the same tools, the less valuable simply owning those tools becomes.

In the future, the advantage may not be:

“I have AI.”

Everyone will.

The advantage will be in what your AI knows that others do not, what data it has access to, how well you manage risk, and how well you understand what everyone else is likely to do with the same information.

What changed when I stopped using SOL for everything in Codex

Agdal — Tue, 15 Sep 2026 19:27:31 +0000

I’ve been developing web sites and applications for years, and lately Codex has become a pretty big part of how I work.

At first my workflow was simple. Open the project, use SOL, explain what I want, let it inspect the code, implement the feature, run the tests, fix whatever breaks, and continue.

It worked.

The problem was that after a while I started noticing how much of SOL’s time was being spent on work that didn’t really require SOL.

A difficult architectural decision? Sure.

Trying to understand why a bug exists across several parts of the application? Absolutely.

But once a task was already understood and the important decisions had been made, a lot of the remaining work was fairly mechanical implementation.

Controllers. Validation. Services. Views. Tests. CSS. Small refactors.

Luna Max was perfectly capable of doing a lot of that work.

So I started changing the way I used the models.

Instead of asking SOL to think about the problem and then also spend the rest of the session implementing everything, I started asking SOL to prepare the work for Luna.

That sounds like a very small change.

It ended up changing most of my Codex workflow.

The real problem wasn’t code generation

One thing I quickly discovered was that telling SOL to “make a plan” wasn’t enough.

Codex can produce plans that look perfectly reasonable while you’re reading them.

Then another model actually tries to implement the plan and you realize how much information is missing.

“Add validation.”

“Update the controller.”

“Add tests.”

“Handle errors.”

Technically those are steps.

They just aren’t necessarily useful instructions.

On a real application, the important questions are usually somewhere underneath those sentences.

Which existing service owns this behavior?

Which business rules must remain unchanged?

What happens when the input is invalid?

Which existing tests represent behavior we are not allowed to break?

Does this require a new migration, or can the existing model support it?

What should the implementation model do if the repository does not look the way the plan expected?

Those are the decisions that matter.

So the workflow gradually became less about asking SOL for a generic plan and more about getting SOL to understand the actual project first.

On an existing project, that means inspecting the real repository, relevant code, tests, routes, schema and current architecture before planning anything.

On a new project, there obviously isn’t a repository to inspect yet, so the process starts earlier: discovery, requirements, specification and architecture.

Only after that does implementation planning make much sense.

SOL plans. Luna implements.

Eventually I ended up with a fairly simple division of responsibilities.

SOL handles the work where stronger reasoning is useful.

Luna handles as much of the actual implementation as possible once that reasoning has already been done.

The important part is that the plan shouldn’t become the implementation written in English.

I ran into that problem too.

If SOL writes an enormous plan containing almost every line Luna should eventually type, I haven’t really delegated much. SOL has already solved and practically implemented the feature, just in another format.

So I now try to keep a boundary between planning and implementation.

SOL should answer things like what needs to change, where it belongs, why it belongs there, what decisions are already locked, what constraints must be preserved, what failure cases matter and how we will verify that the result works.

Luna still has to write the actual code.

That distinction turned out to matter more than I expected.

The moment where AI agents usually make me nervous

There is another behavior I kept seeing on longer projects.

The implementation model receives a good plan, starts working through it, and eventually discovers something unexpected.

Maybe the existing architecture is slightly different.

Maybe a method mentioned in the plan doesn’t exist.

Maybe an earlier implementation decision changed the shape of the module.

At that point an AI coding agent has two choices.

It can stop and tell you that reality no longer matches the assumptions.

Or it can decide that it understands the intent well enough and redesign part of the solution itself.

The second option is where things can get ugly.

A seemingly reasonable local fix can quietly turn into a new architectural decision, followed by another decision required by that decision, and suddenly the agent is modifying parts of the application that were never part of the original task.

So one of the rules I started using is extremely simple:

If the plan materially conflicts with the real project, stop.

Don’t invent a new architecture just to keep moving.

Report what the plan assumed, what actually exists and what decision is now required.

Then the problem can go back to SOL if it genuinely requires stronger reasoning.

This slows down one individual step.

It has saved me a lot of time cleaning up “helpful” improvisation afterward.

I also stopped treating project context like chat history

Another thing that became annoying on longer projects was repeating myself.

What phase are we in?

What did we decide about this module?

Which plan is active?

What is Luna currently allowed to change?

Did we already approve this architecture?

Why did we decide not to use that dependency?

Which model should work next?

Chat history is a terrible place to keep all of that.

Sessions change. Context gets summarized. You start a new conversation. A model reads the code but doesn’t know why certain decisions were made.

I wanted the project itself to carry enough information for the next Codex session to understand where it was.

So I started keeping the workflow state inside the repository.

Not a giant journal of everything the AI ever did.

That would become useless almost immediately.

The state file only needs to answer where the project is now.

If Luna spends three hours implementing the same active plan and nothing meaningful changes, the state does not need to be updated every five minutes.

It changes when something meaningful happens: a handoff, a blocker, a STOP checkpoint, a review result, a takeover, acceptance of a task, moving to the next module.

The implementation details belong in the active plan and the code.

The state is just the navigator.

This eventually became TITAN

After using variations of this workflow for a while, I realized I was recreating the same structure on different projects.

So I put it into a repository and called it TITAN - Technical Intelligence, Tasking & AI Navigation.

The name sounds much more dramatic than what is actually inside it.

There is no runtime, no AI proxy and no orchestration server.

It is mostly Markdown.

Roles, workflow rules, project state, planning prompts, handoff rules and templates live inside the repository where Codex can read them.

That was intentional.

I didn’t want another black box between me and the model.

If a rule is stupid, I want to be able to open the file, read it and change it.

The normal flow is roughly SOL doing discovery and architecture when needed, SOL preparing the current implementation task, Luna implementing it, tests verifying the result, and then either continuing, reviewing or stopping when something requires a decision.

SOL can still take over implementation when Luna gets stuck on something that genuinely requires continuous high-level reasoning.

The point isn’t to artificially force every line of code through Luna.

The point is to stop paying for stronger reasoning when the task no longer needs stronger reasoning.

Is this just vibe coding with more paperwork?

Maybe that is the obvious question.

I don’t really think so, although the definition of “vibe coding” seems to change depending on who is using the term.

I’m not particularly interested in having an agent generate an application while I avoid understanding what it is doing.

The whole reason I ended up with this workflow is because longer AI-assisted projects became harder to control once architecture, business rules, state and multiple implementation sessions started interacting.

I still own the decisions.

I still review what gets built.

Tests still matter.

Production verification still matters.

And when the model says something that doesn’t make sense, the fact that it came from a stronger model doesn’t make it correct.

For me, AI-assisted development became much more useful when I stopped treating the model as one very fast developer that should do everything and started treating different stages of the work differently.

Has it actually saved anything?

In my own work, yes.

Before this I was using SOL for almost entire projects.

Once I started moving well-defined implementation work to Luna Max, my SOL usage dropped noticeably.

I also spend less of my own time repeatedly explaining project state, architecture and model handoffs.

What I do not have is a controlled benchmark.

I haven’t taken the same set of projects and scientifically compared SOL-only against SOL-to-Luna while measuring every token, cache effect, iteration and failure.

So I’m not going to claim that TITAN reduces token usage by some percentage.

It may not even reduce the raw number of tokens in every situation.

A planning pass itself costs tokens, and changing models has its own tradeoffs.

What I care about more is how much work actually needs to be done by the stronger reasoning model.

If SOL spends one good reasoning pass preparing a task and Luna can then handle a long edit-test-fix-test implementation loop, that has been worthwhile for me.

For a tiny change, it probably isn’t.

I wouldn’t use this process to change the text on a button.

What I want to find out now

TITAN works well enough for the way I use Codex that I decided to make it open source.

That doesn’t mean I think the methodology is finished.

Actually, the interesting part now is seeing where it fails for people who didn’t design it.

A few of the best changes already came from other developers questioning assumptions in the workflow.

One person pointed out that a planning model could “verify” an extremely detailed plan by temporarily implementing the feature, running the tests and reverting everything before handing the plan to Luna.

That is technically thorough.

It is also a spectacular waste of the handoff.

That feedback led to a new rule: SOL planning and review are application-code-read-only. If SOL genuinely needs to take over debugging or implementation, the workflow explicitly transitions into that role first.

That kind of feedback is much more useful to me than someone telling me the repository looks nice.

If anyone here uses Codex on projects that have grown beyond the toy-project stage, I’d be interested in seeing what happens when TITAN hits a codebase and workflow I had nothing to do with.

Especially if it gets annoying.

That is probably where the next useful rule is hiding.

The project is MIT licensed and available on GitHub:

https://github.com/netelite/titan

You can also initialize it directly inside a project folder with:

npx -y @netelite/titan@latest

That only adds the TITAN methodology files to the project. It does not replace your application code or add a framework dependency.

For a new project, open it in Codex with SOL and start with something as simple as:

Start this project using the TITAN methodology.

Idea: <your idea>

For an existing project, SOL starts by understanding what is already there before planning changes.

If you try it, I’m much more interested in hearing where the workflow gets in your way than whether you agree with every rule.

Disclosure: I used AI assistance while drafting and editing this article and to help translate this article into English and to improve grammar and clarity. The workflow, project experience, opinions and TITAN methodology described here are my own, and I reviewed the final text before publication.