Show HN за 8 июня 2026 г.

hope you enjoy

What works now: user signups, org creations, private/public repos, and importing GitHub repositories (both as read-only mirrors and full migrations). So basically, you can create, push and pull to a repo, but we don't have many features quite yet (issues, PRs, CI).

What is a bit unique is: 1) we built it in Rust and 2) the website is a little odd. Its design is inspired by CLIs (e.g., fzf, broot, vim) instead of web apps, and as such, lacks some affordances that you might typically expect in favor of keyboard-driven instant navigations (we have the very ambitious goal of an FCP of 100ms). In case you're curious, here's how we we built it: https://gitdot.io/designs

We recognize that we're making some bold claims here and are also well aware that we have much to learn. Building software is still hard, and that's a fact we seem to relearn everyday.

But we wanted to share what we built so far nonetheless.

Cheers, thank y'all for reading, and till the next —paul & mikkel.

Hi HN! We’re Jimmy and Ray. Jimmy is a Thiel Fellow with a Ph. D. from MIT who has worked on programming tools for 15 years; Ray became VP of Sales at a $2B company when he was 19 and has built side-businesses vibe-coding.

Last year, we set to answer the question “If AI can write code 100x faster, then why aren’t you shipping 100x faster?” What we learned shocked us — even fairly nontechnical people and solo founders told us they were spending more than half of their development time reading the AI-written code. And much of the rest of the time was spent either de-slop-ping it, or wishing they had done so.

As luck turns out, our last two products were a tool that quickly onboards people to large codebases ( https://x.com/0xjimmyk/status/1873357324229984677 ) and trainings that taught deep concepts of code quality to CEOs, YC founders, and engineers at top companies ( mirdin.com ), so we were extremely well-positioned to solve these problems.

Command Center is an agentic coding environment focused on quality. With a few keypresses, you can start building 3 features at once and soon have 3 diffs ready, each consisting of 2000 changed lines across 50 files….

This is normally the point where you think “Crap, what now?”

With Command Center, at this point you simply click “Refactor,” and watch the vibed slop turn into readable robustness. Then you click “Generate Walkthrough,” and then suddenly, to read a 2000 line diff, instead of scrolling up and down trying to make sense of it, you just press the right arrow key 200 times. See something you don’t like? Click on line 37, type “Do this and all other network fetches in the background Cmd+Enter,” and you have a few more agents getting your code into final shape. Click or type “Commit,” “Push,” “Create PR” — you just shipped a high quality, non-slop feature

We’re striving to be the best at every step of the pipeline, but can just try Command Center in pieces wherever you feel your current workflow is weakest. We have users who do all their coding in Zed or the Codex app, and then jump over to Command Center for a walkthrough when it finishes running. There’s even a skill that will pop open a Command Center walkthrough from the environment of your choice. Or you can just keep Command Center running while you do your work elsewhere, and if your AI deletes anything, you have Command Center’s snapshots to the rescue.

We launched quietly last year and have been refining since. The quality and usability have kept going up, and Command Center is now ready for a lot more attention.

Since our quiet launch, we’ve seen at least a dozen other agentic coding environments appear….approximately all of which have the same feature set focused on the part which is already easy (generating the first version of the code) and with at best a shoddy answer to the hard part (everything that comes after). Command Center’s focus is making the hard parts easy.

Here’s what our users have to say:

“[The refactorings] give your LLM taste. I’ve never seen an LLM write code this good before.” — Doug Slater, Staff Engineer, Climavision

“With Command Center walkthroughs, I can get through a 400-line diff in less than half the time.” — Prateek Kumar, Platfor Engineer, Sumo Logic

This product is not for everyone. If you’re someone who preaches “the prompt is the source, the code is the compiler output,” then you probably won’t enjoy Command Center.

But if you want to uphold traditional engineering discipline while also shipping 20 PRs a day, then this is the environment for you.

I built a pair programmer, using AI, but now am trying to go slow with new languages and paradigms using this package.

I have noticed a decline in my programming skills, and wondered why I couldn't use AI as a pair programmer. Why can it watch what I'm doing over my shoulder and suggest changes? That way I can struggle through problems still and actually learn something.

Results have been good so far :)

Hi HN,

I'm the creator of Mach (https://github.com/octalide/mach or https://machlang.org). Two days ago, we finally achieved full self hosting. I wanted to make a post here to show off the language since this is a big milestone for us.

## TL;DR about the language for those curious:

- There are no external dependencies anywhere in the pipeline. This includes LLVM, libc bindings, or anything of the sort (save for the historical bootstrap compiler, which requires any C compiler and has been phased out completely).

- Mach is extremely opinionated and very anti-magic. WYSIWYG is a core principal for the language. There are no hidden behaviors, implicit type conversions, or "automatic features". Simplicity and stripping away ambiguity are core principals that this language upholds.

