惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

C
Check Point Blog
美团技术团队
Jina AI
Jina AI
人人都是产品经理
人人都是产品经理
The Cloudflare Blog
V
Visual Studio Blog
Google DeepMind News
Google DeepMind News
Hugging Face - Blog
Hugging Face - Blog
云风的 BLOG
云风的 BLOG
有赞技术团队
有赞技术团队
T
The Blog of Author Tim Ferriss
WordPress大学
WordPress大学
月光博客
月光博客
宝玉的分享
宝玉的分享
小众软件
小众软件
MongoDB | Blog
MongoDB | Blog
Apple Machine Learning Research
Apple Machine Learning Research
A
About on SuperTechFans
J
Java Code Geeks
博客园_首页
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
N
Netflix TechBlog - Medium
Vercel News
Vercel News
博客园 - 聂微东

Show HN

Show HN: AI agents for UK GDAD PCF roles and their skills The Two Pillars: Mixer Mode and Meta-Software in the Reorganization of Software Work After AI GitHub - JaiCode08/teleport-env What 1,000+ Harness Experiments Taught Me About Self-Improving Agents Show HN: Liiists, a Markdown-first, iOS and CLI list app SwiperTab – Get this Extension for 🦊 Firefox (en-US) GitHub - kouhxp/fftext: Summarize, explain, fact-check, or translate any text, URL, or file. No GPU. No cloud. One command GitHub - sweetpad-dev/sweetpad: Develop Swift/iOS projects using VSCode GitHub - dogmaticdev/IRON: IRON a.k.a. Intermediate Representation Object Notation is a Interpreter/Database that is used to create Programming Languages. GitHub - sjhalani7/vaen: Package your AI coding harness into a portable .agent file, and share it across repos, teams, & the community without ever having to copy-paste instructions, skills, MCP config, or secrets. Show HN: Gandalf the Grader Show HN: Citadeld – replay any CI failure locally from a single file GitHub - tdortman/cuSBF: High-Performance GPU Super Bloom Filter coral-ai/claude-code-token-xray at main · Coral-Bricks-AI/coral-ai GitHub - ulyssestenn/funes: Funes is a Git-based framework for LLM-managed knowledge work: an AI Librarian ingests raw sources, builds an interlinked Markdown knowledge base, and uses it to produce cited reports, analyses, and other outputs. GitHub - ThatXliner/gah: Git Add Hunk, built for agents to use GitHub - harmont-dev/harmont-cli: Command-line client for the Harmont CI platform GitHub - brooksmcmillin/mcp-authflow: OAuth 2.0 Authorization Server framework for MCP servers GitHub - javaid-codes/audit-supply-chain-agents GitHub - amorey/gochan: A small library of common channel architectures for Go, inspired by Rust GitHub - arifozgun/OpenGem: Free, Open-Source AI API Gateway with Gemini, OpenAI & Anthropic Compatibility in 1 file GitHub - Pranesh950/BioPetals: 🌸 Run BIOxAI models at home, BitTorrent-style. Fine-tuning and inference up to 10x faster than offloading GitHub - cnguyen14/bounty-doctor: Diagnose a GitHub bounty issue before you waste hours: detects honeypot scam repos, AI-bot attempt swarms, and stale contests. Show HN: CoreMCP – MCP Server for On-Prem DBs Show HN: KittyHTML – Render HTML/CSS as an inline image in your terminal GitHub - bingud/filemat: Web-based file manager Show HN: TruthLens – Free multi-signal deepfake image detector GitHub - apexlocal-jz/claude-usage-tray: Windows system-tray app showing your Claude Code rate-limit usage at a glance. Zero deps, ~300 lines of PowerShell. Cross-IDE (works regardless of VS Code, Cursor, plain terminal). Release v0.1.2.1 · kouhxp/yapsnap GitHub - noopolis/moltnet: Self-hostable chat network for AI agents. Pre-built bridges for Claude Code, Codex, and the Claws. Rooms, DMs, history. No Slack bots, no Matrix, no glue code.
Why code should never read B7 · logisky/LogiSheets · Disc...
logisky · 2026-06-16 · via Show HN

