This 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.
Control the Ideas, Not the Code
151–160 of 208 posts
Re: Control the Ideas, Not the Code
#152I 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…
Totally agree. But I have the feeling damage has already been done, like full oop back then. To be precise I don't think oop was a total mistake, rather being maximalists about it was a mistake like with AI. I am so pessimist that I believe sooner or later we will testify the first death because of ai unreviewed code. I hope I'll be wrong
Re: Control the Ideas, Not the Code
#153Earlier quoted context omitted.
That's fair, I think my point is there's a nuanced theory behind my choice to be rude, which is essentially "you need to experiment more, be more open minded, really work at it, and then you'll see what others are seeing, it isn't impossible." It's like Dark Souls, nobody can beat it for you, or teach you how to use dodge rolls, you've gotta build that skill yourself, and blaming the tools won't help.
I think your attitude is pretty lazy. It's a low-effort answer to say "skill issue" and then walk away feeling superior. Much harder to lean in to the other person, understand them, then help guide them onto the path. When you do this, you cause them to accelerate tremendously. IMHO as you get more senior in software, after a while the only interesting metric becomes: are you raising the level of the people around yo…
> IMHO as you get more senior in software, after a while the only interesting metric becomes: are you raising the level of the people around you?
Strongly agree, especially given how helping your teammates scales geometrically rather than linearly like improving your own output. If you work on a team team of five people with roughly equal output, and each becomes 20% more productive because of improvements you make, your team's output is increased the same as if you doubled your own productivity without helping anyone else on your team. (The math doesn't work out the same if your teammates aren't as productive as you already, but that's just an another argument for why it's better in the long run to be someone who can enable those around them rather than someone who only helps themself; helping everyone else has compounding returns if you keep doing it!)
I personally just also find it more fulfilling to be someone who makes everyone else around me better rather than just trying to be better than anyone else, but I recognize that not everyone will be motivated by that, so sometimes framing it in terms of raw output can help. The other potentially strong argument for those who are a bit more motivated by their own experiences only is that it's usually a lot more fun to have smart productive coworkers than ones who make you scoff and say "skill issue" to!
Re: Control the Ideas, Not the Code
#154For some background on me to set the context for the following opinion: - been a SRE/DevOps at banks/hedge funds for almost 20 years - now work in L1 crypto - have been coding since I was 12 and have also been using frontier models for the past year (including running multiple agents at the same time etc). My thoughts: The models are indeed amazing. They can read large codebases, find bugs, infer the root cause of an…
You can have almost 100% tests coverage and green tests and still have a plane crash and LLMs shilling with you that everything is ok. To me it seems we havent learned yet tests coverage means nothing without solid code
Re: Control the Ideas, Not the Code
#155Very egocentric piece. Almost reads as “I’m so cool, I did so many cool things, and most things other people did is way worse than even the slop that my LLM prompting skills are capable to produce”. Also “ You have to understand how things work, what is the best design, how to reach a certain level of performance.” - how does OP propose to understand how things work or what is the best design if you don’t actually go…
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 structures and ideas; less and less in lines of code.
And I fully understand his point that, once the architecture of an idea is settled, reading LLM code does not feel worse than reading human generated code. Especially if you have a strong style and conventions guide.
The idea is the hard part, and it's the right place to focus your effort.
Re: Control the Ideas, Not the Code
#156I highly respect Antirez, and as an Italian fellow programmer, for me, he's like a legend! Although reading this article makes me quite sad; I consider myself an average, mediocre programmer, but I enjoy writing code since it's a way to build the mental model of a problem and to solve it iteratively. I obviously use agents and all the new fancy tools, but if a great programmer like Antirez says that it's over, I thin…
From another Italian fellow: stop following people and do your own thing, it will be worth it no matter what influencers says
Re: Control the Ideas, Not the Code
#157Ideas are a dime a dozen. All of us have half a dozen of what appear to be good ideas every. Execution matters, testing and sanity checking matters, actual engagement with users and iteration matters. Sure, we're reducing the cost of idea -> prototype to near zero (well, as long as tokens are free or nearly free), but that just means we now have mountains of throw away code, within which there may a gem or two. Nothi…
I think "idea" is getting overloaded here. The article isn't talking about new feature/product/tool ideas, but about what concepts to use to build those features. e.g. what data structures and algorithms to use. So your last line agrees with the article, I think. They are saying that it's still important to curate ideas, and no longer important to read the code; the time you would have spent reading the code should b…
I completely agree with this you. The article is NOT about product ideas. Your parent has misunderstood the article.
Re: Control the Ideas, Not the Code
#158> looking at the code itself is suboptimal and often pointless
yeah I was having a convo with AI about this recently
I was like, I recognize AI tools are useful, but I don't end up using them as much as I'd like to
and the conversation kind of went towards acknowledging how dramatic the shift has been from using search engines to get ideas about how to manually code, to just sharing ideas for other people to maybe implement in their own way using AI
So, there were all kinds of buzz phrases that popped up like about "prompts as source code" and "spec driven development" and "context engineering" which just kind of confirmed for me that I think some of my "slowdown" with coding with AI has been due to a shift from this manual coding with search engine assistance to sharing ideas and letting AI do the actual coding
Manual review akin to skimming while reading and then reading in depth specific passages that need "deeper focus" is probably something to consider keeping doing
Re: Control the Ideas, Not the Code
#159Do I have to look at the text of the article (words, letters, punctuation) to get to the ideas in it? Do ideas exist outside of the code where they are embedded? If the ideas live outside the code how confident can I be confident the code as written embodies the ideas? These are the things I keep thinking about.
Re: Control the Ideas, Not the Code
#160Very 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…
People who do this are no longer engineers in any real sense. They’ve switched careers to technical management.