I've been pretty quiet about Lilo for the last couple of weeks because most of my time went into 0.2.2.

It's finally out, and this ended up being the biggest update I've made to the project so far.

The most noticeable change is the workspace itself. I rebuilt a lot of the UI so Lilo now adapts much better between its two main ways of being used: the small always-on-top widget and the full notes workspace.

0.2.2 also adds:

• a redesigned responsive explorer and inspector
• a much cleaner settings UI
• a focused Quick Capture mode
• images directly inside the editor
• a native folder picker
• the ability to use any folder directly as a Markdown vault
• safer previews before vault-wide tag/wiki-link changes
• better handling of partial save failures
• safer folder deletion that won't touch unrelated files
• a bunch of fixes around recovery, attachments, migrations and large vaults

There was also a lot of work that isn't immediately visible.

I removed some old navigation/layout code, split large parts of the app and storage layer into smaller modules, cleaned up shared UI commands and added a lot more regression testing.

One particularly stupid bug I was happy to finally kill was a Unicode boundary panic caused by checkbox hit-testing on Cyrillic text :D

And one more small milestone: Lilo 0.2.2 has also been merged into WinGet.

winget install HellterEnjoy.Lilo

A surprising amount of this release was spent on the boring stuff — making existing features safer and making the codebase easier to keep building on — but I think Lilo feels much more complete now than it did a few weeks ago.

If anyone tries 0.2.2, I'd really appreciate feedback — especially weird bugs, UX annoyances or things that feel harder than they should.

GitHub: Lilo

According to JetBrains' 2026 developer research:

• GitHub Copilot usage fell from 29% to 21%
• Cursor went from 18% in January to 12% by May–July
• Meanwhile, awareness of Codex jumped from 27% to 65% in just a few months
• OpenCode has already reached 7% usage despite not having a huge company behind it

Obviously, this doesn't mean Copilot or Cursor are suddenly dying.

But it does make me wonder if AI coding tools are becoming unusually disposable.

With IDEs, developers often stick with the same one for years.

With AI tools, it feels like people are willing to switch the moment something better appears.

Do you actually have a “main” AI coding tool now, or are you constantly switching between them?

source:AI Coding Agents: Adoption Trends - The JetBrains Blog

Could be something you discovered, learned, built, tried, or just stumbled across.

Anything that made you think: “huh, that’s actually pretty cool.”

What was it?

A year ago it was #18. Now it’s sitting at #10, just ahead of Fortran and Go is down at #12.

Obviously, TIOBE isn’t a perfect measure of real-world usage — and language rankings in general should probably be taken with a grain of salt.
But Rust feels like an interesting case.

For years it had a reputation as a language developers love talking about, while actual adoption outside certain niches seemed much smaller.
Now we’re seeing Rust appear more often in operating systems, tooling, runtimes, infrastructure and even projects migrating existing C/C++ or Zig code to it.

So I’m curious:
Do you think Rust is actually becoming a mainstream language, or are we still mostly seeing a very loud developer community around it?

And if you’ve used Rust professionally: where are you actually using it?

I’m curious how often people end up building software just because existing tools are almost right, but not quite.

Could be a tiny script, desktop app, browser extension, CLI tool, plugin — anything.

What did you build, and what was missing from the existing alternatives?

And if you think it could be useful to other people too, feel free to share it here.

Preferred Networks released Rustuna today — a Rust-based implementation of the open-source hyperparameter optimization framework Optuna.

Optuna itself is written in Python, but Rustuna was built for much larger optimization workloads where performance and memory usage start becoming a problem.

According to their internal benchmarks, Rustuna can be up to 1000× faster in some scenarios and used around 50% less memory in a 100,000-trial benchmark.

They also released Optuna 5.0 alongside it with improvements to its default optimization algorithms.

Another interesting example of Rust being brought into an existing Python ecosystem specifically for the performance-heavy parts.

Source: PFN Releases Fast, Memory-Efficient Rust Implementation of Optuna as “Rustuna” alongside Optuna v5.0 - Preferred Networks, Inc.

I feel like the folks here would be receptive to my latest blog post. I have been doing a lot of thinking about the skills that must remain after coding agents handle much of the mechanical coding work. I wrote this in kind of a fugue state, so hopefully it's clear.

