Sorry, couldn't resist... :)

Jokes aside, I am seriously pissed at Nissan because it was one of reasons I bought it in the first place: to pre-heat or pre-cool the car remotely before going to work, while it is still plugged to the wall charger. And they just decided to take it down. Funny thing, they even mentioned in the email that "not to worry, I can still use my AC when I am in the car". Wow.

Sorry, rant. Anyway, my point being - buy Nissan Leaf, no connectivity guaranteed by the manufacturer, LOL.

It might have started in an innocent way, all those A/B tests about call-to-action button color, etc. But it became a full scale race between products and product managers (Whose landing page is best at converting users?, etc.) and somewhere in this race we just lost the sense of why UX exists. Product success is measured in conversion rates, net promoter score, bounce rates, etc. (all pretty much short-term metrics, by the way), and are optimized with disregard to the end-user experience. I mean, what was originally meant by UX. It is now completely turned on its head.

Like I said, I wonder if there is way back of if we are stuck in the rat race. The question is how to quit it.

Like, who knew this is even a character: ᆚ

Comments URL: https://news.ycombinator.com/item?id=47511304

Points: 4

# Comments: 0

Yes, I tried YouTube iOS app recently, without an ad blocker. It pretty much describes the experience.

It's like role-playing a story of software developer in the era AI, but accelerated. The results are truly good and fast. Coding fun zero. The new fun is prompt/context engineering.

You are a JavaScript developer. On this page you are presented with a coding challenge to solve: an elevator to program in JavaScript. Analyze the page, take a screenshot to understand the floor and elevator layout (how many floors, how many elevators), see the sample code in the solution text box and replace it with your solution for the challenge. Keep the solution simple, just sophisticated enough to solve the task at hand, do not over-engineer or optimize, not unless your initial solution fails. After you insert the solution into the text box, click the "Start" button to test it. After a time limit set for a solution (it is indicated on a page), verify if the solution worked: read page or take screenshot. If it didn't work, try a new better solution. If it worked, you task is complete. See the API documentation here: https://play.elevatorsaga.com/documentation.html#docs .

[1] https://opencode.ai/

I don't *yet* subscribe to the idea of "code is context for AI, not an interface for a human", but I have to admit that the idea sounds feasible. I have many examples of small-to-mid size apps (local use only) where I pretty much didn't even look at the code beyond checking that it doesn't do anything finicky. There, the code doesn't mater because I know that I can always regenerate it from my specs, POC-s, etc. I agree that the paradigm changes completely if you look at code as something temporary that can be thrown away and re-created when the specification changes. I don't know where this leads to and if this is good or not for our industry, but the fact is - it is feasible.

I would never use this paradigm for anything related to production, though. Nope. Never. Not in the foreseeable future anyway.

> Everyone uses their own IDE, prompting style, and workflow.

In my experience with recent models this is still not a good idea: it quickly leads to messy code where neither AI nor human can do anything anymore. Consistency is key. (And abstractions/layers/isolation everywhere, as usual).

IDE - of course. But, at the very least, I would suggest using the same foundation model across the code base, .agent/ dirs with plenty of project documents, reusable prompts, etc.

--

P.S. Still not sure what does the 10AM rule bring, though...

Essentially the models are given a set of conflicting constraints with some relative importance (ethics>KPIs), a pressure to follow the latter and not the former, and then models are observed at how good they follow the instructions to prioritize based on importance. I wonder if the results would be comparable if we replace ehtics+KPIs by any comparable pair and create a pressure on the model.

In practical real-life scenarios this study is very interesting and applicable! At the same time it is important to keep in mind that it anthropomorphizes the models that technically don't interpret the ethical constraints the same was as this is assumed by most readers.