- Performance currently lags behind C by about a factor of only 4x at the time of writing, almost entirely due to the lack of deep compiler optimizations like autovectorization, which have not been fully implemented yet. Eventually, Mach will be at least on par with C.

## Why did I build this?

I love low level systems languages like C, Zig, Go, and (sometimes) Rust, but I wanted something that actively discourages "cleverness" in favor of long-term maintainability and overall clarity. Mach is highly opinionated and explicitly demands verbosity in ways that other languages are afraid to. Computers aren't magic, and code you write should not pretend they are. This project initially started out as a learning opportunity for myself, but grew into a fully featured language as time went on. There is still a lot I have to learn, however, and I'm excited to be able to do so as this project continues to grow into the future.

## Why do I (the reader) care?

If you like C, you'll probably like Mach. Mach takes heavy inspiration from the "vibe" of writing C, but improves on much of the syntax, lacks quite a few footguns, "unhides" a lot of internal mechanisms, and has a FAR better dependency management system.

If you want to play around with a language that is fully capable of replacing C, and especially if you would like to contribute to its development, then PLEASE stop by and mess around.

## Where should I go to check it out?

The github repository has a link to our discord if you'd like to chat with myself or our few other regular users. My personal account has all of the tooling that exists as well as a few example repos if you feel inclined to try it out.

## Will this project by dead in X months?

I've been working on this in the background for over 2 years now. This is a long term project that I plan to maintain into the indefinite future, with or without a userbase. If you like the language at all, I highly encourage you to get involved in its development because it WILL be sticking around in some capacity forever.

I know this was a bit "rambly", but let me just say that it's been a great joy to work on this project and I would love any and ALL opinions and contributions, ESPECIALLY if you hate the language or find a problem that needs fixing. Let me know what you guys think!

It started after reading Stephen King's "On Writing" where he likened the art of writing as the unearthing of an archeological site after you stumbled upon a unique bone of a story. His advice was to choose a domain you are deeply intimate with. For me, I've been a struggling startup founder for 15 years—enough material to inspire a novel.

A 1,000-word writing exercise turned into a complete 125k-word manuscript over the course of a year.

In year 1, I learned the sheer joy of unencumbered creative flow and authentic expression. A similar flow I used to get from coding (and more recently vibe coding). What made it effortless was a mindset that I was writing for the sake of it, not with the intention of publishing.

After a year of keeping it close to my chest, I decided to show it to a few close friends. They liked some of it, destroyed some of it. Some ultimately encouraged me to publish it.

In year 2, I learned about the chasm between writing for myself and writing for an audience. Nerdy stuff I thought were clever completely flew over my readers' heads. So I studied a dozen textbooks on literature, prose, poetry, voice, grammar, and completely rewrote the manuscript twice over, this time with the audience in mind. There is a lot more finesse to writing than I originally appreciated.

In year 3, I felt ready to pitch literary agents. The reason wasn't to make a career out of writing, but to learn from professionals. After 100 personalized pitches and 0 offers of representation, I learned that pitching agents was much harder than pitching VCs. Especially for a niche novel like mine; fellow startup founders was too small of a TAM.

In year 4, I engaged with a professional author/editor (Rob Hart, author of The Warehouse), who gave me essays worth of incredible developmental feedback. Lots of nuanced feedback I couldn't get from textbooks. Per his advice, I started back at chapter 1 and refactored the whole manuscript. I distilled it down to the best 88k words.

The tinkering never stops; when do you know it's done? I realized that I kept on tinkering because it was more comfortable than overcoming the fear of launching. Today, on 06/08/26, almost 5 years after that Stephen King writing exercise, I'm ready to say “ship it.”

Blockchained is a near-future startup sci-fi thriller that chronicles a struggling startup founder who meets a mysterious investor in Hong Kong. Little does he know that the too-good-to-be-true investor works for the Chinese government.

Blockchained was written for the fellow startup founders, engineers, and near-future sci-fi enthusiasts. In other words, HN community, you are my target audience

Sample chapters available at https://www.blockchainednovel.com/ — eBook and paperback available today. Hardcover edition coming soon.

I suppose we live in an era where it must be qualified that Blockchained was 99.9% lovingly handcrafted. No AI was used to write this novel aside from research, spellcheck, grammar, and the occasional phrasing checks.

I posted a version of this over a year ago but decided to rebuild it recently.

Bored Spreadsheet is a collection of quick and easy games that look like a spreadsheet from a distance. I have tightened the app to be a collection of 6 games: Minesweeper, 2048, solitaire, sudoku, a market trading game and a daily reconciliation puzzle where the player must find bad data in a fake table.

