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

It’s likely because the quick thought is that auth is just user table with hashed password.

Then when you really start thinking about it, the list of requirements grows.

Of course it’s still totally doable for an average developer, but takes time and mistakes can be catastrophic. And maybe the time is better spent developing stuff that differentiates you from others.


Kubernetes sounds like overkill, but I've been running microk8s for few standalone servers. This feels a pretty good match when working with agents. Codex can manage the cluster also over ssh, schedule new pods, check statuses, logs etc.

K3s is also pretty nice for a minimal setup

Haven't used it in a while but this thing is also interesting--it supports a bunch of different ways to spin up k8s https://github.com/tilt-dev/ctlptl


I think k8s is a great choice today specially when you can plug it into Gitlab and have a control plane for your clusters in the same place where your code lives.

”Engineers were actively encouraged to use tools like Claude Code and Cursor, even ranking them on internal leaderboards based on usage”

Token maxxing? Might explain high costs if you are actively encouraging developers to spend as much tokens as possible.


The good ol' measuring inputs, not outputs...

(Other inputs from days of yore: number of people that report to you, budget allocation to your team. Nothing new under the sun!)


Is there an xyz's law for this yet? Will add - lines of code (as long as you don't believe code is the product/output).


There's Goodhart's law: "When a measure becomes a target, it ceases to be a good measure."


There it is. Thanks!


I don’t think people want that, but they are willing to accept that in order to get stuff done.


Why not replace the SMTP with an API and explicit permissions. When registering for a newsletter, I would explicitly grant the sender right to push stuff to my inbox. At any point I could revoke this right and the sender would get clear error message when pushing.

Old fashioned person-to-person email would work as it does. This would only apply to the app-to-user stuff, which in my case makes up >99% of my emails.


Put proper LLM into Siri. Encourage developers to expose the functionality of their apps as functions, allow Siri LLM to access those (and sprinkle some magic security dust over it).

Boom, you have an agent in the phone capable of doing all the stuff you can do with the apps. Which means pretty much everything in our life.


Sometimes easy performance trick is to split the CTE to separate queries, put the results to unlogged temporary tables and add whatever indexes the next step needs.

Obviously makes only sense for stuff like analytical queries that are not running constantly.


Worth underlying the OLAP versus OLTP divide you are speaking to on the close, there.


An issue that has arise for me in some situations is that for more expensive/reporting queries we point to a db replica, where temporary tables are not an option.


Somebody took a deeper look at Claude Code and claims to find evidence of Anthropic's PaaS offering [1]. There's certainly money to be made by offering a nice platform where "citizen developers" can push their code.

From Astral the (fast) linter and type checker are pretty useful companions for agentic development.

[1] https://x.com/AprilNEA/status/2034209430158619084


I wouldn't be surprised if Vercel were bought by Anthropic/OAI (but maybe it would be too expensive?)


No no - SpaceX/xAi must now buy Vercel so that we can deploy our bloated Next apps to space.


Next now renamed to Xext.


At least in space there is lots of space and no heat /s - I'd love for Next to exist in a vacuum


Nothing is too expensive. It will be a bidding war.


Home scale example with strawberries: https://www.youtube.com/watch?v=8LIhx0yoM7s


A good solution for memory would help with stickiness. But it's a hard thing to crack.


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

Search: