Thinking

What we figured out, written down.

Methodology / Case study / Technical perspective
01··Technical Perspective

Why We Don't Blindly Use Dify / LangChain

Tools are means, not ends. When facing a concrete problem, we first ask: does this framework's abstraction level match our scenario? Will its assumptions become future constraints?

Read Full Article→
02··Case Study

Non-Intrusive Securities Mid-Office Transformation: Three AI Scenarios

Financial system overhauls fear the 'rip and replace' approach. We layered three AI scenarios non-intrusively on top of existing infrastructure — each with different entry points and trade-offs.

Read Full Article→
03··Methodology

5 Questions We Ask Before Taking an AI Project

Not every problem is worth solving with AI. We built a screening framework — 5 questions asked before project kickoff to decide whether this is a fit.

Read Full Article→
04··Series · 5 parts

EasyZ FDE Methodology

An FDE isn't someone who ships code and leaves — they turn 'unclear requirements' into 'verifiable results.' This series distills our hard-won lessons into five parts: aligning with the client, surviving, driving projects, governing docs and code, and keeping AI inside its boundaries.

  1. 01The First Hurdle for FDE: Aligning with the Client→
  2. 02How an FDE Survives: Earn Trust First, Then Absorb the Chaos→
  3. 03How FDEs Drive Projects: Turning Vague Requirements into Verifiable Results→
  4. 04How FDEs Govern Docs and Code: Making AI Actually Useful→
  5. 05How FDEs Work with AI: Keeping AI Inside Its Boundaries in Complex Business→
8 essays · 1 series