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

LLMs learned to speak by reading novels which have to use many adjectives and impactful vocab to help set the scene without visual support. So no wonder we ended up with this quirk showing up. I wonder if the researchers in the lab thought this was normal because they also write like this


Code reviews dont scale, inherently bottlenecked by how fast you can read code + cognitive capacity. But there are ways to make it easy to make sure PRs dont break prod and keep the quality stable: linters with best practices + company specific coding guidelines, dev environments per PR, comprehensive e2e tests that verify both correctness and performance. Not so easy to setup, but benefits are worth it.

Im working on karinja.ai which I lets teammates share live agent sessions backed by cloud sandboxes, that way you can centralized your agent config within a team so that the output is consistent and results can be previewed without even leaving your browser.


Is there a public test to check the performance of various captchas vs yours to verify the claims?

Ps. In mobile its possible to accidentally zoom out of the website, width is not limited to screen size.


This is pretty cool, didnt even know of half the options under well-known urls. Thanks!


I was about to write what advantage it has over linters but then saw the built on section. Good work. We use megalinter with our flavour of go and vite rules, plus extensive e2e testing after each agent run. Quality of the spec driven agentic PRs are significantly better than the baseline. Megalinter is quite resource heavy and slow, so will definitely check this out


Thank you, really appreciate. Feel free to create issue if you have any


Love it! I think the minimal approach you took is the right path forward. As others mentioned, small harnesses make it possible to run many agents in parallel and in small cloud instances. working on a minimal agent in Go myself for this use case.


I'm betting my startup on it. The subsidised model subscription will start to dry out and providers will lean heavier into locking down how they want their models to be used (Anhropic has been paving the way already). The only way forward is open weight models. If you are working on any LLM powered product be careful betting on utilising user subscriptions.


Maybe you know something I don't, but it seems the standard will continue to be a large number of companies hosting and reselling LLMs as both subscription plans and pay-as-you-go. It's virtually identical to the mobile market: the economics of the business require a large regular infusion of cash, and limits are used to prevent a minority of users from making the service unusable/unprofitable. A few giants are the most expensive but offer the most features, and cheap providers offer less for less. All of this will happen because people constantly want "more": more bandwidth, more quality, etc. Capitalism rewards this constant growth/advancement with constantly increasing bills.

Anthropic is going to go out of business by probably Q1 2027 due to not paying their bills. OpenAI will become a new Oracle, serving a luxury product for enterprises and governments. Google and Microsoft will keep doing what Google and Microsoft do. Chinese vendors will capture a significant amount of business over the next 10 years by running the models in non-Chinese DCs, with demand coming from their much lower prices. 95% of regular users will be paying for open model subscriptions, even if their local machine can run the model, because the providers will be offering features that are hard to impossible to replicate locally.


What is your startup?


S3 lifecycle policies and scheduled RDBMS jobs are the low hanging fruit here.

I used to work at a data platform team and built a cleaning service that used tags and object hierarchy trees to find and clean old PII data. Not an easy thing to do as our data analytics bucket had over 7PiB of data.

Overall the architecture was based of 3 components: detector, enforcer, cleaner. Detector sifted through the datalake to find PII datasets(llm based), enforcer tracked down ETL of the datasets in our VCS to set appropriate tags/metada(custom coding agent), finally cleaner used search to find and clean the data based on the metadata.


I'm curious about how the LLM-based detector worked. How often did you run into a false positive? (I'm assuming you leaned on the more sensitive side due to the importance of the data)


nice work! I built a similar system at my previous company. It was built on top of github. agent was triggered by the created issue, run in actions, save state in PR as hidden markdown.

It worked great but time to first token was slow and multi repo PRs took very long to create (30+ mins)

Now im working on my standalone implementation for cloud native agents


Why was the time to first token slow? Was it because of the spin up time for containers? That was an issue for us when we were running on Google's Cloud Run. We switched to Blaxel and it's much faster now. The hibernate feature has been great for comment iteration.


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

Search: