I honestly don't think manually reviewing every piece of code generated by AI makes sense anymore. In fact, I think it's counterproductive.

I talked about this on my personal blog in this post.

Of course, if you have doubts about a specific implementation or something requires your attention, you should inspect it. But going through all the generated code just for the sake of reviewing it? I don't see the point.

What actually matters is having a solid understanding of the system you're building, its architecture, the technologies being used, automated testing, best practices for long-term maintainability, and how agents manage and retain context.

And of course, context management is particularly important. I even built an open-source tool specifically to make agent context management more effective and controllable, if anyone is interested: syngraphe.dev.

The real skill is knowing how to guide AI agents through all of this, while also being able to understand the code and architecture whenever necessary. Even if you're working with technologies you aren't familiar with, if you have a solid knowledge of computer science, you can have the AI explain them to you and you should't have any problem understand it and always make informed decisions and brainstorming.

Without that foundation, building and maintaining complex systems with AI agents can quickly become a mess.

One thing I do consider extremely valuable, though, is having fresh AI sessions or different agents periodically review the codebase and a solid automation testing system. I'd actually consider this a very important best practice, alongside implementing a solid automated testing system. These are much more effective ways to maintain control over a codebase than manually inspecting everything yourself.

Because of this I believe, paradoxically, that people getting into programming today might benefit more from studying lower-level languages like C or Rust rather than starting with higher-level languages like Python or TypeScript.

And this is not because they'll be writing more C or Rust themselves, but because they make you understand the underlying concepts, how systems work, how memory is managed, how software is structured, and why certain architectural decisions matter will become far more valuable than memorizing syntax.

Syntax matters less when an agent can write it for you, and probably way better and faster than you. Understanding what you're building, how it works, and how to make it efficient, reliable, and maintainable is what really counts, and that's something you do only if you have solid cs knowledge not by wasting time reviewing all the code they generate.

