This is a very important point.

AI makes different types of mistakes to humans. They're harder for us to see because we're not expecting them.

which is more likely when they start vibe-coding grid managers

What about when you work at Anthropic?

Yes but now it gives slackers a way to imitate and inundate the builders.

The problem is that everyone has a different opinion. If you let a single user drive the design then that single user might love it, but everyone else will hate it.

Bespoke designs are often really terrible. Have you ever shopped for a house?

You know immediately when the previous owner had their stupid whims indulged by contractors with dollar-signs in their eyes. The house is ugly, non-functional and is not going to get the sellers price.

The next owner will undo nearly all of the work, and the contractor will cash in on both ends.

As engineers, we like to think we're the contractor in this scenario. But it's actually just an LLM.

I've been in a similar situation as the GP. 15 years ago my first job after college was at a large Fortune 500 building LOB apps. The company was full of departments that were run entirely out of a massive Excel spreadsheet (hundreds of MB or more), or better yet a totally custom thing built on Access97 and VB made by a guy who retired 10 years ago. More than a few of the people in these departments had been in the same job for 20+ years and literally done the job the same way the whole time. Our mandate was not to modernize their business processes or make them friendly to automation, it was literally to indulge their stupid whims. But at least at the end they would be on an app where IT had access to the source code, could ensure databases were backed up, etc.

Sure, but these are small departmental apps, 20 users or less in most cases. It’s not like everyone is using every app. The alternatives at this scale are far worse.

If he's using AI to write that documentation (like everyone else) he'll soon find out why that doesn't work out in the end.

Our reduced attention spans are just adaptation to a world filled with meaningless distractions.

Imagine how crippled you would be if you felt compelled to follow every comment thread to its end.

We're just monkeys looking for the good bits among a pile of rotten fruit.

If your product needs a tour your product is badly designed.

Imagine you walked into a convenience store and the owner was like "Hey you need to take the tour first!"

I chuckled cause the convenience/grocery store is laid out to make us find the high margin items and not what we need. They can't explain it to us otherwise we'd shop less.

The best UI is no UI at all.

I can't think of a single time I've looked at a product tour and thought "well, I'm really glad they told me that, I never would have figured that out.

What the product tour I think often misses is that people don't want to learn your entire tool at one time.

They came to do one thing, that one thing needs to be brain dead simple.

Over time, you can show people what else they can do. But a product tour isn't the way to do that.

I think progressive UIs where you expose more and more to the user over time is the way to go.

If you're thinking "but I have so many features and capabilities this person needs" you probably haven't identified what the one thing people are paying you for is.

Isn't that exactly what IKEA does?

That sucks too

UI is like a joke. If it needs explaining, it's bad.

I don't know how you make even the simplest UI, unless it's a carbon copy of an existing one, then.

That's why I like startup tips.

"Did you know that in California all gas stations are required to provide you with free air and water for your car?"

I'd argue this is only true for B2C

Imagine you'd never visited a convenience store. You might ask the clerk for something, or you might just pick up something and walk out.

It's a double-edged sword. Two million lines is a major feat. It's also represents a significant maintenance burden.

The advantages to Haskell are theoretically obvious. The downsides are harder to intuit.

The temptation is to model _everything_ as types. The codebase itseld becomes a _business specification_, not an application. Every policy change is a major refactor (some of which are shockingly high-touch thanks to Haskell safety).

The lesson is you cannot have your cake and eat it too. Eventually you become trapped by your types.

Haskell is really impressive and powerful, perhaps especially at this scale. However it brings its own unique problems. The temptation to model business logic as types leads to rigid structures. And the safety these structures bring can blind you to other classes of risk.

You can do a great job of navigating that as long as you have some experienced engineers with taste building the core pieces. You can't have it all, but you can have a lot.

I interned at Jane Street years ago and they seemed to do a great job of walking that line (in OCaml rather than Haskell, but same difference). They moved remarkably quickly despite working in an area with a lot of inherent complexity and where reliability and correctness are an existential concern to the business. (Which, perhaps surprisingly, is massively more the case for a trading firm than for a Mercury-like neobank...) In hindsight, a key thing Jane Street did was hire some experienced OCaml programmers with great taste (like Stephen Weeks, the author of MLton) and let them build the core libraries and guide the whole codebase from the beginning.

Unfortunately, this is one of the things that Mercury didn't do anywhere near as well.

Any particular stories illustrating that that you can share?

Typescript too: https://www.richard-towers.com/2023/03/11/typescripting-the-...

Tbvh the biggest downside of a Turing complete type system is that you can theoretically implement an application that compiles to dust.

In practice this just doesn't happen because you've composed a bunch of pure functions with various branches within them.

You lose the ability to log "why" some effect is happening.

Eh sure. But you can always collect/carry decisions in something like an Either. When using arrows or your own monadic bindings it is even possible to abstract this away from view.