[deleted]
Control the Ideas, Not the Code
171–180 of 208 posts
Re: Control the Ideas, Not the Code
#172It's kind of ironic reading a post with such bad grammar written by someone that seems to be so pro-AI
You realize he's not a native English speaker, right? His English grammar is better than my Italian, so I don't feel the need to criticize.
There's a difference between criticizing and saying, "I'm sorry, I don't understand what you are trying to say."
Re: Control the Ideas, Not the Code
#173Earlier quoted context omitted.
This is pretty unfair. If the author didn't establish some context there would be someone else here saying "Check out this dilettante telling me what to think." I have a degree in mathematics followed by twenty years in software development (pillory me, if you like). My conclusions after 6 months of using LLMs every day are remarkably similar to the author's. I increasingly think in shapes, architectures, data struct…
I bet you had to solve math equations and prove math stuff to get your degree, am I right? Now imagine I tell you that you could have just prompted LLMs with “please solve the is and make no mistakes”, would you think you’d be able to get your math degree? The point I’m trying to make is that it’s very easy to tell everyone “don’t read the code, just focus on architecture” when you have decades of experience behind y…
I see it. I'm with you. It does feel lonely though, doesn't it?
Re: Control the Ideas, Not the Code
#174This will be true because LLMs will increasingly generate better code faster and will outpace your patience to read the code while being entice to move forward faster because of partial trust. Like an engineer that you direct to do things, you as a technical manager can only review so much. It will drift till we are just asking it to review and give you a overview for you to review.
Everyone's a prophet now
Re: Control the Ideas, Not the Code
#175I think this blog post could use a disclaimer that Redis has AI offerings and would like to expand in the vector database market. The fact that the author addresses the young makes me feel uncomfortable. Gen-Z knows that currently almost all blog posts have an ulterior motive and are worded in a way that claims to be in their best interests. Do not listen to well-known programmers who use their non-AI earned fame to…
You're right. It's disappointing to see an established name, which I used to respect as a voice of an experienced programmer, pivoted to a different field and purpose. There's no substance or personality there anymore, only a kind of indirect marketing for how to drive an overhyped code-generation service provided by a corporation.
From out of the ruins other voices of reason, talent and expertise will surely emerge, but it will be difficult to find and listen amidst the public pollution and industrial megaphone drowning them out. The mainstream culture has been enshittified, and healthy creative subcultures have yet to grow into their stride.
Re: Control the Ideas, Not the Code
#176Earlier quoted context omitted.
Reaching the correct outcome is easy. That’s what happy path means. The time sink is all the error cases, ensuring that one of the transition in the system does not result in an unsatisfactory outcome. That’s why we read code. Because only there the correct and incorrect cases are clearly separated.
But that's just more data. Create the error conditions in your test harness and exercise them. The machine will tell you what happened. Then correct the machine.
You make it sound so easy. Have you ever worked in QA?
Re: Control the Ideas, Not the Code
#177[dead]
Re: Control the Ideas, Not the Code
#178Earlier quoted context omitted.
I bet you had to solve math equations and prove math stuff to get your degree, am I right? Now imagine I tell you that you could have just prompted LLMs with “please solve the is and make no mistakes”, would you think you’d be able to get your math degree? The point I’m trying to make is that it’s very easy to tell everyone “don’t read the code, just focus on architecture” when you have decades of experience behind y…
I see it. I'm with you. It does feel lonely though, doesn't it?
You made my evening a bit better by your message, kind stranger. It is lonely in there, but I suspect you know, just like me, that we can't chose a different path.
Re: Control the Ideas, Not the Code
#179Very 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…
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…
> 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.
Re: Control the Ideas, Not the Code
#180[dead]