I think that generally creators being responsible for what they ship applies across the board. That doesn't change because AI has it's fingers in it.
Write less code, be more responsible
81–90 of 135 posts
Re: Write less code, be more responsible
#82I’m working as a single solo developer of a tiny video game. I’m writing it in C with raylib. No coding assistants, no agents, not even a language server. I only work on it for a few hours during the week. And it’s progressing at a reasonable pace that I’m happy with. I got cross-compilation from Linux to Windows going early on in a couple of hours. Wasn’t that hard. I’ve had to rework parts of the code as I’ve progr…
>I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less. This is what I've always found confusing as well about this push for AI. The act of typing isn't the hard part - its unde…
It always seemed to me like its lootbox behavior. Highly addictive for the dopamine hit you get.
Re: Write less code, be more responsible
#83Earlier quoted context omitted.
I've worked in two different types of environments - one where what you said is absolutely true (most of my jobs), and another where it's not true and the quote holds up. The difference, I think is: - Code factories where everything is moving fast - there's no time to think about how to simplify a problem, just gotta get it done. These companies tended to hire their way out of slowness, which led to more code, more c…
I think your mind might be blown when you discover a third type of environment. It's neither a small shop of yak-shaving idealists, nor a desperate code factory. The third environment is a large business maintaining services long term. These services do not change in fundamental ways for well over a decade and they make a shit ton of money, yet the requirements never stop changing in subtle ways for the clients. Bugs…
HN is a tough crowd for comments like these :) The absolute best work in our industry is this but people (especially younger people which is a shame) are chasing FAANGS is shit like that. I have been blessed (also it wasn't by accident but still blessed) to spend a lot of my career in exactly these kinds of places (minus the bugs popping up constantly :) ).
Re: Write less code, be more responsible
#84Earlier quoted context omitted.
Not only it can but it does. Just as I was reading this claude implemented a drag&drop of images out of SumatraPDF. I asked: > implement dragging out images; if we initiate drag action and the element under cursor is an image, allow dragging out the image and dropping on other applications then it didn't quite work: I'm testing it by trying to drop on a web application that accepts dropped images from file system but…
Why is it using a temp file? Is there really no more elegant way to pass around pointers to images than spilling to disk?
Of course there is, but slop generators be slopping
Re: Write less code, be more responsible
#85I’m working as a single solo developer of a tiny video game. I’m writing it in C with raylib. No coding assistants, no agents, not even a language server. I only work on it for a few hours during the week. And it’s progressing at a reasonable pace that I’m happy with. I got cross-compilation from Linux to Windows going early on in a couple of hours. Wasn’t that hard. I’ve had to rework parts of the code as I’ve progr…
> Writing the code hasn’t been the bottle neck to developing software for a long time.
For who? There's no lack of professional programmers who couldn't clear FizzBuzz now coding up company-sized systems using Agents. This is all good as long as agents can stick to the spec/req & code it all up with decent enough abstractions... as the professional approving it is in no position to clue it on code organization or bugs or edge cases. I think, we (as a society) are looking at something akin to "reproducibility crisis" (software full of Heisenbugs) as such "vibe coded" systems get widely sold & deployed, 'cause the "pros" who excel at this are also good at... selling.
Re: Write less code, be more responsible
#86Earlier quoted context omitted.
imo a question is, do you still need to understand the codebase? What if that process changes and the language you’re reading is a natural one instead of code?
What happens when your LLM of choice goes on an infinite loop failing to solve a problem? What happens when your LLM provider goes down during an incident? What happens when you have an incident on a distributed system so complex that no LLM can maintain a good enough understanding of the system as a whole in a single session to spot the problem? What happens when the LLM providers stop offering loss leader subscript…
AFAIK everything I use has timeouts, retries, and some way of throwing up its hands and turning things back to me.
I use several providers interchangeably.
I stay away from overly complex distributed systems and use the simplest thing possible.
I plan to wait for some guys in China to train a model on traces that I can run locally, benefitting from their national “diffusion” strategy and lack of access to bleeding-edge chips.
I’m not worried.
Re: Write less code, be more responsible
#87Yeah many newbies are thinking that all ai generated code is safe while they can poison the next gen ai by training on wrong data.
Re: Write less code, be more responsible
#88Earlier quoted context omitted.
imo a question is, do you still need to understand the codebase? What if that process changes and the language you’re reading is a natural one instead of code?
> What if that process changes and the language you’re reading is a natural one instead of code? Natural language is not a good way to specify computer systems. This is a lesson we seem doomed to forget again and again. It's the curse of our profession: nobody wants to learn anything if it gets in the way of the latest fad. There's already a historical problem in software engineering: the people asking for stuff use…
> But it seems we are introducing a whole new layer of lossy interpretation to the whole mess (...)
I recommend you get acquainted with LLMs and code assistants, because a few of your assertions are outright wrong. Take for example any of the mainstream spec-driven development frameworks. All they do is walk you through the SRS process using a set of system prompts to generate a set of documents featuring usecases, functional requirements, and refined tasks in the form of an actionable plan.
Then you feed that plan to a LLM assistant and your feature is implemented.
I seriously recommend you check it out. This process is far more structured and thought through than any feature work that your average SDE ever does.
Re: Write less code, be more responsible
#89Earlier quoted context omitted.
> The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down. I've been doing this for 30-years and this is another political slogan of sorts. this is true in every single imaginable job - new people slow you down, until they do not and become part of the well-oiled machine that is hopefully your team. not sure why people insist on saying th…
When people say code is the bottleneck, they don’t always mean the lack of code: it’s also the accumulation of code, which becomes like plaque clogging your arteries. When you have too many people pumping out too much code, it can be the death of your startup. Startups have failed from writing way too much code.
amazing how many comments in these discussion talk about startups as if that is all there's to it, you either are at startup or you are plumber... [mind blown...]
Re: Write less code, be more responsible
#90Earlier quoted context omitted.
> What if that process changes and the language you’re reading is a natural one instead of code? Natural language is not a good way to specify computer systems. This is a lesson we seem doomed to forget again and again. It's the curse of our profession: nobody wants to learn anything if it gets in the way of the latest fad. There's already a historical problem in software engineering: the people asking for stuff use…
> But it seems we are introducing a whole new layer of lossy interpretation to the whole mess (...) I recommend you get acquainted with LLMs and code assistants, because a few of your assertions are outright wrong. Take for example any of the mainstream spec-driven development frameworks. All they do is walk you through the SRS process using a set of system prompts to generate a set of documents featuring usecases, f…
> I recommend you get acquainted with LLMs and code assistants
I use them daily, thanks for your condescension.
> I could see LLMs being used to check/analyze natural language requirements and help turn them into formal requirements though.
Did you read this part of my comment?
> Take for example any of the mainstream spec-driven development frameworks. All they do is walk you through the SRS process using a set of system prompts to generate a set of documents featuring usecases, functional requirements, and refined tasks in the form of an actionable plan.
I'm not criticizing spec-driven development frameworks, but how battle-tested are they? Does it remove the inherent ambiguity in natural language? And do you believe this is how most people are vibe-coding, anyway?