[AndrewKemendo]

This is precisely the future of consumer software engineering (no I’m not saying anything here about building robots rockets medicine etc. at least for the next decade probably)

This idea that software developer productivity being the goal for AI companies is just not it - every piece of code you put into an LLM is a you giving these giant companies your expertise

People need to remember where the bulk of engineering money goes: consumer advertising and consumer facing applications, and don’t forget most of them have tragically bad user experiences and dark patterns because they’re trying to make the software as a service model work for investors

if I can spend a week replicating your software that has all these bullshit dark pattern features and I can replicate that for my own why why wouldn’t I?

[bigblind]

I'm curious whether people feel like UX could at all be a differentiator here. like, sure, i can build a very quick crud app with Ai in an hour, but there are lots of UX decisions that, if not prompted in the right direction, AI just handles badly.

i guess the problem is that once a teamp goes through the process of figuring out good UX for a certain flow, which can take time, that UX then becomes trivial to copy.

[AndrewKemendo]

Every product reveals its design if you know how to interrogate it.

So knowing a software architecture for something you use is the HARDEST part to observe and the UX is the easiest to observe.

provided you can describe what you observe, and your desired workflow that matches your need, then you can replicate it provided you understand how to test and iterate, which again is trivial to learn.

Combine:

Observations of workflows to implement and

Notional data architecture

You can create a slimmed down version of pretty much anything.

I mean this is basically every image editor compared to Photoshop.

A designer that is used to all the features Photoshop has, and then you just use the most common workflows that most people use, to be the feature bootstrap for your Photoshop alternative that’s much lighter weight and cheaper etc.

[mattmanser]

It really isn't. No-one wants to maintain these things, they'll be back on an out-sourced provider within 5 years, if they survive that long.

[ale]

The devs doing these kinds projects no longer think of the code as maintainable, but disposable. It's quite the 180 for a community obsessed with reusable npm packages and not reinventing the wheel. Last year Cursor bragged about ditching their CMS in 3 days: https://x.com/leerob/status/1999513884382597485

[AndrewKemendo]

It’s not a 180

It’s measuring time to iterate/ship, cost reduction and independence, which is really all that matters

Reusable was great because it used to be the fastest. The fastest now is vibe/slop > iterate > iterate > iterate > ship > iterate > ship etc…

[AndrewKemendo]

Why maintain it?

Make a new one from scratch if needed.

[add-sub-mul-div]

> if I can spend a week replicating your software that has all these bullshit dark pattern features and I can replicate that for my own why why wouldn’t I?

Have fun Chesterton's fencing yourself into much of what other companies spent years learning and solving.

Prototypes and proofs of concept were easy even before AI.

[AndrewKemendo]

I’m well aware

Which is why you start from the principles that were “learned and solved” in the past.

Literally none of those things that you’re talking about Chestertons fence hopping are secrets or hidden

They’re very well documented in product design, project management, cybernetics, IT etc…

There’s been thousands and thousands of articles written about all the different ways to build: functional programming, monorepo vs micro services, strong typed, memsafe etc….

there’s infinite number of framework debates that are already embedded in the LLMs that you simply need to interrogate as part of the planning process before you ship anything

It’s actually really simple.

The reality is that 99% of software engineers never gave care about any of that ever. Go ask your average software engineer about Parness information hiding or Conway law inversions.

These things are trivially easy to grasp and make engineering intuitively simple to avoid MOST problems. I am consistently teaching principal engineers, VP, senior software engineers, people who know how to write code about basic basic basic information theory. It’s honestly embarrassing.