Very uncomfortable to read. The proposed idea of not reading the code you ostensibly wrote, doesn’t just challenge the traditional workflow or methodology, it challenges the identity of a programmer itself. For experienced, respected programmers like antirez perhaps reading and writing code truly has just gotten in the way of the ideas, but I cannot identify with that perspective. The devil is in the details, reading other peoples code (and code the LLM writes) evolves the idea itself, and changes my understanding of it. My view on this is so biased by the direct relation of code I read and write to feeding myself and my family (the vast majority of my programming is for a paycheck) that suggestions of removing myself from the process feel grim, not exciting.

▲

sibeliuss 6 hours ago | parent | next [-]

I'm fully on the agentic coding train and haven't manually typed code in a while so I understand the sentiment around moving beyond this level of analysis. However, how can this advice work practically speaking, day to day? Especially at ones day job?

I'm sitting here working and just caught a handful of really bad decisions by the agent, one right after the other, cascading from an assumption that was incorrect. My ideas and architecture are sound in this codebase! Are those things simply to remain in the code if they work 'good enough', or are there consequences right around the corner?

	▲	puglr an hour ago \| parent [-]
		> cascading from an assumption that was incorrect I have found including this in my AGENTS.md to be quite transformative in this regard: > Always use an aggressive red/green TDD-approach. It is critical to remember that in the red phase, things like module/exports import failures due to trying to import file paths that don't yet exist, exports that don't yet exist, etc. is not valid TDD. For valid TDD, the test cases must actually run. For this, you must create stubs of the expected modules and exports in the red phase, so that the test cases actually run and fail on the test case assertions themselves. In some cases, when using this approach, once in a while some of the red phase test cases might "incidentally" pass, and this is ok. Before running red phase tests you should always make predictions about the number of test cases you expect to fail/pass -- this count is not the number of test files or test suites, but rather the number of test cases. By performing these red phase expected counts of passing/failing test cases, it will help you catch errors in your prior reasoning quickly and efficiently. > Always use a proof-driven, scientific method-based approach to validate hypotheses, assumptions, and conclusions: define the smallest falsifiable hypothesis, create or identify a reproducible failing case, gather direct evidence, make the smallest targeted change, and then re-run the same proof to confirm the issue is fixed. Avoid speculative fixes, broad rewrites, or changing multiple variables at once. When possible, preserve the reproduction as a regression test before implementing the fix. Consider that when gathering evidence, additional logging and durable files can be very helpful. > The strict TDD and proof-driven approaches described above could be described as "proof-driven development". Try to internalize and generalize these concepts, as they are broadly applicable.

▲

wongarsu 7 hours ago | parent | prev | next [-]

For complex code changes or bigger features I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions, etc. It's not that you spend less time refining ideas, you just do it at another level of abstraction

But that does come with tradeoffs, and it's not the right thing for every project. But when it does work it does increase the amount of work you get out in the same time

▲

qsera 6 hours ago | parent | next [-]

>For complex code changes or bigger features I often spend hours with an LLM refining architecture

The problem here is that the LLM hallucinates, so

* it will tell that something is a bad idea, even when it is not. * it will miss good ideas.

But here is the thing. Even discussing with a rubber duck can do wonders to your thought process. So may people who are noticing the usefulness of this procedure might be actually just doing a slightly better rubber ducking...

	▲	wongarsu 5 hours ago \| parent [-]
		Yes, a better rubber duck is a decent description The LLM will often miss the most obvious simplifications. And if I ask it to present me with six approaches how we could solve a problem, chances are we will settle on number seven or eight, both my ideas after rejecting all the other six. But those first six were still valuable for coming up with the version we actually settle on. Making the rubber-duck talk is genuinely useful. And the rubber duck is actually pretty good at the localized grunt work, so you can spend more time talking with it about big-picture stuff

▲

cyphar 6 hours ago | parent | prev | next [-]

But the CPU is not executing the textual description of your architecture. It executes code.

Honestly, I've found that the architecture described to and by LLMs is always a more rosy picture than what is actually generated, no matter how many times you do an adversarial review. It's less visceral than in image generation, but the pattern is the same -- the broad strokes seem fine but the details are awful.

▲

skydhash 6 hours ago | parent | prev [-]

> I often spend hours with an LLM refining architecture, exploring alternate directions, trying to find alternate directions in the first place, clarifying design questions,

Is that something recent? I’ve been doing this for years, even in high school where we were asked essays on contrast between different viewpoints.

I don’t need LLM to do this. It’s the 101 of any engineering process to not rush with the first thought you have and indeed try to explicitly explore the solution space and base your decisions according to defined tradeoffs.

▲

archagon 3 hours ago | parent | prev [-]

People who do this are no longer engineers in any real sense. They’ve switched careers to technical management.