anself

Most of these issues are vastly improved or mitigated by adding clear instructions in AGENTS.md.

I follow a specific process with agents, and it works reasonably well: 1) describe my intended feature or change and then say “please recapitulate my intention and write an implementation plan” 2) read the plan carefully and refine it, make any corrections 3) tell the agent to go, but I check in frequently as it’s going. I watch the stream of thought and make course corrections or pull it out of rabbit holes 4) carefully review the result. Checking that tests actually fail, removing unnecessary changes 5) add instructions in AGENTS.md if I’ve found a new behavior that needs redirection

It’s not actually less certain now than it was then. It’s just the media has gotten louder. Cuban missilie crisis, civil rights, world wars, nuclear weapons, it has all been happening for a while.

Who ever said coding is solved??

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.

Pessimists are going to read this and call BS

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.

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

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

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.

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

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.

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

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

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.

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

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