SF-based generalist engineer-type person at various tiny startups, currently first engineer at a fledgling startup. kevinhighwater.com / [email protected] / https://ruby.social/@kkuchta / https://bsky.app/profile/kevinkuchta.com
Submissions
Forcing Myself to Vibe Code
kevinhighwater.com
1 points·by fishtoaster··3 comments
Show HN: Kriegspiel Tic Tac Toe
kttt.io
2 points·by fishtoaster··0 comments
Why TypeScript?
eng.daybreakhealth.com
2 points·by fishtoaster··0 comments
Show HN: SqlToApi – Does what it say on the tin
sqltoapi.com
3 points·by fishtoaster··0 comments
Ducktools: Power Tools for AWS Spend
ducktools.com
4 points·by fishtoaster··2 comments
A Case Against Platform Teams
kislayverma.com
2 points·by fishtoaster··0 comments
TabDB: An SQL-able database in the browser tabs
tabdb.io
1 points·by fishtoaster··0 comments
Scarr: production-grade flatfile sites on AWS with one command
github.com
3 points·by fishtoaster··0 comments
Building a Url-Shortener with Lambda – JUST Lambda
2 points·by fishtoaster··0 comments
Disguising Ruby as JavaScript
kevinkuchta.com
2 points·by fishtoaster··0 comments
How to Use Time
kevinkuchta.com
1 points·by fishtoaster··0 comments
Asm.js Chess Battle
dev.windows.com
175 points·by fishtoaster··37 comments
Down with Craftsmanship
kevinkuchta.com
3 points·by fishtoaster··0 comments
The S in Rest
teddziuba.github.io
147 points·by fishtoaster··70 comments
How to survive a flat-managment mutiney
pando.com
1 points·by fishtoaster··0 comments
3 Reasons Why ROI Analysis Doesn’t Work for Freemium
blog.expensify.com
1 points·by fishtoaster··0 comments
Startups are Rockets
kevinkuchta.com
1 points·by fishtoaster··0 comments
Why Expensify endorsing Bitcoin is a really big deal
As I mentioned explicitly in the comment you're replying to: yes, I did read that section. Did you not bother to read my whole comment before telling me to read more?
There's some good ideas and points in here, but this bit threw me:
> # We tried this
> In July 2025 we went full lights-off
Isn't it pretty well-accepted at this point that the models underwent a step-change in usefulness around fall 2025 / spring 2026? I know that I was able to start handing agents whole features after that, but not before.
I feel like any perspective/experience on "what agents can/can't do" from before that period is... maybe less than relevant to the modern era. TFA calls it out a few sections later with "But surely the models have gotten better since then", but then just writes off any improvement. That does not match my experience.
Unfortunately I never got around to trying it! I remember it being a contender around the time of Backbone, but then Ember and Angular were the main options thereafter.
"React is actually a library, not a framework" is definitely a thing people have said here and there since its inception. It's a distinction that doesn't seem to buy anything in terms of explanatory power or clarity, so I tend to ignore it.
As someone who lived through all major waves of JS for the last ~16 years, I do love react, in a sense:
React is the worst JS framework except for all the others we've tried.
I'd take React over the Angular 1 days any time. I'd take Angular 1's full-bodied MVC over the "build it yourself from scratch every time" approach of Backbone. I'd take Backbone's minimal MVC structure over the classic JQuery Soup architecture. And I'd take JQuery's dom manipulations and standard-library improvements over the native apis (of that era) in an instant.
React has its tradeoffs, but we got here after a long slog of other things that don't work.
Interesting! Given the obvious AI-written nature of this, I'd probably want to double-check the math, but it's a neat concept.
As a homebrewer, the standard approach is to look up / measure your tap water's profile, buy a few grams of additives (gypsum, calcium chloride, epsom salt, etc), and add them to compensate. But if you don't have your water profile handy, this could work in a pinch. 5 gallons of bottled water is an expensive approach, though!
I landed on something similar for my own game, though it's been pretty tricky.
I'm building a physics-based 2d game involving slingshotting around planets. The realtime nature of it has meant that it's nearly impossible for the AI to test using a browser mcp. It'll take one screenshot, then another, and in the intervening time the player shot off the map and into deep space.
Instead I gave it both a code-level api to step forward and backward the physics engine and a browser-based, `window.game` api to do it via a browser mcp console. The former helps it work out physics bugs and the latter helps it test animation and UI issues.
It's still not great. I keep occasionally getting "I tested it and it works perfectly!" as I stare at the mcp'd browser with the player stuck clipped halfway into a planet. I think, if anything, I need to lean harder into this approach: building really solid tooling for the AI to inspect every aspect of state. I would kill for a turn-based game like OP XD
An alternate interpretation of that chart is "After the microsoft acquisition, they got serious about actually tracking outages."
That said, anecdotally, it's felt much worse over the last 6 months. I'd guess it's a combination of MS-induced quality drops and AI-induced scale increases.
Yeah, I think all style comments should be handled by either a linter/formatter or be written in a style guide. Everything else is up to personal preference.
Then, when a style comment comes up in a PR, the answer is "Oh, do you think we should add that to our style guide? If so, let's discuss that in slack. Until then, though, that's not blocking."
Winning 2000 games in a row sounds statistically unlikely unless the Windows version of solitaire does something behind the scenes to make the game more winnable.
> This is the part that doesn’t demo well. ETL pipelines feeding into BigQuery from every operational system: Salesforce, Zendesk, and a dozen other internal tools. dbt transformations that normalize and document the data. Column-level descriptions for every table in the warehouse, because an AI agent that doesn’t know what a column means will write SQL that looks right and returns wrong numbers.
I'm glad they called this out. For the first half of this, I kept thinking: "Either your answers are confidently wrong or you've done a ton of prep work to let your AIs be effective BI analysts." Sounds like it's the latter, and they're well aware of it!
For real, I'm not certain we will ever be able to merge AI code without human review. But:
1. Every time I've confidently though "AI will never be able to do X" in the last year, I've later been proven wrong, so I'm a bit wary to assume that again without strong reasons.
2. I see blog posts by some of the most AI-forward people that seems to imply some people are already managing large codebases without human review of raw code. Maybe they're full of crap - there are certainly plenty of over-credulous bs artists in the AI space - but maybe they're not.
3. The returns on figuring this out are so incredibly high that, if it's possible, people will figure it out.
All that to say: it's far from certain, but my bias is that it is possible.
Figuring out how to trust AI-written code faster is the project of software engineering for the next few years, IMO.
We'll need to figure out the techniques and strategies that let us merge AI code sight unseen. Some ideas that have already started floating around:
- Include the spec for the change in your PR and only bother reviewing that, on the assumption that the AI faithfully executed it
- Lean harder on your deterministic verification: unit tests, full stack tests, linters, formatters, static analysis
- Get better ai-based review: greptile and bugbot and half a dozen others
- Lean into your observability tooling so that AIs can fix your production bugs so fast they don't even matter.
None of these seem fully sufficient right now, but it's such a new problem that I suspect we'll be figuring this out for the next few years at least. Maybe one of these becomes the silver bullet or maybe it's just a bunch of lead bullets.
But anyone who's able to ship AI code without human review (and without their codebase collapsing) will run circles around the rest.
This is a great use of data to make a compelling case that sizing sucks for women's clothing!
I do wish it attempted to answer the question at the end, though: "Sizes are all made up anyway — why can’t we make them better?"
Like, why doesn't the market solve for this? If the median woman can't buy clothing that fits in many brands, surely that's a huge marketing opportunity for any of the thousands of other clothing brands?
This is, to be clear, a sincere question - not a veiled argument against OP or anything! It seems like there are probably some structural or psychological or market forces stopping that from happening and I'd love to understand them. Same with the "womens clothes have no pockets" thing!
It feels like someone asked an AI to read a year of output from a ruby link roundup newsletter and then had it write a report: many facts, minimal synthesis, and little-to-no useful opinion/summary.
I'm a big fan of this genre of "a person got rich in tech and spent their wealth making an unrelated thing they wanted to exist in the world, untethered from the need to be profitable or self-sustaining."
See also, Jamie Zawinski's DNA Lounge[0] in San Francisco
> if you have any code you actually care about I would watch them like a hawk, in a nice large IDE on the side.
This is about where I'm at. I love pure claude code for code I don't care about, but for anything I'm working on with other people I need to audit the results - which I much prefer to do in an IDE.