Hacker Newsnew | past | comments | ask | show | jobs | submit | sublimefire's commentslogin

Everyone is serious about it but the problem lies in capital markets and investment funds and the fact that Europe is not a single country (multiple languages, slight difference in some laws). Banks tend to be too conservative and local investment vehicles are much smaller compared to what you can get in US. You are pretty much free to do anything you want otherwise, eg recent defense startups. What is more ageing population does not help and puts “a bit” of strain on the taxation.

Very similar experience. As an example I had to user Naver and Kakao maps in Korea instead of Google and those apps gave me sort of another perspective that other apps can be better than G for sure. For youtube I have been fighting the addiction and eventually disabled all options around privacy and eventually reduced the use quite a bit as they do not render the feed of random videos and shorts anymore (just subs).

There are “a few odd” things here. It is not entirely clear if this is sort of a rage bait blog post as well. What looks to me they do not even care if you are good “engineer” rather look for prompters and then use their contributions to improve their own platform; many of us have automation templates for that which would be difficult to replicate. I am not even talking about the mention of JS to do that, like sure it is easier because your platform does not need to compile, but if they move huge amounts of money and JS is actually used for it, you’d expect someone to understand how VM interprets that code etc. IMO it is possible (such interview practice) purely because it is a tough job market now.

aren’t they stuck on an older version of ios with just security patches? but i sort of agree as my kids would have older versions which are all right


> margins shrink and become razor-thin

You need to understand that these models are provided by the corporate entities, they are expensive to maintain, iterate and run. There is still no strong correlation between the use of AI and the business outcomes so there should be a real ceiling to how much enterprises would pay for tokens. The gov is a usual choice to establish contracts and get some stability, similar to building nuclear reactors or military equipment. And posturing about limiting model access is just saying it is expensive to subsidise its use for cat image generation or call summaries.

I am pretty sure we have not found the killer app (like an IDE even) for us to extract all the possible value from the models yet. I would even go as far as to say that the synthesis between a human and AI could leverage average models to achieve a lot more compared to the model/agent working on its own.

edit: Just to add to this, I am going through Mythos scans and it is not perfect, very much similar to what pentesters would do with the added bloat of noise in reports about nonissues.


Surely we want impact to be seen in our lives and not after our funeral. In such a case it is easier to think about huge things in the first part of the career as attainable, but later in life you might have 15 years left for which you will optimize your chosen battle to be able to see it to fruition.


A mention of a “rewrite” triggered. Whoever does rewrites is effectively out of ideas on what to do next. This is an opportunity cost and the team/company chooses what is more important and the rewrite is never at the top. So even promising or expecting such a thing is silly.

IMO it is a bit arrogant to assume it is more important to engineer a better version of a thing rather than make money quicker and cut corners. In essence it is better to have a problem which is about how to scale a new product because it got traction rather than solve a problem how to sell more copies of already scalable thing.


I do "rewrites" for my day job all day every day; with as of late the goal being rewriting critical services to get past scaling plateaus.

Rewrites require an existential-level threat to pursue and should never be taken lightly. They must solve a real verifiable need, backed by real world data. Rewrites for rewrites sake or some lofty or nebulous goal of "better" or "more maintainable" code are doomed to fail and a waste resources.

I've seen the worst of it, from your average monoliths with no separation of concerns to 1000s of lines of self-modifying assembly in dead architectures with no code comments containing critical business logic, etc.

The main rule is to not to bite off more than you can chew, which if I'm being honest you really only learn from fucking up or watching others fuck it up.


They said a Proof of Concept goes to prod. That’s not “rewrite the whole service that’s been built for months”. That’s “I vomitted a neat thing over the weekend” -> now it’s in prod.

Hackathon and overnight oncall fixes ABSOLUTELY should be rewritten or production-hardened, but they very often are not.


A typical example would be the researchers which are evaluated based on papers and new stuff they put out into the wide blue world. But if you are on a product side this makes little sense because you need to match “features” to the requirements expressed by the customers and you will tell researchers to stop pushing.


Some people do not take no for an answer. This is bordering on absurd.

But on the other side what I miss is some explanation if forensic analysis helps here? Presumably the messages stay on a phone and you can recover them. If that is the case then it should be enough to fight the crime, i.e if you get a warrant to access the device then you can access messages, which I believe many would agree is fine.


One important part is not expanded on - incentives. If you really think about it that is the crux of the problem. If I am recognized for creating documents, PRs, features, decks, token use, and NOT for doc/PR/deck reviews or feedback or fixing features, then the outcome is what we see now.

An example of a new feature in the company goes the following way:

- some request is raised by person1

- PR is generated with an "agent" by person2

- PR is reviewed using an "agent" by person3

- feature is merged and shipped

- person1 is happy and records a video with a feature to be shown to the clients

- in a next call with the leadership this feature is declared as a success

It all looks good until you look at the implementation, not only that there is very little time to intervene. I find myself recently trying to quickly review PRs before they get quickly merged, just to be on a safe side as people do not even look at the code.


You already realised that you aren't paid to review code manually. Why waste the time? And maybe even get the wrath of your management by "wasting" time?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: