anself · HackerTrans

hace 7 horasdiscuss

I agree, don't pre-emptively put too much control over your agents. But they do need guidelines and guardrails. All of the constraints I've added on my agents, I've added because when I let them cook, they went down the wrong path. Examples:

* Don't do ad-hoc fixes. Don't mutate the production data just to fix an issue. Fix the bug, ingest the bad data in code if necessary, or write a migration/repair script that an ops agent can run. * Write infrastructure as code, don't rely on remembering complex manual workflows. * Make sure there's a single model in the app with a single source of truth. Don't let truth get spread out across representations, it will get out of sync and bugs will result. Derived truths can be projected from the single truth, but they must update when the truth updates. * Write all logic in the application server, and send only a minimal visible payload to the web client. No calculations, except those needed for rendering the view, should happen in the client.

It goes on. These are all driven from the model making mistakes and having to have it go back and refactor to correct them.

anself

hace 9 mesesdiscuss

Pessimists are going to read this and call BS

anself

hace 10 mesesdiscuss

The 100m / 10k analogy is fantastic, but the reality is even worse. Let’s say you expect a candidate to stay for average five years. That’s about 1200 working days. If you get to interview them for 1 day, then that day is 8.3m to the 10k. You get to watch them run for 8.3m and decide how well they can run the 10k.

anself

hace 10 mesesdiscuss

Came here to say this! So many ways to parse it. But the key issue was not knowing that “pregnancy-test frogs” was the central concept. Without that, the headline is so confusing… at some point I had to consider whether “frogs” was being used as a verb

anself

el año pasadodiscuss

Too much developers relying on bloatware, not enough “implement it yourself” because in reality every hash map doves a unique problem that a Palin hash map is not necessarily suited for. Embrace NIH

anself

el año pasadodiscuss

You need at least one or two somewhat disagreeable folks in a team. Because without this, groupthink emerges, teams have too much inertia, they follow the assumed norm instead of challenging it for something better, they don’t debate the options enough. That disagreeable energy, in the right dose, leads to better decisions. If you don’t have it naturally, you can encourage someone to “play devil’s advocate” in decision discussions (or do it yourself) and you’ll find sometimes the devil’s advocate is actually right.

anself

el año pasadodiscuss

Agree - but The Goal (Eliyahu Goldratt) is a rare exception to this. It’s written as a novel but actually contains valuable and counterintuitive lessons about optimizing for efficiency in a complex delivery process. Worth every page

anself

el año pasadodiscuss

Agree, it's not testing. The problem is here: "In a typical testing workflow, you write some basic tests to check the core functionality. When a bug inevitably shows up—usually after deployment—you go back and add more tests to cover it. This process is reactive, time-consuming, and frankly, a bit tedious."

This is exactly the problem that TDD solves. One of the most compelling reasons for test-first is because "Running the code in your head" does not actually work well in practice, leading to the above-cited issues. This is just another variant of "Running the code in your head" except an LLM is doing it. Strong TDD practices (don't write any code without a test to support it) will close those gaps. It may feel tedious at first but the safety it creates will leave you never wanting to go back.

Where this could be safe and useful: Find gaps in the test-set. Places where the code was never written because there wasn't a test to drive it out. This is one of the hardest parts of TDD, and where LLMs could really help.

anself

el año pasadodiscuss

I don’t think there’s zero demand recommendation apps, a lot of founders choose this because it’s a problem they want to solve for themselves, and there are a few success stories out there. It’s just that it’s a super-hard problem

anself

el año pasadodiscuss

Is there a way to consume this in text instead? Video is far too slow and cumbersome and requires headphones

anself

el año pasadodiscuss

Having worked in banking for many years (no longer), I can say with confidence, the big banks have a giant moat: regulation.

They want to be heavily regulated so that new upstart competitors will not come in and spoil their cozy space. And it’s easy to justify because terrorism, money laundering, insider trading, etc etc. And many of these regulations are largely ineffective and easily worked around, whilst costing billions to the banks to comply with. Hence the moat.

We won’t get banking disruption until there’s banking deregulation.

anself

hace 2 añosdiscuss

Aren’t “utterly toxic” and “scammer” kinda the same thing? The only difference is the intention, and does that really matter?

anself

hace 2 añosdiscuss

Where did the wastewater go before the first rodwell was finished?

comments