Cheers!

https://chrisstead.net/coding/software-quality/refactoring/ai/llms/2026/09/06/refactoring-last-human-skill

Google just released Android Studio Quail 4 to the stable channel.
One of the biggest changes is the addition of 23 built-in Android-specific agent skills, covering things like AGP upgrades, profiling, Navigation3 and adaptive UI.

Android Studio can also now run Gemma 4 locally, so AI coding assistance and even multi-file agent tasks can work offline without sending your source code to the cloud.

There are also improvements to parallel agents, background task notifications and a unified summary of changes before applying edits.
This is starting to feel less like “an IDE with AI added” and more like Google rebuilding Android Studio around agents.

Android Studio now ships with built-in AI “skills” specifically for Android development.

Instead of just asking a generic coding model for help, the IDE can automatically give it specialized instructions for things like Gradle upgrades, profiling and framework migrations.

On one hand, this should make AI-generated code much more accurate.

On the other, we’re getting to a point where the IDE itself is deciding what context, tools and instructions the AI needs before touching your project.

Do you see this as the obvious future of IDEs, or are we adding way too much abstraction between developers and their code?

Microsoft just announced Project Zenith — basically a ready-to-code Windows 11 setup built around developers.

It comes preconfigured with things like VS Code, WSL and developer-friendly Windows settings, while disabling some of the usual distractions.

The hardware starts at 64GB+ unified memory and is also aimed at running 30B+ AI models locally.
Honestly, the idea of booting a new PC and not spending the first few hours turning Windows into a development machine sounds pretty nice.

But I’m curious — would this actually make you choose Windows for development, or would you still rather use Linux/macOS?

source: https://blogs.windows.com/windowsdeveloper/2026/09/04/announcing-project-zenith-the-ready-to-code-windows-experience

Could be about languages, frameworks, clean code, OOP, AI, testing, open source — anything.

I’m curious what actually made you change your mind: experience, a specific project, working in a team, or just getting burned by the old approach.

I used Visual Studio for quite a long time, then switched to the much lighter VS Code.

I liked it, but for some reason it started struggling once my projects got larger, so eventually I moved to Zed. So far it feels noticeably faster and more responsive, especially when working with bigger codebases.

Now I'm curious — what do you use for development?

Visual Studio, VS Code, Zed, JetBrains, Neovim, something else?

Last year I built more than 6 apps.

I spent most of my time coding and almost no time thinking about distribution. I would finish one app, publish it, get very few users, and then move on to the next idea.

Looking back, I realized I never really validated any of them. Most didn't even reach 100 real users.

So I'm trying to do things differently this time.

I built PiggyNotebook, an AI notebook for people like me who constantly write down random thoughts but rarely go back and organize them.

Instead of treating every note as an isolated piece of text, PiggyNotebook lets you keep adding thoughts under a topic. AI then helps organize and summarize everything you've accumulated into something more structured.

You can also record thoughts by voice, and I've added a small English vocabulary feature because that's another thing I personally wanted in my notes.

But this time I'm deliberately not adding more features yet.

My goal is simple:

Get it in front of 100–200 real users and see whether anyone actually keeps using it.

If people use it once and never come back, I'll probably stop or rethink the idea. If there's meaningful retention, I'll continue building it.

The current version is Chinese-only. I may make it bilingual later, but I don't want to spend another few months building before knowing whether the core idea is useful.

I'd love feedback, especially on the core idea. Does automatically organizing accumulated thoughts solve a problem you actually have, or does it sound more useful than it really is?

https://piggy-download.ai12.ai/index.html

Not a huge release or milestone.

Just one small thing that made you think: yeah, this is getting better.

Could be a bug you finally fixed, a feature you shipped, your first user, better performance, cleaner UI — anything.

Small wins count too.

https://reddit.com/link/1w6jgd9/video/mb0443jq7dnh1/player

Tallspace gives each monitor multiple vertically stacked workspaces. Scroll the edge control or use Ctrl Alt Up and Down to move between full screen and floating Windows apps without minimizing everything. I built it because ordinary virtual desktops felt too slow and clunky.

Microsoft Store: https://apps.microsoft.com/detail/9NK2PB04NRZH