The games are free to play but sign up is required to submit your scores to the leaderboard. As was the original intention over a year ago, I hope this proves useful to those office workers who have a lot of downtime in between tasks or meetings yet don’t have the freedom to open Youtube or Cyberpunk 2077 on their work computers. Ironically my work network has blocked the website as it “contains non-business-related services” – I hope you have better luck than me!

I built this because I wanted to make outbound HTTP/3 and raw QUIC connections from ordinary Node.js code, without building Node from source or putting everything behind a reverse proxy.

Repo: https://github.com/currentspace/http3 npm: https://www.npmjs.com/package/@currentspace/http3

It’s a native package around Rust/quiche. It supports both client and server APIs, but the client side is the part I care about most: raw QUIC streams, datagrams, custom ALPN, session behavior, and HTTP/3 client work from Node.

Install:

``` npm install @currentspace/http3 ```

Minimal raw QUIC client:

``` import { connectQuicAsync } from '@currentspace/http3';

const session = await connectQuicAsync('127.0.0.1:4433', { rejectUnauthorized: false, });

const stream = session.openStream(); stream.end(Buffer.from('hello QUIC')); ```

This is early and it’s native networking code, so I don’t expect people to trust it casually. I’m mainly sharing it because I’d like more eyes on the API shape and implementation model.

Hi HN,

Over the last few days I've been building USTPS (UDP Speedy Transmission Protocol Secure), an experimental encrypted transport protocol built on top of UDP.

The primary goal of USTPS is low-latency video streaming. A server can take a video source and expose it through a USTPS endpoint, while Linux and Android (Termux) clients receive the stream and expose it locally to applications such as VLC, mpv, and FFmpeg.

Although streaming is the main focus, USTPS is not limited to media delivery. It can also be used for other reliable encrypted UDP-based applications, which is why I built USSH on top of it.

Some of the main design differences compared to TCP-based transports are:

- USTPS is reliable but unordered. - If packet N is lost, later packets can still be accepted and processed immediately. - Missing packets are recovered through selective retransmission. - Ordering is handled by the application layer when needed.

This means the transport layer itself does not introduce Head-of-Line Blocking. The tradeoff is that applications which require ordering must implement reordering themselves. I consider this a reasonable tradeoff because it avoids forcing every application to pay the cost of transport-level ordering.

For media player compatibility, the default USTPS client creates a local TCP endpoint at 127.0.0.1:1238.

The client maintains a small reordering buffer (350 ms by default) to give retransmissions time to arrive before forwarding data to the local TCP stream. This allows existing software such as VLC, mpv, and FFmpeg to work without modification.

USTPS currently provides:

- Reliable delivery using ACKs and selective retransmissions - X25519 key exchange - AEAD encryption (AES-GCM and ChaCha20-Poly1305) - Optional unordered live output mode - Stream position metadata - Multi-client support - Local TCP compatibility output - No congestion control (currently intentional)

While developing USTPS, I also built USSH, an SSH-like remote shell running entirely over USTPS.

USSH uses the same unordered transport underneath, but the client reconstructs and orders terminal data before presenting it to the user. This prevents terminal corruption while still allowing the transport layer itself to remain unordered.

USSH includes:

- Interactive terminal sessions - PTY support - Password authentication - Host key verification (TOFU) - End-to-end encrypted communication through USTPS

I'm currently using USSH from my Android phone through Termux to manage my VPS.

The project is very young (less than a week old) and is primarily experimental and educational. I'm interested in feedback from people working on transport protocols, streaming systems, SSH implementations, QUIC, SCTP, and networking software.

USTP-Secure: https://github.com/x1colegal/USTP-Secure

USSH: https://github.com/x1colegal/USSH

Internet-Drafts:

USTPS Draft: https://datatracker.ietf.org/doc/draft-x1co-ustps/

USSH Draft: https://datatracker.ietf.org/doc/draft-x1co-ussh/

Questions, criticism, and suggestions are welcome.

Hey everyone, I've been working on a tool called Web Speed. It takes web pages full of HTML and parses them into an easily readable sitemap for an AI agent. By ensuring the AI doesn't have to analyze the full HTML from the page or screenshots of the page, it makes the agent a lot cheaper and faster. It's MCP-native, so any AI that supports MCP can run it and take control of your browser for you. There are both “normal” and post-auth versions live on GitHub. What I think is the coolest thing about the project is the global cache of sitemaps. When a user visits a site, it takes the sitemap and sends it up to the server so that later, a person can get that sitemap from the cache, further speeding up the agent. Right now, only the paid API version can access the cache. I would love your thoughts on the project, any ideas, criticisms, or concerns. I really just want to see if people think that this would be a useful tool. Please reach out if you have any questions about Web Speed. Repo (OSS): https://github.com/Dominic-Pi-Sunyer/web-speed-oss Repo (Post-auth): https://github.com/Dominic-Pi-Sunyer API and Docs: https://getwebspeed.io

