Welcome Thread - v374

hi🤗

Agreed - thank you for whoever put together the guide - likely a multi-indiviual effort.
Hi Everybody...

Hi! Great to connect 👋

Hello! Great to meet you here. What are you currently working on or learning? Always exciting to connect with fellow devs!

hi

:)

Hi Antonia

I appreciate you taking the time to welcoming people to DEV, just like @konark_13! Makes it much more welcoming :)

I think there's a joke from The Office that fits here quite well.

Thanks! check it out on GitHub : )

There are challenges. I'm optimizing the backend communication with multiple devices and it's complicated.

Hello 👋

Cheers, feel free to check it out on GitHub

Hey! Yeah, memory-hard KDFs are definitely a pain on mobile.

For my password manager I ended up prioritizing security over UX, so I went with two coarse-grained modes:

Standard: 128MB, 3 iterations
Hardened: 256MB, 4 iterations

My thinking is that users who really value security and privacy will be okay with waiting a bit longer. Especially since the KDF only runs once per session in my case (login).

Thanks Francis!

It's called MonetScope — a pipeline that reads Reddit / HN / X and surfaces what people complain about as scored
startup opportunities. Been the most fun / most humbling build I've done in a while.

Actually writing up the engineering side right now — the five things that turned out harder than the LLM itself.
Dropping here once it's live if you're curious. What are you building these days?

Update as promised — just posted the writeup: dev.to/benjiandai/i-shipped-an-ai-...

The five things that turned out harder than the LLM itself when building
the scraper-to-scored-opportunity pipeline. §3 (the grounding pattern)
and §5 (the cross-language serialization bug) are the two I think
generalize best. Would love your read.

Good day Francis

Think of it less like building an “app” and more like building a living system.

In a typical project, you have one codebase doing everything — frontend, backend, logic, data — all tightly coupled. It works, but it’s static. If one part changes, everything feels it.

What I do instead is structure projects like an ecosystem, where each part behaves more like an independent organism.

For example in my MindsEye ecosystem:

There’s an orchestrator layer (like a brain) that coordinates everything
Multiple agents/services handle specific roles (data collection, reasoning, logging, simulation, etc.)
A shared memory layer (logs, ledgers, state stores) acts like the environment they all live in
Each component can evolve, break, or be replaced without collapsing the whole system

So instead of:

“How do I build this feature?”

I think:

“What kind of entity should exist in this system, and how should it interact with others?”

The key shift is:

Apps = fixed structure, predefined flows
Ecosystems = dynamic interactions, emergent behavior

For example, in one setup:

A data agent observes inputs
A reasoning agent interprets them
A logging agent records state changes
Another agent can later “learn” from that history

None of them need to know everything — they just communicate through structured outputs (often prompts, events, or state updates).

It does make things more complex 😄
But the upside is you start getting systems that can:

adapt without full rewrites
scale organically
and sometimes surprise you with behaviors you didn’t explicitly code

I basically treat software like digital ecology instead of architecture.
Alright, here’s a clean, dev-focused version you can post as a continuation:

If I had to break down one concrete part of my setup, I’d point to the MindsEye Orchestrator. That’s essentially the control layer of the ecosystem.

At a practical level, the orchestrator is not doing the work itself. It’s responsible for deciding what should happen, which component should handle it, and how everything stays coordinated.

What it actually is

In simple terms, the orchestrator is made up of:

• an input handler (event listener or loop)
• a router/dispatcher
• a decision layer
• a connection to shared memory

It’s closer to a control system than a traditional backend service.

Core flow

1. Input enters the system

This could be user input, sensor data, or output from another agent. Everything gets normalized into a structured event.

Example:

{
  "type": "observation",
  "source": "plant_sensor",
  "data": {
    "moisture": 32,
    "light": 78
  }
}

1. Context is pulled from memory

The orchestrator checks the current system state:

• past events
• logs
• active processes

This step answers questions like:

• Has this already been handled?
• Is there existing context that matters?

1. Decision routing

Instead of hardcoding logic directly, the orchestrator selects which agent should handle the event.

Traditional approach:

if moisture < 40:
    water_plant()

Ecosystem approach:

agent = select_agent_based_on_context(input, memory)
dispatch(agent, input)

This makes the system modular and adaptable.

1. Agent execution

The orchestrator assigns a task to a specific agent:

{
  "agent": "reasoning_agent",
  "task": "analyze_plant_state",
  "input_ref": "event_1023"
}

Each agent focuses on a narrow responsibility and returns structured output.

1. Results are written back to memory

Outputs are stored as part of the system state:

{
  "type": "analysis",
  "result": "low moisture detected",
  "confidence": 0.92
}

This becomes new context for future decisions.

1. Chain reactions (feedback loop)

Outputs can trigger other agents. The system becomes a loop rather than a straight pipeline:

event → agent → memory → agent → action → memory → next step

This is where the system starts behaving less like a program and more like an environment.

Key components inside the orchestrator

• Event Queue / Input Handler
  Standardizes incoming data into a consistent format.

• Router / Dispatcher
  Determines which agent should process each event.

• Agent Registry
  A simple mapping of available agents:
  

  agents = {
      "reasoning": ReasoningAgent(),
      "logging": LoggingAgent(),
      "simulation": SimulationAgent()
  }

• Memory Connector
  Interfaces with storage systems (logs, ledgers, databases, vector stores).

• Feedback Loop Engine
  Allows outputs to re-enter the system as new inputs.

How this differs from a typical app

Traditional backend flow:

request → controller → service → response

Ecosystem-oriented flow:

event → context → agent → memory → agent → evolution

One is linear. The other is iterative and state-driven.

Concrete example (plant system)

• Sensor reports moisture = 32
• Orchestrator logs the event
• Reasoning agent identifies low moisture
• Decision agent determines watering is needed
• Action agent triggers irrigation
• Logging agent records the outcome
• Simulation agent updates the digital model

Each component operates independently but contributes to the same system.

Core idea

Instead of building a system that directly performs tasks, the goal is to build a structure where components interact, and outcomes emerge from those interactions.

That’s what I mean by treating projects like ecosystems rather than standalone applications.

Thank you Francis (⁠ ⁠◜⁠‿⁠◝⁠ ⁠)⁠♡

Hey Julien, thanks! 🙌

Basically any action a user takes in your product: user.login, invoice.deleted, document.shared, settings.updated, whatever matters to you. You fire an event from your backend (SDK or REST, 3 lines), Recalled stores it signed + searchable, and you get a dashboard to answer "who did what, when, from where" without touching your prod DB.

The idea came from re-coding the same activity_logs table in every SaaS I built. Figured it shouldn't be my problem anymore.