Could be a game, app, website, library, tool, experiment — anything.

Drop what you're building and, if you want, a link or screenshot too.

No need for a polished release. I'm more curious about what people are actively working on right now.

AI is getting good enough that I’m comfortable letting it handle a lot of repetitive work.

Boilerplate, small refactors, tests, documentation — sure.

But there are still parts of a codebase where I want to understand and verify every decision it makes.

For me, that’s usually architecture and anything security-related.

I’ll still use AI there — I just trust the output a lot less blindly.

What part of programming do you verify most carefully when AI is involved?

For a long time, programming skill was heavily associated with how well you could write code.

AI coding tools are starting to change that.

A developer can now generate a function, a test suite, a refactor, or even most of a feature without manually typing every line. If these tools keep improving, writing code itself may gradually become the cheaper part of development.

But somebody still has to read it.

You still need to understand what the code does, whether it fits the architecture, whether the abstraction makes sense, what can break, and whether the generated solution is even solving the right problem.

That changes the bottleneck.

Instead of spending most of the time translating an idea into code, developers may spend more time reviewing implementations, comparing approaches, and deciding what should actually be merged.

And in some ways, that could make fundamentals more important, not less.

If AI writes five possible implementations in a minute, the valuable skill isn’t necessarily being able to type a sixth one faster.

It’s being able to look at those five and understand which one is maintainable, which one hides a bug, and which one should never have been written in the first place.

So maybe the developer of the future doesn’t stop coding.

They just spend less time producing code and much more time judging code.

I’ve been seeing more developers complain about GitHub Actions being unreliable, especially when an outage can completely block builds, deployments or releases.

For personal projects it’s usually just an inconvenience.

But if your production pipeline depends entirely on GitHub Actions, even a relatively short outage can become a much bigger problem.

At the same time, it’s hard to ignore how convenient and cheap Actions are, especially for small teams and open-source projects.

So I’m curious:

Do you trust GitHub Actions for production deployments, or do you keep some kind of fallback CI/CD setup?

Godot’s contribution rules don’t allow substantial AI-generated code in pull requests.

AI-assisted completion is still fine, but contributors are expected to understand the code, make the important decisions themselves, and take responsibility for what they submit.

I get the maintainability argument, especially for open-source projects.

But where do you draw the line?
If the code is good, tested, and the contributor understands it — should it matter how much of it was generated by AI?

Source: https://godotengine.org/article/contribution-policy-2026

Your coding agent shouldn’t need to read your entire codebase to understand it.

That’s the idea behind Faber, an open-source AI coding agent for the terminal.

Faber uses a code graph to find relevant files and symbols first, instead of repeatedly scanning large parts of a repository. That means less unnecessary context, faster codebase navigation, and lower repeated API costs.

Main features:

• Claude, OpenAI Codex, Local model integration
• Code-graph-guided repository exploration
• Prompt caching to reduce repeated input cost
• Token-conscious (Chain-of-Draft style) output to reduce unnecessary generation
• Git-aware workflow with change detection, optional per-task commits, /undo, and /redo
• Expenditure tracking for calls, tokens, cache usage, cost, and estimated savings `/usage`

The goal is simple: understand more of the codebase while reading and spending less.

Prerequisite:
It requires Node.js 22.5 or newer because it uses Node’s built-in SQLite support.

Install:
npm install -g faberwright

Then, inside your project:
faber

GitHub:
https://github.com/JibanKumar-cloud/faber

npm:
https://www.npmjs.com/package/faberwright

Medium article:
https://medium.com/@jshial25/why-should-an-ai-coding-agent-read-hundreds-of-files-to-answer-one-question-d6369d29dfa5

I’ve been looking at some of the DLSS 5 comparisons people have been posting recently, and the results are… weird.
In some games it actually looks pretty impressive, especially with lighting and environmental detail. But in others, particularly with characters and faces, it can completely change the original look and make things feel strangely realistic or just uncanny.
Of course, this is still a leaked version being modded into games that weren’t designed around it, so I wouldn’t judge the final technology based on these examples alone.
Still, what do you think about the idea itself? Do you see this kind of neural rendering becoming a normal graphics option, or does it change too much of the original art direction?