fishtoaster

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

[0] https://en.wikipedia.org/wiki/DNA_Lounge

> 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.

Yeah, this feels right on the cusp of being interesting. I think that, being charitable, it could be interesting if it turns out to be successful in hiring and coordinating several people and physical assets over a long time horizon. For example, it'd be pretty cool if it could:

1. Do some research (as it's already done)

2. Rent the land and hire someone to grow the corn

3. Hire someone to harvest it, transport it, and store it

4. Manage to sell it

Doing #1 isn't terribly exciting - it's well established that AIs are pretty good at replacing an hour of googling - but if it could run a whole business process like this, that'd be neat.

This article makes a number of the standard arguments for hiring juniors and a couple new ones:

- Companies should hire juniors [at their own perceived detriment] to improve the overall industry

- Hire juniors because strong companies are resilient to junior mistakes [rather than hiring seniors and also becoming resilient]

- Juniors learning fast inspires others

- Juniors will teach your seniors how to use AI

Perhaps you can see why most companies don't find these terribly compelling.

Personally, I suspect we're going to have to wait for capitalism to fix this. Senior engineers will age out and the supply will drop. This will increase the cost of seniors until low-cost juniors start to look like a better option to the median hiring manager.

This post was so in-line with her writing that I was really expecting it to turn into an ad for Honeycomb at the end. I was pretty surprised with it turned out the author was unaffiliated!

Based on the later life updates, I suspect this was being humorous.

> After these zoom attempts, I didn't have any new moves left. I was being evicted. The bank repo'd my car. So I wrapped it there.

Well, TFA linked to https://pubmed.ncbi.nlm.nih.gov/29741239/

Yes. But that's like saying "a racecar would gain a competitive advantage by being faster."

Getting your internal structures right and aligning your incentives is one of the main challenges of building and running a large company! If it were easy, you wouldn't see nearly so many massively-inefficient corporate giants. :)

> Selling to businesses is very easy. You go to a business and you say "hey, you like making money?" And the business will say "why yes, I do like making money" and you will say "great, I can help you make more money.

This is so wrong it hurts. You'd be amazed at how often "I will save you $X, guaranteed, or your money back" is a non-starter when selling to companies.

I've spent a career very slowly gaining respect for enterprise sales people - going from "Ugh, sales people are all snakeoil salesmen" to "I can't believe what they do is even possible, much less regularly done" over about 20 years.

Selling software to large organizations involves finding a champion within the org, then figuring out the power structure within the org via an impressive sort of kremlinology. You have to figure out who loves your product in the org, who hates it, who can make the buying decision, whose approval is needed, who's handling the details of the contract, and so on. You need to understand the constellation of people across engineering, procurement, legal, leadership, and finance – and then understand the incentive structures for each.

Then you have to actually operate this whole complex political machine to get them to buy something. Even if it's self-evidently in the interest of the whole organization to do so, it's not an easy thing to do.

Anyway, all that to say: "b2b sales are easy" is... naive... to say the least.

This is one of my next learning goals: getting a better feel for which models to use when. "100% claude 4 Sonnet" worked pretty well, but I want to keep pushing myself out of local maxima.

It's niche, but I wasn't really able to find anything else like it. I wanted to project our some retirement scenarios and my options seemed to be:

- Any of a few dozen "retirement calculators," each consisting of 6 fields and very simple outputs

- Building out a series of buggy spreadsheets

- Projection Lab

After messing around for it a bit, it was a "shut up and take my money" situation. It was cheap, it was powerful, it was nice to use, and it has been the foundation for my personal financial strategy for the last few years!

Haha, yeah, I, I was considering putting some disclaimers around those. "What actually are the true, base-level primitives of physics?" has been an ongoing project for centuries. :)

My take has always been:

1. D&D mechanics, like all games, are a simplification of the real world using primitives like "firing a bow" and "passing an item" and "downing a potion"

2. The real world is fractaly deep and uses primitives like "plank length" and "quark spin"

3. Therefore there will always be places where the real world and the simplification don't line up. Finding those gaps might be a fun meme, but it's not an exploit. We play with the simplification's primitives, not the real-world physics'.

Or just someone who's familiar with the terminology. I've never worked at Amazon, but I've heard the term for years as an Amazon thing.

The storage is not just an implementation detail because it affects how fast things run, which affects which tasks it's better or worse for. There's a reason people reach for a columnar datastore for some tasks and something like postgres or mysql for other tasks, even though both are technically capable of nearly the same queries.

Yep. Clickhouse is absolutely great for tons of production use cases.

Unless you try to join tables in it, in which case it will immediately explode.

More seriously, it's a columnar data store, not a relational database. It'll definitely pretend to be "postgres but faster", but that's a very thin and very leaky facade. You want to do massively a complex set of selects and conditional sums over one table with 3b rows and tb of data? You'll get a result in tens of seconds without optimization. You want to join two tables that postgres could handle easily? You'll OOM a machine with TB of memory.

So: good for very specific use cases. If you have those usecases, it's great! If you don't, use something else. Many large companies have those use cases.

