161–170 of 375 posts
Earlier quoted context omitted.
> you have to account for the fact that AI will get better rapidly that's nowhere near guaranteed
Nothing gets worse in computers. Name me one thing. And if the current output quality of LLM stays the same but speed goes up 1000, quality of the generated code can be higher.
The addiction aspect of this is real. I was skeptical at first, but this past week I built three apps and experienced issues with stepping away or getting enough sleep. Eventually my discipline kicked in to make this a more healthy habit, but I was surprised by how compelling it is to turn ideas into working prototypes instantly. Ironically, the rate limits on my Claude and Codex subscriptions helped me to pace mysel…
Isn't struggling to get enough sleep or shower enough and so on because you're so involved with the process of, you know, programming, especially interactive, exploratory programming with an immediate feedback loop, kind of a known phenomenon for programmers since essentially the dawn of interactive computing?
Earlier quoted context omitted.
My gripe with "developer accepts bad code without reading it" is two fold. 1. It's turning the Engineering work into the worst form of QA. It's that quote about how I want AI to do my laundry and fold my clothes so I have time to practice art. In this scenario the LLM is doing all the art and all that's left is the doing laundry and folding it. No doubt at a severely reduced salary for all involved. 2. Where exactly…
"Where exactly is the skill to know good code from bad code supposed to come from?" Answer: Books. Two semesters of "Software Engineering" from a CS course. A CS course. CS classes: Theory of Computing. (Work. AKA Order(N) notation. Turing machines. Alphabets. Search algorithms and when/why to use them.) Data Structures. (Teaches you about RAM vs. Disk Storage.) Logic a.k.a. Discrete Math. (Hardware stuff = Logic. Al…
Also again, this logic only works on absolute greenfield project. If you write enterprise code in large organizations, you also have to consider the established architecture and patterns of the code-base. There's no book or usually cohesive documentation to that. There's a reason a lot of devs aren't considered fully on-boarded until after a year.
If you leverage the LLM to write the code for you. Then you never learn about your own codebase. Thus you cannot preform good code review. Which again is why I say reviewing code while never writing code is a paradox statement. You don't have the skills to do the former without doing the latter.
Even if you're take was that typing code into a keyboard was never the main part of your job then the question is ok what is it? And if the answer was being an architect then I ask you. How can you know what code patterns work for this specific business need when you don't write code?
- AI creating un-opinionated summaries of PRs to help me get started reviewing
- AI being an interactive tutor while I’ll still do the hard work of learning something new [1]
- AI challenging my design proposal QA style, making me defend it
- boilerplate and clear refactorings, while I’ll build the abstractions
[1] https://www.dev-log.me/jokes_on_you_ai_llms_for_learning/
That AI would be writing 90% of the code at Anthropic was not a "failed prediction". If we take Anthropic's word for it, now their agents are writing 100% of the code: https://fortune.com/2026/01/29/100-percent-of-code-at-anthro... Of course you can choose to believe that this is a lie and that Anthropic is hyping their own models, but it's impossible to deny the enormous revenue that the company is generating via th…
It's not entirely surprising. You can prompt the AI to write code to pretty much any level of detail. You can tell it exactly what to output and it will copy character for character. Of course at a certain point, you have to wonder if it would be faster to just type it than to type the prompt. Anyways, if this was true in the sense they are trying to imply, why does Boris still have a job? If the agents are already d…
Earlier quoted context omitted.
It's very interesting to me how many people presume that if you don't learn how to vibecode now you'll never ever be able to catch up. If the models are constantly getting better, won't these tools be easier to use a year from now? Will model improvements not obviate all the byzantine prompting strategies we have to use today?
It's hilarious. The whole point of "vibe coding" is that you don't need to learn or know anything. It's like saying if you don't learn to use a smartphone you'll be left behind. Even babies can use it now.
The workflow that seems more perilous is the one where the developer fires up gas town with a vague prompt like "here's my crypto wallet please make me more money". We should be wielding these tools like high end anime mech suits. Serialized execution and human fully in the loop can be so much faster even if it consumes tokens more slowly.
When someone vibe-codes a project, they typically pin whatever dependency versions the LLM happened to know about during training. Six months later, those pinned versions have known CVEs, are approaching end-of-life, or have breaking changes queued up. The person who built it doesn't understand the dependency tree because they never chose those dependencies deliberately — the LLM did. Now upgrading is harder than building from scratch because nobody understands why specific libraries were chosen or what assumptions the code makes about their behavior.
This is already happening at scale. I work on tooling that tracks version health across ecosystems and the pattern is unmistakable: projects with high AI-generation signals (cookie-cutter structure, inconsistent coding style within the same file, dependencies that were trendy 6 months ago but have since been superseded) correlate strongly with stale dependency trees and unpatched vulnerabilities.
The "flow" part makes it worse — the developer feels productive because they shipped features fast. But they're building on a foundation they can't maintain, and the real cost shows up on a delay. It's technical debt with an unusually long fuse.
[flagged]
> LLMs are good at writing individual functions but terrible at deciding which functions should exist. Have you tried explicitly asking them about the latter? If you just tell them to code, they aren't going to work on figuring out the software engineering part: it's not part of the goal that was directly reinforced by the prompt. They aren't really all that smart.