HN user

ekusiadadus

71 karma

Creating Bookmark App Designer, Tokyo

Frontend with TypeScript, React Backend with Go, Rust, Flutter, Python Mobile App with Flutter Blockchain with Rust, C++ OS with Rust Languager with .NET Game AI with Python

Posts14
Comments50
View on HN

I've been working on multi-agent path finding (MAPF) for warehouse robotics, so when Amazon published the DeepFleet paper (arXiv, Aug 2025), I spent considerable time dissecting it.

Four things I found most interesting:

1. The 97M-parameter Robot-Centric model beat the 840M and 900M alternatives. Local interaction propagation matters more than global context — a finding that aligns with what we see in classical MAPF (PIBT, LaCAM).

2. Image-based representations catastrophically failed (186% congestion delay error). You cannot represent a robot as a single pixel and expect to capture fleet interactions.

3. The 13M-parameter Graph-Floor model was surprisingly competitive. This suggests the warehouse's graph topology itself is the binding constraint on coordination quality.

4. The scaling laws section experimentally confirms power-law behavior over two orders of magnitude — giving substance to the "improves over time" claim.

I also tried to translate the technical findings into economic terms using Little's Law: a 10% travel time reduction in a 1,000-robot warehouse is equivalent to ~100 fewer robots ($1.3M/year).

I build Rovnou (https://rovnou.com), which does MAPF-based fleet coordination for non-Amazon warehouses. The DeepFleet paper validates many design choices we've made (event-driven, local context, graph-first), while also showing where foundation models may eventually surpass classical solvers.

Happy to discuss the architecture tradeoffs, MAPF vs. learned approaches, or practical deployment challenges.

  Great question! The current implementation is relatively straightforward:

  Layout: The diagram generation uses fixed coordinate positioning (x, y values) calculated heuristically based on node indices and predefined
  spacing. For example, flowcharts use a simple vertical layout with consistent spacing. There's no automatic layout engine - it's manual
  coordinate calculation.

  Arrow routing: Currently uses simple direct connections between source and target nodes. draw.io handles the actual path rendering, but we don't
   leverage draw.io's advanced edge routing algorithms (orthogonal routing, etc.) - arrows just connect the specified entry/exit points.

  CJK text sizing: This is actually an area that could use improvement. The current implementation doesn't dynamically calculate text width for
  CJK characters. Node widths are set to fixed values (e.g., 120px for flowchart nodes), which works reasonably for short labels but may clip
  longer CJK text. draw.io does handle CJK rendering internally, but we're not pre-measuring text to adjust geometry.

  So to directly answer: it's mostly heuristic-based with fixed layouts, not leveraging draw.io's internal layout rules. The .drawio XML format
  gives us the geometry, and draw.io renders it. Future improvements could include:
  - Auto-layout algorithms (dagre.js style)
  - Text measurement for proper sizing
  - Smarter edge routing

  Thanks for the interest!
  Location: Tokyo/Japan
  Remote: Yes
  Willing to relocate: Depending on the case
  Technologies: Rust, TypeScript, AWS
  Résumé/CV: https://github.com/ekusiadadus
  Email: ekusiadadus@gmail.com
I founded my company in Japan 3 years ago and sold it. I'm seeking for a new opportunities. (When it comes to an exciting challenge, I'd love to hear)

I think it’s precisely because of the free sharing that we’ve been able to build such a huge market. The fact that so many engineers enjoy relatively higher salaries and strong demand compared to other professions is thanks to open-source contributions and knowledge sharing being offered for free.

Spacing Over Cards 11 months ago

I think modern websites tend to be especially overloaded with cards. Maybe tools like Claude Code just really love cards. That said, I don’t believe card-free design is always better either. For example, subscription pricing pages often use cards effectively — they make the options much clearer.

Ah, my mistake — Bic Camera didn’t acquire Seibu’s site. Seibu Ikebukuro was actually sold to Fortress, and then the property was transferred to Yodobashi Holdings, which is now planning the redevelopment. Bic Camera started in Ikebukuro, so it’s influential locally, but it wasn’t part of the acquisition.

Sources:

Wikipedia – Sogo & Seibu: https://en.wikipedia.org/wiki/Sogo_%26_Seibu SBbit – Seibu Ikebukuro redevelopment: https://www.sbbit.jp/article/cont1/144891

Really interesting work! I have two questions:

1.LLM-Ex

We call this LLM-Ex.

Could you share more about the internal structure of LLM-Ex? Is it something like a fixed XML-style representation, or more of a free-form structure?

2.realized you don't need huge models to get reliable results

You wrote that > by applying these two principles religiously, we realized you don’t need huge models to get reliable results.

Intuitively, it feels like these principles alone wouldn’t completely remove the need for larger models. Could you explain how you arrived at this conclusion, and what kind of validation or experience led you there?

VIM Master 11 months ago

The fact that Vim has been debated for decades is proof that it’s one of the greatest pieces of software.

It’s not only MIT students—poetry is being read and written at many schools. The claim that this is a > "symbolic event for thinking about the meaning of human expression in the age of AI” feels a bit exaggerated.

Did the author actually compare MIT with other universities?

How are you actually running this in practice with Claude Code? Do you just tell Claude to always read and follow AGENTS.md, or do you also use an MCP server to strictly control which commands (like pnpm test or pnpm lint) it can run? I’d love to hear what workflows or best practices have worked well for you in day-to-day use.

If you aren’t familiar with Rust syntax, |argument| result is an anonymous function equivalent to function myfunction(argument) { return result; }.

Here, your program is constructed left to right. The first time you type line is the declaration of the variable. As soon as you type line., your editor is able to suggest available methods.

Yeah, having LSP autocomplete here does feel nice.

But it also makes the code harder to scan than Python. Quick readability at a glance seems like the bigger win than just better autocomplete.