Honestly, it's been pretty great at my tiny startup. The designer has a list of tweaks he wants that I could do pretty quickly... once I'm done with my current thing in a day or two. Or he can just throw claude at it. We've got CI, we've got visual diff testing, and I'll review his simple `margin-left: 12px;`->`margin-left: 16px;`.

But we're unlocking:

A) more dev capacity by having non-devs do simple tasks

B) a much tighter feedback loop between "designer wants a thing" and "thing exists in product"

C) more time for devs like me to focus on deeper, more involved work

GeneralMayhem captured it pretty well, but yeah: it's complex at every scale. You see some complexity, you zoom in, and you find that the bit you zoomed in on is just as complex!

Our founders are pretty deep domain experts on aws cost management. At this point one of them has pretty much a catch phrase: whenever I say how I think some little aspect of aws billing works, he'll reply with "Let me complicate that for you" and describe 2-3 edge cases where what I thought I knew doesn't quite apply. :)

Stealth | San Francisco, CA (hybrid: M-W-F ONSITE) | Full-time | Fullstack Engineer

We're looking for a backend-leaning fullstack dev. Highlights:

- We're a 5-person startup in San Francisco (hybrid: 3 days/week in office)

- We're working on a b2b SaaS for managing/analyzing cloud costs for really large companies.

- The domain isn't cool, but the complexity is fractal and the need is huge.

- Typescript/Python/Clickhouse currently

- Our founders are also the founders of the Duckbill Group, an AWS cost consultancy. As a result, we've got a great, built-in sales pipeline.

- As a result of that, we're bottlenecked on our ability to just build the features our users clearly want.

- So we're hiring a 4th engineer: a backend-leaning full stack dev to build and own large swaths of this thing we're creating!

- We're looking for someone with 5+ years of experience, though probably closer to 8-10, depending on the person and the experience.

- Comp is 175k-200k base, 0.5-0.75% equity.

If you're interested, apply here: https://careers.duckbillgroup.com/apply/CBxnybZYqm/Full-Stac...

I promise I'm personally reading everything that comes in through that link.

Sounds like this is the result of "accelerated depreciation." As far as I can tell, that's a strategy that ultimately allows you to pay less tax one year and more tax in a later year. I don't have a strong feeling on the value of that particular tax law, but it seems somewhat less nefarious than the implied "not paying taxes at all."

This seems somewhat useful. I've definitely found I have a much better signal-to-noise ratio on more focused job boards. The more focused, the better.

Eg when hiring at tiny startups, WorkAtAStartup (or Wellfound, if I'm not currently at a YC company) get a lot more candidates who are actually interested in working at a startup than general tech (or, god forbid, completely-general) job boards.

I'm really interested in this bit: "the fracture with the community is not about licensing, or at least it’s not mainly about licensing"

I wish he'd elaborated a bit more on what he thought it was about. My understanding is that it's 100% about the license. That's certainly why I'll reach for valkey instead of redis next time I need it. That's also what I've heard from everyone else in a similar position. What else would the community split be about?

I would second this. I have pretty extensive experience in a few python-like languages, and had written a few hundred lines of python over the years, but had never had a full-time job writing it. I had an upcoming job working on a python codebase. I found ExecuteProgram to be a pretty great as a way to bone up on intermediate python syntax, idioms, and standard library so I could minimize the first few weeks of "How do I do [common thing I know in 5 other languages] in python?"

I think this is a nice way to clarify the different use cases for version numbers:

- SemVer is a communication tool for when an author needs to tell a potential user what to expect from a new version.

- TrunkVer is an auditing/engineering tool for when you need to give a unique identifier to a version for technical reasons.

I think this page is a nice codification of a useful practice, but it does itself a disservice by positioning itself against SemVar and claiming to be a "drop-in" replacement.

That's why I offered the choice: different people do well under different circumstances. I figured that it'd allow me to hire a great dev who hates timed challenges or a great dev that hates take-home busywork. In practice, though, everyone like the take-homes, so ¯\_(ツ)_/¯

As for feeding it into an LLM, I go back and forth on that. With their current capabilities, the project is slightly too complex for that to work. You could get a lot of help from an AI, but you still have to put the pieces together yourself. And I'm fine with that! If AI tooling makes you a faster/better dev on a test, I'd expect it to do the same in real work.

Longer-term, though, I worry that LLMs still won't be able to "write the whole thing" for real work, but will be able to "write the whole thing" for takehome tests. And as such, I'll have to figure out how to handle that.

Yeah, that was the explicit tradeoff: I'm losing the ability to compare apples-to-apples. I decided it was worth the risks associated with that - that I'd wind up with two candidates who picked different options and I couldn't decide between them because I got different signal between them. As it turned out, it didn't really come up - nearly everyone chose the takehome. On a larger scale, though, you'd definitely have to grapple with that.

Because all evidence[0] I've found has shown that work-sample tests and repeatable, structured indicators are the best indicator of job performance. I understand that a lot of devs think they can get a feel for a candidate by just having a good ol' conversation with them, but the body of study on the subject says that that's just wrong. And so I have people do a task that's as close to the actual job as humanly possible and evaluate them on that.

https://www.researchgate.net/publication/283803351_The_Valid...