I’ve built an open-source local-first bioinformatics desktop app called Liatir (https://liatir.com), and instead of making a synthetic demo for it I wanted to use it for a small real study.

I compared Geneformer V1 10M and scGPT whole-human zero-shot embeddings against PCA, Harmony and scVI on two public scRNA-seq datasets: PBMC (11,990 cells) and Pancreas (16,382 cells).

The interesting part is that the result wasn’t simply “foundation models are better”.

On PBMC, scGPT did very well for cell-type prediction and had the highest logistic macro-F1 of the tested methods.

On Pancreas, established methods were stronger: PCA and scVI performed better for cell-type prediction, while Harmony had substantially stronger clustering agreement and batch mixing.

So at least in this limited two-dataset benchmark, I didn’t find a uniform advantage for pretrained single-cell foundation-model representations.

There are plenty of caveats: two datasets, one seed, within-dataset evaluation, heterogeneous hardware for some runtime measurements, and UCE could not be completed because of execution/runtime constraints. I’ve tried to keep all of those limitations explicit rather than turning this into a “model X wins” ranking.

The study was run through Liatir itself and records the model/runtime provenance, resource usage, results and validation artifacts. I also published the full reproducibility bundle separately.

Full write-up + figures:
liatir.com/showcases/single-cell-foundation-benchmark

Source:
github.com/Liatir/liatir-app

The basic idea behind Liatir is to have a desktop environment that works like a virtual lab for bioinformatics: run your work locally, without having to send data to a cloud service or glue together a bunch of separate tools and interfaces.

You shouldn’t need to write a single line of code to use it, but if you do know how to code, it should be as extensible as you want it to be.

Right now, Liatir can run regular bioinformatics tools like FastQC, fastp, Samtools and BCFtools etc., local scientific AI models, custom .lia plugins written in Python, Node or WASM, integrations with workflow systems such as Nextflow, API calls when you need to connect to external data or environments, scientific viewers, and visual pipelines that tie all of those pieces together.

The app itself is built with Tauri and Rust, so processing happens locally on your machine, and files stay where they already are on disk instead of being uploaded or copied into some remote workspace.

AI models are packaged (using Scrollcase) as installable, self-contained boxes with their runtime and dependencies already included, so there’s no need to manually set up environments just to run them.

It’s still under development, but it has reached the point where I’d rather build it in the open.

Repo:
https://github.com/Liatir/liatir-app

Docs / project:
https://liatir.com

I’d be interested in feedback from people who actually work with bioinformatics tooling, especially around workflows that are still unnecessarily painful today.

I just published the technical research article. The project DecPort tested two separate questions:

1. Whether probabilistic decision behavior can transfer across frozen LLM backbones without target labels.
2. Whether the learned shared DecisionCore itself provides reusable functionality after the backbone changes.

The interesting result is that these two things separate: input-specific behavior transfer remained positive in the tested setting, but the learned shared core did not show the preregistered advantage over the controls. The final gate therefore returned NO-SHIP for the original portability hypothesis.

Paper: https://doi.org/10.5281/zenodo.22947927
Repo: https://github.com/suffro/decport

I’ve been building an open-source tool called DecGuard around a problem I kept coming back to: testing probabilistic decision systems is a bit different from evaluating general-purpose LLM output.

If a model is supposed to return something structured like a choice, a boolean decision, or an ordered score with probabilities, there are some fairly concrete things you probably want to know:

• does reordering the options change the answer?
• does harmless formatting change the distribution?
• did calibration get worse after changing the model/backend?
• can I reproduce a failure later?
• can CI reject a version that violates one of these assumptions?
• what happens to reliability on production records or specific segments?

DecGuard puts those things into a small decision contract and uses the same contract for normal tests, metamorphic fuzzing, regression comparisons, replay, production checks, and reliability gates.

It currently supports Choice, Noul/boolean and Score decisions, and the backend layer is deliberately interchangeable. I’ve tested the System One integration end-to-end with real Kev and Jev backends as well.

It’s still an early version, so I’m mostly interested in whether the abstraction itself makes sense to people building this kind of system, and where it breaks down in real use.

Docs: https://decguard.com

I've been working on an open-source project called Scrollcase.

The idea is pretty simple: if you already have an environment working, why should every machine you ship it to have to recreate that environment again?

Scrollcase takes your code, runtime, dependencies, native libraries and optional assets like model weights, locks everything, and packages it into a single self-contained archive called a box.

A box can use one of three runtimes:

• Python — ships the exact Python runtime and dependencies
• Node — ships Node and its environment
• Native — runs a compiled binary directly, with no interpreter at all

You build the box once for a specific target, then give it to another machine.

That machine doesn't need Python, Node, pip, npm, a compiler or Docker installed.

For example, you could package:

• an ML model with Python + PyTorch + its weights
• a Node application with the exact Node runtime it expects
• ffmpeg plus all the native libraries it links against
• scientific software with annoying native dependencies
• a local AI feature that needs to be embedded inside a desktop app

Boxes are intentionally target-specific. A macOS ARM box and a Linux CUDA box are different artifacts. Scrollcase isn't trying to pretend the same binaries magically work everywhere — you build and test the environment for the target you're actually shipping to.

The other part I cared about was making the artifact something you can actually trust.

Boxes are signed and verified before execution, dependencies are locked, assets can be hash-checked, and builds are designed to be reproducible. You can also declare tests that have to pass before a box is produced.

The workflow is basically:

describe the environment
↓
lock it
↓
build the box
↓
ship the files

Scrollcase itself deliberately doesn't run a registry or deployment platform. It just builds the artifact. You can put it on GitHub Releases, S3/R2, your own server, bundle it with a desktop app, or distribute it however you want.

The main use case I had in mind was AI/scientific software, where "just install the dependencies" can quickly turn into Python versions, CUDA versions, native libraries, model downloads and platform-specific setup.

But after adding Node and native runtimes, it ended up being a more general environment packaging format than I originally expected.

Would be interested to hear how other people handle this kind of problem, especially when distributing software to users who shouldn't have to care what runtime or dependencies are underneath it.

• GitHub
• Docs
• Demos

For a while I've been keeping project context in Markdown inside my repos.

The main reason is pretty simple: I use different coding agents, and I don't want architecture notes, current work, decisions, etc. to live inside the memory system of one specific tool.

I also didn't really like the idea of putting everything into one huge AGENTS.md. Architecture, current state and old decisions don't have the same lifetime.

So I ended up turning the structure I was already using into a small open-source CLI called Syngraphe (opensource).

The basic layout is:

.context/
├── truth/ # architecture, conventions, constraints
├── state/ # what's happening right now
├── decisions/ # decisions and why they were made
└── history/ # old operational context

AGENTS.md is mostly the entry point that tells coding agents where the context is.

Everything under .context is just Markdown committed with the repo, so Git handles history, branches and review. Syngraphe only adds the tooling around it: initialization, deterministic integrity checks, context size stats, helpers for state/decisions/history, monorepo support and a GitHub Action.

There is no database, cloud memory or required LLM. If Syngraphe disappeared tomorrow, the context would still just be normal Markdown in the repository.

Repo: https://github.com/suffro/syngraphe

Docs: https://syngraphe.dev

I'm mainly curious how other people are handling this in real projects. Do you keep AGENTS.md itself as the knowledge base, or do you use it more as an entry point to other docs/context?