This 1000 times. I’ve tried implementing what OP has mentioned, and quickly learned it isn’t possible. A city can also exist in multiple zip codes. And there can be multiple cities with the same name in the same state. So, to be safe, you have to enter city, state, and zip.
I don’t understand either of these arguments. They both appear to reinforce the point made in the article. At worst a zip code contains multiple cities? Voila the city box becomes a dropdown. It’s 2025. JavaScript.
I get the vibe that it's more like there's unexpected complexity and it's difficult to be confident you know how zipcodes work with enough detail to make the feature work. And that is just one example of possible complexity.
Do zipcodes change for example? Can your drop-down quickly go out-of-date? You'd need a way to manually enter a city so people are able to tell the system an address. Do you want to bother making an auto-updating zipcode feature just for a form?
Is it going to confuse people because nobody else has bothered to make this superfancy selection feature thing?
Is this USA only? There are postal codes/zipcode-equivalents in other countries.
It starts to feel it's likely not worth the time and effort to try to be smart about this particular feature. At least not if I'm imagining this us some generic, universal address web form that is supposed to be usable for USA-sized areas.
To me it feels similar to that famous article about what you can and cannot assume about people's names; turns out they can be way more complicated and weird than one might assume.
Although maybe zipcodes don't really go that deep in complexity. But on the spot I would not dare to assume they are.
> Is this USA only? There are postal codes/zipcode-equivalents in other countries.
This is where the real problems start - postcodes exist the world over.
Speaking as someone that has dealt with countries that have postcodes, but no states, so it's just Street Address (if applicable) | City (if applicable) | Country | Postcode
Inputting a "zip code" first would result in every country being in the drop down.
In Australia, addresses too are wild, they should be considered "free form"
What kind of app are you building? Maybe you're selling something. You probably want users to get through your check out form as fast as possible before they change their mind or get distracted or frustrated.
Or you're building an app for data entry and people are filling in lots of addresses every day. They would appreciate you saving them time.
Either way, spending a day or two to polish up your form can be worth a lot.
Not saying its trivial to get all the edge cases right, but I'm pretty sure we can do better here.
I just placed a delivery order from home depot and this is exactly how they handled it. I put in my zip, they gave me a drop down of the cities that zip covers (there are like 5 of them, incredibly) and I was on my way.
Even if a zip code contains multiple cities, each ZIP has one "preferred" locality name and you can default to that. Any of the locality names within a zip code is deliverable for all addresses in that zip code.
As has been pointed out in many other comments implicitly and explicitly, the purpose of a set of address fields in an HTML form is not always to come up with a USPS delivery address.
Except that's not what this page does, so it's harder than TFA makes it out to be. I am in a zip code that spans two cities, and it won't let me change the city name at all once I put my zip code in.
I have a 4 digit postcode, I have to look it up every time I have to fill in an address form for delivery.
I've had people screw 1 digit up in that postcode and their items (a laptop in one case) went to the completely wrong city.
A code sounds foolproof, until you realise most people don't engage with them for most of their lives - you don't tell the uber driver the zip/post code you are waiting in, and travelling to, nobody does.
edit: just to add - Magic numbers are bad. Software engineers know that a number that's undocumented in code is unmaintainable, a zip code is worse.
> I have a 4 digit postcode, I have to look it up every time I have to fill in an address form for delivery.
> A code sounds foolproof, until you realise most people don't engage with them for most of their lives - you don't tell the uber driver the zip/post code you are waiting in, and travelling to, nobody does.
When the above comments said +4, they meant knowing the second half of the nine digit zip code.
Basically everyone in the US knows the first 5 digits. It's really easy to memorize them. If you can remember your city, you can remember your zip code. And in the US you use it all the time, so it stays memorized.
> edit: just to add - Magic numbers are bad. Software engineers know that a number that's undocumented in code is unmaintainable, a zip code is worse.
That complaint about magic numbers is completely off base. Magic strings are just as bad in software. "Beverly Hills" and 90210 are equal sins on the magic front.
> Basically everyone in the US knows the first 5 digits. It's really easy to memorize them. If you can remember your city, you can remember your zip code. And in the US you use it all the time, so it stays memorized.
What's the 5 digits for Yonkers New York (edited because I originally had NYC)
> That complaint about magic numbers is completely off base. Magic strings are just as bad in software. "Beverly Hills" and 90210 are equal sins on the magic front.
For the same reasons, that's why it would be: Beverly Hills, Los Angelos County, California, USA, 90210
> What's the 5 digits for Yonkers New York (edited because I originally had NYC)
Nobody sends packages where the destination is an entire city. If someone gives me an address inside Yonkers, it'll have the zip code in the address. I've never had to look up a zip code in my life.
> For the same reasons, that's why it would be: Beverly Hills, Los Angelos County, California, USA, 90210
Which reasons? That has nothing to do with magic numbers, except that a 'magic full mailing address' is still bad, you don't shove that into the middle of your code either. If you're looking at the "made a typo" reason then that's where showing the address after putting in the zip code will give you the same verification but faster.
Is that information supposed to change my mind about something?
If you put in any of those numbers it can prefill the city name, with enough accuracy that you don't need to change it.
Did I imply anywhere that cities only have one zip code before you asked about Yonkers? I said if you can remember your city name you can remember your zip code. That doesn't imply you would use a list to get from one to the other.
I picked up the implication that you thought my response could be improved, so I tried to guess what your criticism was and respond to that. If it feels "way off" because I framed it as disagreement, then I dunno, that feels like the right framing? Unless it's something else I did? I could have made it clearer I was guessing but that doesn't seem way off.
Your zip plus 4 changes. It isn't worth trying to know as it isn't supposed to be constlnt. If you send a lot of mail there is a discount for using it but you have to update everyone's address often (iirt at least 4x per year)
Source? The numbers correspond to the USPS distribution centers and carrier routes. If the numbers are changing that would imply an increase in zip code subdivisions, making each zip code a better address predictor for a given individual.
This is a bad hill to die on for a ux conversation. "10% can feel kind a big number when 100% is huge" is a funny argument, as is trying to be pedantic about "nobody knows" as a shortcut for "most people won't know and you can't rely on any particular user knowing". If 10% is big enough to matter I can't wait to tell you about 90%!
I'm not suggesting that one would design for the 10%, but I also think that writing off 10% - "nobody" - (particularly of a large number of people) is pretty dumb too.
Yeah, anyone who has had to work with USPS bar codes should know that internally these are called routing codes, and they come in 5, 9 and even 11 digit variants. The 11-digit one narrows down to a specific delivery point, but even that isn’t enough to derive an address (just enough to know whether you’re looking at the right one or not). Zip+4 codes also change frequently because they aren’t based on locations but on delivery routes and sequencing.
> Zip+4 codes also change frequently because they aren’t based on locations but on delivery routes and sequencing.
This was news for me. I know the few zip+4 I memorize never change.
I think the source for the parent is AI slop. See [1].
> Due to an increase in population or to the improve postal operations, the US Postal Service® will occasionally add a new ZIP Code or change ZIP Code boundaries.
The census bureau (very) periodically publishes zip code data (which is where some places get their geolocation info). If you work with enough addresses you’ll find some zip+4s that are wildly far away from where they used to be. There are paid services that have better accuracy, but I’m not sure how they acquire their data.
Some people don't realize just how much you can "customize" deliverability with the post office, especially if you're big (like a school or large business) - you can have something that looks like your physical address, but is actually really a maildrop/PO Box at the nearby post office.
You can do relatively complex forwarding that would only appear to the end users if they can decode the barcode.
Zip isn't uniformly distributed numbers though so you dont have the equivalent of that many digits of decimal numbers. Other comments have more detail but just for the top level example the first number is the zone and goes from 0 on the east coast to 9 on the west.
Only if there's never more than 10,000 addresses in a single zip code, which means that if you enforce that, you can force a zip code to appear by building enough house
I think my point is that if you're going to make people learn a 9-digit identifier for their house you might as well make that identifier unique and then that's the only information they need to fill in. Having non-unique 9-digit identifiers feels wasteful.
Make that 1003+ times. At least in my part of the US, even a pretty modest-size city will have multiple zip codes. And zip codes can have zero geographical footprint (meaning street address) - for example, some zip's are just for Post Office Boxes. And a physical address can have an official USPS address & zip of "Middle City", while physically being in (say) Middle Township. And other fun stuff.
I've implemented it, too, and didn't run into any problems. User inputs the zip code, if there's multiple city matches, they select the correct one from the drop-down (or you auto-complete the city name after they type the first 4 letters).
The fact that "A city can also exist in multiple zip codes. And there can be multiple cities with the same name in the same state" is a good point IN FAVOR of asking for the zip code first (NOT to avoid it) because you certainly can't do it the other way round.
And if you just leave it to the user to free-type all that info in, you have to verify it after... Users are going to make typos, and the USPS will kick your butt if you don't correct it (and credit card payments won't go through, either). So it may be less work for web-form creators, but pushing the verification down stream just makes it all worse for the company using it.
The postcode doesn't tell the whole story. But what you can do is use an IP geolocation service which should narrow down your location enough, so that typing in the entire address is no longer necessary.
I.e. using something like https://ipinfo.io/json and then typing in a full postcode and street name + number should work well in most cases.
IP geolocation is increasingly not useful for anything, especially for mobile users. The best it can do is give you the correct country and maybe get you in the right region.
I work for IPinfo. Has our data been inconsistent for you? We actually invest heavily and continuously in data accuracy. I think for hosting IP addresses we are nearing the highest level of accuracy possible, especially with data center addresses. We are investing in novel, cutting-edge research for carrier IP geolocation.
I am curious about your experience with us so far.
That link nailed me perfectly. I'm on my phone. Connected to wifi, like most people probably are. Chilling in bed or on the toilet.
If you're on cell service.. yeah probably less accurate. Not sure if it makes the form harder to fill out if you have to change some of the fields.
What I've started doing for my personal app though is I've added a "guess" button. It fills in the form using heuristics but it's opt in. Fills out like 10 fields automatically and I've tuned it so it's usually right, and when it isn't correcting a few is still quicker.
I work for IPinfo. The accuracy you see is inferred data actually. Our IP address location should not perfectly pinpoint anyone, unless that IP address is a data center of some sort. The highest accuracy for a non-data center IP address is usually at the ZIP code level. In terms of carrier IP addresses, currently we do one data update per day. If we did more, I guess the accuracy of mobile IP addresses would improve, but on an overall scale, it would be quite miniscule.
Our country-level data (which is free) is 10-15 times larger than the free/paid country-level data out there. We constantly hear that the size of the database is an issue. The size is a consequence of accuracy in the first place. So, it is a balancing act.
What if I order something on the road and want it delivered to my home? Or what if I want to order something over mobile? My mobile IP is often 1500km away from where I live.
Autofill solves all of that with an implementation cost that approaches zero.
It means that if we cut off or discourage immigration, we can’t count on non-native citizens to continue boosting our numbers. So, we have to look at the native-born stats to get an idea of our future.
In a bear market in a bloated company, maybe. We’re still actively hiring at my startup, even with going all-in on AI across the company. My PM is currently shipping major features (with my review) faster and with higher-quality code than any engineer did last year.
It’s hard to compare, honestly. Last year, my PM didn’t have the AI tools to do any of this, and engineers were spread thin. Now, the PM (with a specialized Claude Code environment) has the enthusiasm of a new software engineer and the product instincts of a senior PM.
This is how it will go at least in the near term. Engineers will be phased out slowly by product/project management that will prompt the tool instead of the tech lead for the changes they want.
And in the longer term those people will also get deprecated.
Then any company that was staffed at levels needed prior to the arrival of current-level LLM coding assistants is bloated.
If the company was person-hour starved before, a significant amount of that demand is being satisfied by LLMs now.
It all depends on where the company is in the arc of its technology and business development, and where it was when powerful coding agents became viable.
The issue is the onus is on the contractor to prove that Anthropic technology has not tainted US government contracted projects - this is a herculean task verging on impossible. Additionally, most contracts will mandate SLAs around removing BOM risks.
If you were a contractor to DoD (no way I'm calling them DoW) would you take the risk of doing business with a company that has been labeled a supply chain risk by your main customer?
That last benchmark seemed like an impressive leg up against Opus until I saw the sneaky footnote that it was actually a Sonnet result. Why even include it then, other than hoping people don't notice?
This is my own proposal, based on my own experience in helping guide a startup through adoption of Claude Code across all roles. Right now, Claude does very little to encourage safe secret handling, which seems like a significant miss. Most engineers know how to mitigate risks of secret exposure (or avoid giving Claude secrets at all via proxies and such), but non-engineers simply don't have that learned skillset.
Of course, none of this prevents Claude from running scripts that read and expose secret values at runtime. However, with LLMs building and testing so much software, this is one proposed piece to help reduce some vectors of exposure.
[Note: my submission was written with assistance from Claude.]
You will probably never actually be able to create actual Claude chats from OpenAI chats, but you could ask Claude to read and distill your old OpenAI chats into Claude chat context. It won’t be the same, but it’s better than nothing, depending on what you’re hoping to get out of it.
Considering they trained their model on open-source software, the least they could do is give it to open-source maintainers for free with no time limit. I’m sure they can come up with other ways to prevent abuse. This 6-months-free move just adds insult to injury, like it’s just a move to extract more from those who involuntarily contributed to the training already. And that’s coming from me, a Claude Code fan.
The double standards are so obnoxious. Corporations bent over backwards to lobby intellectual property into law, then they invent AI and suddenly everything turns into fair use.
> Considering they trained their model on open-source software, the least they could do is give it to open-source maintainers for free with no time limit.
Why? The resulting code generated by Claude is unfit for training, so any work product produced after the start of the subsidized program should be ignored.
Therefore it makes sense to charge them for the service after 6 months, no? Heh.
What do you mean it's unfit for training? It's a form of reinforcement learning; the end result has been selected based on whether it actually solved the need.
You need to be careful of the amount of reinforcement learning vs continued pretraining you do, but they already do plenty of other forms of reinforcement learning, I'm sure they have it dialed in.
reply