Thanks, Dominic

After almost three years of development, the first developer preview of Kronotop is out.

Kronotop is a distributed multi-model database built on FoundationDB.

Our motto is: One transaction, multiple models.

Documents, ordered key-value data, and other models can participate in the same strictly serializable transaction, even across namespaces.

I'd love to hear your feedback.

Hi all! With the World Cup around the corner, and being a football fan, I went looking for apps that would give me a detailed overview of groups, matches categorized by group or team, a daily timeline of when games happen that day (especially useful for us in Europe, since some games run pretty late), and a way to follow my favorite team or teams. The problem I ran into was that most apps out there are pretty bloated — like, really bloated. The ones that weren't either didn't focus on the World Cup specifically, or were ridden with betting ads and ads in general. So I built a very minimal ad-free (mostly tailored for myself) World Cup web app for fixtures and live scores. The fixture data comes from the openfootball/worldcup.json project - https://github.com/openfootball/worldcup.json. I hope you find it helpful, would love any feedback.

I made an open-source project that will take an existing macOS swift project and make it easily compile into a Linux (GTK/ or Qt). It's part of a new quality Swift-first OS I am making called QuillOS.

I'm eager for help and for feedback.

Also looking for people who have Swift code (there is very little open source swift code) who can give me example apps to compile against this to find any missing holes. The simpler/smaller the better but any size good.

It's also easy to convert any working iOS app and adapt it to macOS with Claude, and then also cross-compile to Linux with this.

https://github.com/Lore-Hex/QuillUI

What's under the hood: - Real-time messaging powered by Firebase - Buddy lists, groups & online presence - Away messages with auto-reply (and the classic %n, %d, %t variables) - Buddy icons & editable profiles - Group chat rooms - The actual AIM sounds - Full Windows 98 desktop UI — taskbar, desktop icons, start menu, the works.

If you have any suggestions or feedback I would greatly appreciate hearing it. There's still more work to be done with it, but it's been a labor of love.

Right now every user that logs on is automatically put on to your Buddy list. I thought this would be a great way to get people to start chatting with each other.

The other day I had a conversation with this guy about skateboarding in the 90's, Tony Hawk Pro Skater, and he sent me a photo through an IM of his CCS magazine they occasionally send him.

Transit.c is an addition to the set of libraries to support transit data interchange format written in C11. It supports full 0.8 specification of cognitect's transit-format: JSON, JSON-Verbose and MessagePack encodings, all ground and extension types, compression via keys caching, extensibility via custom tag handlers.

Hi HN! We’re building Tutati, an app with a funky name that replaces the "broadcast-to-your-followers" model with one massive, shared live center stage. The concept is simple: the live streaming window opens, you jump in the queue, and when your turn hits, you go live to everyone for 60 seconds. Then the next person in the queue goes live and so on. It is 100% free. Our only ask is your brutally honest feedback, and that would mean a lot to us. Tell us what works, what doesn't, and what completely breaks.

Download the iOS app from here: https://testflight.apple.com/join/qJUHbNhd

No iPhone? Go-live or watch right in your browser: https://spotlyt-live.web.app/

The Next Live Window: Today, Monday, June 8 | 8:30–9:30 PM CT Add to Calendar: https://tutati.app/go-live

The Queue: Opens 30 min before at 8:00 PM CT. Join early to grab a spot on stage, or just show up at 8:30 to watch! Website: https://tutati.app/

Promo Video: https://youtube.com/shorts/jiHmbtRQsxM

We will be hanging out in the comments, so feel free to ask us anything about the build, the tech, the vision, etc. You can also drop your feedback at [email protected].

Technical Details:

This kind of architecture brings a few unique issues and we would like ideas and feedback on how to address them:

-Handling the live queue with growth - What do we do if someone drops (or their connection drops) mid-queue? How long do we wait? Do we jump to the next person? What if someone is #2 in the queue and leaves the queue? Do we bump up the next person who may not be ready?

-Since this is live streaming, any ideas on how to moderate the content with automation? Delay the live streaming for a few seconds to have time to moderate? We picked a direction and built it but your feedback here would be invaluable.

Last week, Anthropic released https://github.com/anthropics/defending-code-reference-harne..., a reference harness for autonomous vulnerability discovery that uses Claude Code agents to find, verify, and patch memory-safety bugs. I wanted to use it but I only have access to GitHub Copilot.

This is a port of that harness to the GitHub Copilot CLI. PORTING-PLAN.md covers the decisions made to map the handful of features that work differently between Claude Code and the Copilot CLI.

The result is a working reference for anyone who wants to build autonomous security agents on Copilot, tracking Anthropic's approach as closely as possible.

Feedback welcome!