theZilber

I agree with what is said. When we lean into agents and want to use them for productivity, we need to accept the fact we will not fundamentally understand the code as we have designed and written it, otherwise might as well write the code ourselves. We already used to ship code with different levels of quality and technical debt to production before ai and developed a taste for what is "good enough" depending on the requirements, our long term workflow (how we close technical debt, and handle bugs), and our own personal capabilities. AI gives us more hands in the process and allows us to do more with less time, and less low level understanding. We should still question the code, and get our hands dirty in some sections, slow down and write ourselves small testing environments and chunks of code to get fundamental understanding of code which is critical. Otherwise we should just ship and forget and handle tech debt and "understanding debt" only when relevant. A lot of production code delivered pre ai already had tech debt that even the devs were not aware of, and yet a lot of it never fails and gets the job done, probably will be replaced in the future as those features become obsolete. Just because ai can surface those kinds of issues better does not mean straight away those have to be addressed meticulously.

The same way we do not understand already what the compiler does and how the code we have written runs against the machine, it's ok to delegate some of the lower level of understanding to AI, as long as the process produces the required results.

Different projects will have different sections where tech debt and code understanding debt are more critical, and we should with time acquire the intuition to know where we should rely more, and where we should rely less on ai to fill in the gaps.

I explained them politely what was the issue, and the differences in behavior which led me to conclude why it is a bug and not a feature.

Skipping back twenty minutes in time is not a feature. The reason it was skipping in the first place was because it would use a stale param on videos opened from youtube history.

Thank you everyone for the reads and the replies. I want to clarify a few things.

- the main reason i consider it a bug is because there is a difference of behavior between reopening the tab, and clicking from the history on the video. Videos get loaded with two timestamps, one in the url and one through some information received from the server, if it was a feature, the two timestamps should have been the same. The other issue is it was not the case before that if you would load a video from YouTube history, it would only load a timestamp at the js level without having a url timestamp, the url timestamp is especially annoying because it creates problems when you reopen a video from history, watch for a while, pause, and starting watching again much later - it will send you way back to the point where you started rewatching the first time. (It is confusing so read this carefully)

The combination of switching the behavior to loading two timestamps, the two timestamps being different, and as a result of a switch I could be sent back in time for huge chucks of the video (ie 20 minutes, not seconds) just because i paused for a long time on a video i loaded from history, created a set of issues which can not be justified together.

And seeing here, there is at least one person like me, who watches long form content, had the same issue.

What happens when you press ctrl+o? You get verbose mode?

I really liked the styling on the website. The concept itself is interesting, something about opening journal entries has a calming effect. Making it login only is a bit off-putting.

Hey, you might want to experiment with local sync approach by allowing devices to sync when are on the same network. I have never done this so there might be hurdles, but this can bypass the issues with cloud sync while maintaining the ability to sync across devices

No surprise there. Good thing some officials try and do something about it.

Sheesh, talk about "taking a break"...

I for sure approve this creative way to test things

I recommend you to show an example and a result for people to understand exactly what the tool does. As far as i know "merging images" is not a common term with a specific meaning.

Tbh, to keep my ego in check, whenever i get rejected ghosted, or whatever, I just assume the company/interviewer is doing a perfect job for screening for the kind of candidates they want and need, and if I don't pass it means "there wasn't a fit", tbh if we were totally honest with myself, I don't fit well into most corporate cultures, and I should not care if they ask me questions I did not care enough to answer well in the first place.

A highschool performance question is not odd. It is meant to filter me out - that is perfect, because why would I want to waste my time on an interview in a company with this mentality, in the first place?

The article's headline is great and it delivers the message clearly. But the whole premise to support the message is very assumptive - "there is no moat". There is a lot moat in cursor, bolt, lovable. The same way there is moat in the chat apps of openai, anthropic, gemini...

They say there is no moat, but in fact, a feature in anthropic takes a good few months up to a year to appear on openai chatapp, and the same is true vice versa.

You could say some of those issues are solvable by allocating more money, and resources, which might be true, and it could be true that it would be beneficial for openai to develop their own cursor platform in the future, to get better margins. But in reality, who knows when that future would come? Maybe by then cursor will have much more moat and entering the market would be much more difficult. Maybe openai will continue developing their core product and entering other domains will not be worth the effort.

Currently, LLMs as a product have not been solved. All companies operate at a lose in order to rise the top, and we still don't know how it will be monetized in the future. But as it stands - there is already moat, moat in infrastructure - even though a few years ago they said that llms have no moat, now there is already a strong set of features and "agents" that deliver us the deep reasoning, online searching, and multimodal experience.

So, there is moat. But moat can accumulate over time. For the article to be true - it should prove the the current moat is low, and it can not accumulate.

It is less about performance issues of loading megabytes on the browser (which is also an issue). It is about those cases where a fetch request may take a noticable amount of time just because of server distance, maybe the server needs to perform some work (ssr) to create the page (sometimes from data fetched from an external api).

If you have a desktop app it will also have to do the same work by fetching all the data it needs from the server, and it might sometimes cache some of the data locally (like user profile etc...). This allows the developers to load the data on user intent(hover, and some other configurable logic) instead of when application is loaded(slow preload), or when the user clicks (slow response).

Even if the the target page is 1byte, the network latency alone makes things feel slugish. This allows low effort fast ui with good opinionated api.

One of the reasons I can identify svelte sites within 5 seconds of visiting a page, is because they preload on hover, and navigating between pages feels instant. This is great and fighting against it seems unreasonable.

But I agree that in other cases where megabytes of data needs to be fetched upon navigating, using these features will probably cause more harm then good, unless applied with additional intelligent logic (if these features allow such extension).

Edit: i addressed preloading, regarding pretending its a whole new set of issues which i am less experienced with. Making web apps became easier but unfortunately them having slow rendering times and other issues.. well is a case of unmitigated tech debt that comes from making web application building more accessible.