@simonw Agree. Some of it can be partially alleviated with eg a bespoke commit agent who’s fed the right context and direction. Still not gonna be as good as human understanding though.
English
Kevin Courbet
136 posts
Kevin Courbet
@LonePasserby
Full stack engineering (incl. Web, APIs, Big Data, BI). Lead dev / engi manager in intl corporate for 10y+, now freelance. Ballroom dancer.
Paris, France Katılım Ocak 2015
58 Takip Edilen24 Takipçiler
I've been letting Claude and GLT-5.5 write almost all of my commit messages recently, but I don't feel great about it
"omitting the higher-level framing needed to understand broadly what the code is doing" is definitely the key problem there
Kenton Varda@KentonVarda
I just declared a moratorium against AI-written change descriptions (e.g. PR and commit messages, also issues/tickets) from my team. AI was writing change descriptions that were worse than useless to me as I tried to review PRs: outlining details of the code that could easily be seen by looking at the code, but omitting the higher-level framing needed to understand broadly what the code is doing. I think people like having AI write these things because the output looks structured and thorough, which makes it feel professional in a way. But this isn't actually valuable. Concise, high-level descriptions are better for everyone. If I need to use my own AI to interpret what your AI wrote then something is wrong. Let AI write code, sure, but for the description, I'd rather see your prompt than your output. We could maybe have extended agents.md with guidelines on writing descriptions, but this seemed a bit pointless since a good, concise change description only takes a few minutes to write -- not a significant time savings to delegate to AI. At least, it doesn't take long if you understand the code -- and if you don't understand the code, then I'm definitely not merging it.
English
I think on this topic, people will have vastly different opinions whether they are typically doing work solo vs working in a team. Also factually speaking, to get a PR on par with a really good human-made PR, you’d have to have a dedicated PR agent who is fed 1) the overall vision of the projet, 2) the whole git commit history, 3) minute details from the designer about the work increment (coming from grilling, …) 4) insights about what is more “important” or impactful for the team in terms of communication. This last part is what humans do best and LLMs struggle with. They can’t “read the room”. But yeah most of this can be definitely improved, but most people don’t have a dedicated PR description agent eg
English
@mattpocockuk I work on a team with dozens of bright, kind souls. Every day, I see a handful of PR descriptions I don’t like: verbose, dense with jargon, no progressive disclosure. I think it’s a genuinely difficult problem that large language models have yet to solve.
English
This is crazy to me
AI is an incredible lever for making PR's and commits easy to review
You just need a bit of steering to customize it to how you want
Kenton Varda@KentonVarda
I just declared a moratorium against AI-written change descriptions (e.g. PR and commit messages, also issues/tickets) from my team. AI was writing change descriptions that were worse than useless to me as I tried to review PRs: outlining details of the code that could easily be seen by looking at the code, but omitting the higher-level framing needed to understand broadly what the code is doing. I think people like having AI write these things because the output looks structured and thorough, which makes it feel professional in a way. But this isn't actually valuable. Concise, high-level descriptions are better for everyone. If I need to use my own AI to interpret what your AI wrote then something is wrong. Let AI write code, sure, but for the description, I'd rather see your prompt than your output. We could maybe have extended agents.md with guidelines on writing descriptions, but this seemed a bit pointless since a good, concise change description only takes a few minutes to write -- not a significant time savings to delegate to AI. At least, it doesn't take long if you understand the code -- and if you don't understand the code, then I'm definitely not merging it.
English
I’ve experienced the same actually. It depends where you set the bar for cognitive quality on PRs/Commits. Even with heavy steering and the right context, it will still make technically-true-but-off-the-mark statements. That’s the true hallmark of AI written text. You can tell it doesn’t know where it’s going, it’s just following instructions.
90% of the time it’s “fine” for documenting purposes. But Matt I’m sure you’re not reviewing PRs coming from other people. If they’re your own PRs you can easily wave the “inefficient communication overhead” away . If it’s coming from someone else, you haven’t been part of the design process etc, and you don’t have this cognitive baseline to help you separate the useful from the noise
English
What’s your solution for scaling the process documentation to the whole system level? That’s a challenge I’ve been trying to solve. Horizontally, in terms of breadth, vertically, in terms of relationships (drilling down from top to bottom). Or you’re just happy with being able to jump to a specific process / or it never gets more complex than 3 levels down etc?
English
@sivalabs Sure, if you look at it from a developer perspective. But I'm shifting left. Implementation details are in the guidelines, skills, and MCP.
The use cases and entity model in my process are the core elements and are understandable to all stakeholders.
English
While doing Spec Driven Development, I find myself in a situation again and again.
I create (or generate) a Spec, review it, if it looks good, I ask AI to implement it.
Once AI is done, when I take a look at the code, I realize I missed a couple of small things.
They are not too big to update the spec and ask AI to check for delta and patch the implementation.
So, I quickly make changes, but am too lazy to update the spec knowing there is less likely I will take a look at the already implemented spec in future. When in doubt I check the code.
Now there is drift in the spec and implementation.
Is this what some people are referring to when they say SDD doesn't work because we can't write a complete spec ahead of time?
English
I've got a pure Swift Metal renderer and bindings for libghostty-vt. This will enable libghostty users to basically drop a package into their Swift/Xcode projects and get a full blown terminal (emulation, rendering, or both). Coming soon...
Note that Ghostty itself has always been Metal-rendered on macOS, but Ghostty has a really complicated generic renderer and font subsystem meant to work across any combination of graphics API or font API.
This, on the other hand, is a pure Swift Apple-ecosystem (macOS and iOS) only package for libghostty embedders.
English
Long lived session with long-term goal, generally with an orchestrator agent, where the amount of important information is small -> /(auto)compact . Unit work slice is committed and integrated, -> /new. We did a lot of exploration in an interactive session, but somehow we're reaching the end of the context window, but the problem is not fully defined yet, /handover
English
I feel like I've developed a clear rationale for when to /compact, when to /clear, and when to /handoff
But I'm having trouble articulating it.
So, what's your mental model for when to do each?
English
Amongst my friends, Spotify is the lowest quality consumer app we still pay for. It certainly hasnt gotten noticeably better in the last couple years (arguably worse). So, this is not the positive look Ant and Spotify are spinning here.
Bigger picture, this is the problem with a lot of AI reporting. It reports completely meaningless metrics like deploys per day or LoC. Why don’t we start reporting consumer satisfaction reports? Actually end state research results.
All the no nuance AI people always come out and think that this is anti AI. Again, I think AI is great and Claude is great. But this is bad marketing and makes both look like clowns.
ClaudeDevs@ClaudeDevs
Boris sat down with Spotify VP of Engineering Niklas Gustavsson. Spotify ships 4,500 production deploys a day, and 73% of PRs are now AI-assisted.
English
Do you even play games? You completely discarded the latency issues which will always exist due to the network round trip. Even on the fastest connections and plan. The analogy is bad because for movies, either can deliver on the same experience. This is not true for cloud gaming.
English
@Jonathan_Blow do you use netflix/hulu or still buy everything on bluray?
English
you’ll get mad at me for saying this…but cloud gaming is so obviously more economically efficient than physical hardware I think it’s going to be the default soon.
your home console / pc is idle 90%+ of the day. meanwhile, data centers targets what, 5%, maybe at worst 10% idle.
every second a cloud gamer isn’t gaming, that hardware is being used for someone else, training, etc.
I think there should be a new measurement, something like cost-per effective FLOP hour that takes into account the TCO + effective utilization.
If a gamer spends $500 on a GPU, uses it for 3 years, but it’s only fully active ~5% of that period…the cost-per relative FLOP hour is crazy high! Meanwhile, a $50,000 datacenter GPU might have a *LOWER* cost-per FLOP hour just because the effective utilization is 90+%.
English
@lbartroli88 @shadcn I did - I still don't like the jump. It's a cognitive load / context shift in itself (I was looking at text right there and suddenly its all shifted up). Granted, it's not that big of deal in the grand scheme of things but here we are
English
What Makes a Great Streaming Chat Experience
Start here: Never move the reader against their intent.
1. Move only when the reader asked to move.
If someone is reading, don’t pull them somewhere else. Auto-scroll should never be the default.
2. Follow only while they’re following.
If they’re at the live edge, keep the stream in view. If they scroll away, leave them there.
3. Every interaction is intent.
Scrolling is not the only signal. Selecting text, using the keyboard, opening a link, searching should all stop the interface from moving.
4. Start a new turn near the top of the viewport.
This gives the new turn somewhere it can be read from the beginning.
5. Then stream in the answer.
The streaming answer can then grow into the available space.
6. Keep part of the previous conversation in context.
Enough of the previous turn should remain visible so the reader knows where they are. Context.
7. Let new content arrive offscreen.
The conversation can keep streaming without changing what the reader is looking at.
8. Show what’s happening out of view.
Make it clear when a response is still streaming or when new messages have arrived.
9. Make it easy to return to the latest reply.
A "Jump to latest" action should bring the reader back and resume following.
10. Let people jump anywhere in the conversation.
Long threads need message links, search, unread markers, and direct navigation.
11. Reopen where the reader left off.
A saved conversation should open at the last meaningful turn. This is usually the last user message. Not the absolute bottom.
12. Keep the reader’s place when layout changes.
Images load. Markdown expands. Code blocks render. Older messages appear above. None of that should make the reader lose their place.
13. Handle interruptions without stealing position.
Stopping, retrying, regenerating, branching, or errors should not unexpectedly move the conversation.
14. Stay responsive in long threads.
Streaming text, markdown, code, images, and long history should still feel responsive.
15. Be accessible without the noise.
Keep the transcript navigable, preserve keyboard focus, and announce important events at a comfortable pace.
It’s all about the scroll. Scroll Engineering.
English
@mattpocockuk A bit yes. However functionally speaking, it works well. In addition to what Loic says, I see the research work as an issue to be completed. Once it's been completed, it can be referenced by PRDs. I use tags / labels to facilitate discovery / introspection. Having it all in one place makes it convenient. I agree that instincts make us want to somehow store that differently. However in my experience, the more locations we have to store things the more disconnected they become, cognitively. It's a bit like code collocation lol
English
@mattpocockuk @LonePasserby I know a big company that does everything through github issues and a tag system to differentiate deep dive, design documentation and so on
English
There are a class of AI Coding assets that IMO don't really belong checked into git:
- PRD's
- Research files
- Decision maps
- Implementation plans
Folks who agree with me, what are you using instead?
English
@mitchellh @AstrohackerLabs So many butthurt people by something that is trivial to avoid if you’re paying any modicum of attention to what you’re doing. They’re not worth your time lol
English
I’m a huge proponent for AI. You can see how much I use it and others in my projects do too. Plus my writing on it. I’m not anti AI. I’m anti idiot. I’m pushing people to recognize that AI is still a tool, and bad AI outputs aren’t because AI is bad but because the person is an idiot.
English
this is what anti-ai psychosis looks like. the dude is so obsessed with naysaying ai that he poisons the AGENTS.md files.
Mitchell Hashimoto@mitchellh
Got em. I poison my AGENTS.md (and other things like code comments) all over the place with prompt injections like this to find people who don't review their code and sling it off to another human. Catches folks all the time and then its an instant ban. As I've said, I don't care if you don't review your own code. But if you're submitting code to an OSS project and crossing a human boundary, it is simple courtesy to do some human review.
English
Disagree on composability. If you architecture your codebase right from the get go, all that is different between the two is the router semantics and SSR-only considerations. Most of your business logic should be on the server anyway, SPA or not. I’ve switched entire
codebases back and forth using the adapter pattern and it was pretty quick. But I use Effect
English
SPAs are still the right call for most applications.
SSR unnecessarily overcomplicates your architecture and ultimately hurts composability as the codebase grows.
English
@tsoding I get the same with Factorio. I literally had to balance side projects with it haha
English
The demo is absolutely great! My only complaint is that it seems to be using up the same energy I use for programming. If I work on my projects I can't play the game, and if I play the game I can't program. But maybe that's how puzzle games usually go, I play them rather rarely
Jonathan Blow@Jonathan_Blow
The free demo for Order of the Sinking Star has been going great -- people really like it! We will upload Part 2 for you on Friday morning, but if you haven't tried it yet, you may want to get in there and play before the new puzzles drop! store.steampowered.com/app/4597250/Or…
English
@tannerlinsley @edun_omatseye @tan_stack My man Tanner you got a gross timeline on that? Approx. Cheers
English
@edun_omatseye @tan_stack Because we haven't announced it yet... 🤫
English
Tanstack: why is difficulty to find docs about @tan_stack workflow library from the website directly? Also not listed among the list of libraries??
I literally had to hack to get the link:
tanstack.com/workflow/latest
GIF
English
@Jonathan_Blow The only thing that explains this Pivot to me is:
What if.. they built something close to AGI and used it to build this MRI device? Is that a farfetched proposition?
English
That’s … an unexpected pivot.
x.com/altryne/status…
Alex Volkov @ AI Engineer@altryne
MidJourney just announced... a full body ultrasound! Yup... read on because it's as crazy as it sounds. "As powerful as MRI and as casual as a trip to the spa" They are calling it "the @midjourney scanner" Insane details: - First, the scale. The device uses 8,960 individual transducers arranged in a ring around your body - The precision is the most jaw-dropping part: it resolves motion at the picometer range. It can image internal tissues finer than the width of an atom. We are talking sub-atomic level diagnostic capability - The compute requirement is massive. The system processes 17 gigabytes of data per second. It takes 40GB of raw data to reconstruct just one cross-sectional slice. And they are planning to scan 100 slices? - Midjourney claims that fewer than 12 of these machines could perform more full-body scans than every MRI machine on Earth combined. Welcome to the future of healthcare! Not only these scanners are announced, they will exist in a "Midjourney SPA" - with hot tubs, saunas, cold plunges, and 9-10 whole body scanners.
English
@justalexoki Even if you’re not you do. That’s the whole point of it
English
If this is the model that should convince me to pay token-based pricing from Anthropic it's not even remotely close:
- slow as hell
- doesn't follow instruction
- ships security issues claiming perf gains
- less intelligent at coding than GPT 5.5 (even 5.3)
Michael Arnaldi@MichaelArnaldi
First impressions on Fable 5, it fails to follow basic instructions and always want to run very long sessions. Overall writes good code but nothing impressive so far.
English