Why code should never read B7

TL;DR

I think humans and software break spreadsheets in different ways because spreadsheets lack structure.

LogiSheets adds typed blocks directly into the grid so users can still model with spreadsheets while software can safely read structured data.

Demo (Factory Simulator):
https://www.logisheets.com/

The spreadsheet backing the simulation can be revealed from the top-right corner.


I've been bothered by the same property of spreadsheets for years: they're at once too flexible for humans and too fragile for software.

A person can overwrite a formula, type "N/A" into a quantity column, or accidentally break a calculation. Nothing stops them. The mistake often isn't discovered until much later, after it has already affected downstream results.

Software has the opposite problem. It reads a value from B7, someone inserts a row above it, and now the program is silently reading the wrong number. Humans think in records and fields. Software ends up reading coordinates.

These look like different failures, but I think they're the same bug.

The spreadsheet grid has no structure.

Every cell can contain anything. Rows and columns don't have stable identities. A value's meaning exists only by convention. Humans are expected to follow the convention, and programs are expected to guess it.

What if spreadsheets had structure?

The traditional answer is to move the data somewhere else.

Databases, Airtable, and similar systems introduce schemas, types, constraints, and stable records. The tradeoff is that the user is no longer working in a spreadsheet.

That solves the software problem, but it often removes the thing spreadsheets are uniquely good at: building live models directly in the grid.

My goal with LogiSheets is different.

Instead of replacing the spreadsheet, I want to add structure directly into it.

Regions of the sheet become typed blocks. Fields have names. Values have types. Rules can constrain what users are allowed to enter. Records have stable identities independent of their physical position in the grid.

The important part is that the same structure serves both humans and software.

A user cannot accidentally enter invalid data into a field.

A program can read:

instead of:

Rows can move. Columns can move. Data can be reorganized for readability. The program still reads the same record.

Delete a row and it becomes a removed record, not silent corruption.

One structure. Both sides stop breaking.

It's still a spreadsheet

I don't want to turn spreadsheets into forms.

Users should still be able to write formulas, build models, run scenarios, and experiment with ideas directly in the grid.

The engineer constrains the shape of the result.

The user keeps the flexibility of a spreadsheet.

The software gets something it can trust.

How far can the model go?

One question I had early on was whether this idea only works for simple business records.

To test it, I built an entire factory simulation on top of the model.

Production chains, inventories, bottlenecks, and planning logic are all represented as structured spreadsheet blocks. Users can edit values, formulas recalculate instantly, and the entire state can be saved into a standard .xlsx file and loaded again later.

That experiment convinced me that the idea stretches much further than data entry forms.

Demo (Factory Simulator):
https://www.logisheets.com/

The spreadsheet backing the simulation can be revealed from the top-right corner.

2026-06-16.14.49.51.mov

How this differs from existing approaches

Excel Tables and Named Ranges

Excel Tables give names to regions of the sheet, which is useful.

But names are not guarantees.

A column can still contain unexpected values, broken formulas, or references that no longer make sense. Validation rules are optional and easy to remove. Software still has to trust that the workbook's structure hasn't drifted.

Airtable and Grist

These systems introduce real structure and constraints.

The tradeoff is that they move data into a database-style model.

LogiSheets attempts to keep the structure inside the spreadsheet itself.

Parsing spreadsheets from code

Libraries such as pandas or spreadsheet parsers can read workbook contents after the fact.

They don't prevent the workbook from drifting away from the assumptions your code makes.

The validation happens after the mistake.

I want the structure to exist before the mistake.

Current status

LogiSheets is implemented with a Rust core compiled to WASM and runs entirely in the browser.

It reads and writes real .xlsx files.

Some parts are working well. Some parts are still rough. There are many things I haven't tested yet.

What I'm most interested in right now is feedback on the idea itself:

Is the lack of structure actually the root cause of the problems people encounter when spreadsheets meet software?

I'd love to hear where this resonates, where it doesn't, and what existing tools you think already solve this problem well.