But also points out tons of your deliberate design choices as bugs, and will recommend removing things it doesnt understand.

AI reviews have the benefit of making me feel like an idiot in one bullet point and then a genius in the next.

On her deathbed, years ago, my beloved mother lamented that she often felt mentally bullied by her three brilliant sons [0], even decades into our adulthoods; embarassed, she would censor her own knowledge-seeking from the people she trusted most [2].

She didn't live long enough to use ChatGPT [1] (she would have been flabbergasted at its ability to understand people/situations), but even with her "normal" intelligence she would have been a master to its perceptions/trainings.

[0] "Beyond just teasing."

[1] We did briefly wordplay with GPT-2 right before she died via thisworddoesnotexist.com exchanges, but nothing conversive.

[2] Relavent example, to the best of my understanding of hers: I would never ask my brilliant engineer programmer hardwarebro for coding help on any personal project, never. Just as I don't ask lawyerbro for personal legal advice.

----

About a year later (~2023), my dentist friend experienced a sudden life change (wife sick @35); in his grieving/soul-seeking, I recommended that he share some of his mental chaos with an LLM, even just if to role-play as his sick family member. Dr. Friend later thanked me for recommending the resource — particularly "the entire lack of any judgments" — and shared his own brilliant discoveries using creative prompt structuring.

----

Particularly as a big dude, it's nice to not always have to be the tough guy, to even admit weakness. Unfortunately I think the overall societal benefits of generative AI are going to increase anti-social behaviour, but it's nice to have a friendly apprentice that knows something about almost everything... any time... any reason.

I'm'bout'ta flash your PLC Ladder Logic firmwares, friend.

j/k don't worry I'm an idiot — but somebody else WILL.

>If these automations allow a developer to burn less time, it reduces the need for headcount.

This is exactly the fallacy, and it's very hard to see why it's a fallacy if you've never professionally written code (and even then).

Software development work fills to occupy the time allotted to it. That's because there is always a tradeoff between time and quality. If you have time available, you will fundamentally alter your approach to writing that piece of software. A rough analogy: air travel doesn't mean we take fewer vacations -- it just means we take vacations to farther away places.

Because of this effect, a dev can really finish a project in as little time as you want (up to a reasonable minimum). It just comes down to how much quality loss and risk can be tolerated. I can make a restaurant website in 1 hour (on Wix/Squarespace) or in 3 months (something hand-crafted and sophisticated). The latter is not "wasted time", it just depends on where you move the lever.

However, sometimes this is a false tradeoff. It isn't always necessary that the place you flew 3 hours will give you a better vacation than some place you could've driven to in 3 hours. You only hope it's better.

>As a direct result of this approach to hiring based on need, the concept of a "layoff" doesn't exist where I am.

LLMs or not, you could've just hired fewer people and made it work anyway. It's not like if you hired 3 people instead of 6 before the LLM era, it was impossible to do.

The gist of it is that LLMs are mostly just devs having fun and tinkering about, or making their quality of life better, or implementing some script, tooling, or different approach that they might've avoided before LLMs. There's no powertrain from that stuff to business efficiency.

Whichever PM sold glazing as a core feature should be ejected into space.

I've found Opus 4.5 in copilot to be very impressive. Better than codex CLI in my experience. I agree Copilot definitely used to be absolutely awful.

saying "a coin may land on head or on tail" is useful when other people are saying "we will soon have coins that always land on heads"

Do you think smart companies seeking to leverage AI effectively in their engineering orgs are using the 20$ slopify subscription from Microsoft?

You get what you pay for.

    > disliking exceptions seemed crazy then but it's pretty normal now

Assuming that my interpretation is correct, then I assume that you are a low level systems programmer -- C, C++, Rust, etc? Maybe even Golang? If you are doing bog standard enterprise programming with Python, Java or C#, exceptions are everywhere and unavoidable. I am confused. If anything, the last 20 years have cemented the fact that people should be able to choose a first class citizen (language) that either has exceptions or not. The seven languages that I mentioned are all major and have billions of lines of legacy code in companies and open source projects. They aren't going anywhere soon. C++ is a bit special because you can use a compiler flag to disable exceptions... so C++ can be both. (Are there other languages like that? I don't know any. Although, I think that Microsoft has a C language extension that allows throw/catch!)

That's how we got Rust.

I completely understand the difference, and I am standing by my statement that 80-90% of programmers are not doing advanced programming at all.

Theoretically, if AI can do 80-90% of programming jobs (the ones not in the "advanced" group), that would be an unequivocal +1 for AI.

I used to hand roll the assembly, but now I delegate that work to my agent, clang. I occasionally override clang or give it hints, but it usually gets it right most of the time.

clang doesn't "understand" the hints because it doesn't "understand" anything, but it knows what to do with them! Just like codex.

it's something that crossed my mind too honestly. natural-language-to-code translation.

Compilers are probably closer to "intelligence" than LLMs.

This is all a bit above my head. But the effects a compiler has on the computer are certainly not deterministic. It might do what you want or it might hit a weird driver bug or set off a false positive in some security software. And the more complex stacks get the he more this happens.

And so is "AI". Unless you add randomness AKA raise the temperature.

[flagged]

Genuine reflection question, are these excellent communicators good at using llms to write code?

My supposition was: Many programmers that say their programming domain was too advanced and llms didn't work for their kind of code are simply bad at describing concisely what is required.

When you oversee a team technically as a tech lead or an architect, you need communication skills.

1. Basing on how the engineer just responded to my comment, what is the understanding gap?

2. How do I describe what I want in a concise and intuitive way?

3. How do I tell an engineer what is important in this system and what are the constraints?

4. What assumptions will an engineer likely make that are will cause me to have to make a lot of corrections?

Etc.. this is all human to human.

These skills are all transferrable to working with an LLM.

So I guess if you are not used to technical leadership, you may not have used those skills as much.

For the simplest changes you have to first review the code fully, ask for the change, do a new full review and so on.

I think it's more of a thread-bound dynamic rather than HN as a whole. If the thread starts positive you get "AGI tomorrow", if the thread starts negative you get "stochastic parrot".

But I see what you mean, there have been at least a few insane comment sections for sure.

What happens if you work in a team?

If a team has one senior/seasoned person and 3 juniors will adopting ai be a total positive move? Or the senior person will just become the bottleneck for the junior devs?

Use case mapping matters. I use AI tools at work (have for a few years now, first Copilot from GitHub, now I use Gemini and Claude tools primarily). When the use case maps well, it is great. You can typically assume anything with a large corpus of fairly standard problems will map well in a popular language. JavaScript, HTML, CSS, these have huge training datasets from open source alone.

The combination of which, deep training dataset + maps well to how AI "understands" code, it can be a real enabler. I've done it myself. All I've done with some projects is write tests, point Claude at the tests and ask it to write code till those tests pass, then audit said code, make adjustments as required, and ship.

That has worked well and sped up development of straightforward (sometimes I'd argue trivial) situations.

Where it falls down is complex problem sets, major refactors that cross cut multiple interdependent pieces of code, its less robust with less popular languages (we have a particular set of business logic in Rust due to its sensitive nature and need for speed, it does a not great job with that) and a host of other areas I have hit limitations with it.

Granted, I work in a fairly specialized way and deal with alot of business logic / rules rather than boiler plate CRUD, but I have hit walls on things like massive refactors in large codebases (50K is small to me, for reference)

Did you do 5-10 years of work in the year after you adopted AI? If you started after AI came in to existence 3 years ago (/s) you should have achieved 30 years of work output - a whole career of work.

Your site has waterfalls and flashes of unstyled content. It loads slowly and the whole design is basically exactly what every AI-designed site looks like.

All of the work you described is essentially manual labor. It's not difficult work - just boring, sometimes error prone work that mostly requires you to do obvious things and then tackle errors as they pop up in very obvious ways. Great use case for AI, for sure. This and the fact that the end result is so poor isn't really selling your argument very well, except maybe in the sense that yeah, AI is great for dull work in the same way an excavator is great for digging ditches.

Is your redesign live for chipscompo? Because if so, and absolutely no offence meant here, the UI looks like it was built by an intern. And fair enough, you sound like a backend guy so you can't expect perfection for frontend work. My experience with AI is that it's great at producing intern-level artifacts very quickly and that has its uses, but that certainly doesn't replace 95% of software development.

And if it's producing an intern-level artifact for your frontend, what's to say it's not producing similar quality code for everything else? Especially considering frontend is often derided as being easier than other fields of software.

> Yes, I save an incredible amount of time. I suspect I’m likely 5-10x more productive

The METR paper demonstrated that you are not a reliable narrator for this. Have you participated in a study where this was measured, or are you just going off intuition? Because METR demonstrated beyond doubt that your intuition is a liar in this case.

If you're not taking measurements it is more likely that you are falling victim to a number of psychological effects (sunk cost, Gell-Manns, slot machine effect) than it is that your productivity has really improved.

Have you received a 5-10x pay increase? If your productivity is now 10x mine (I don't use these tools at work because they are a waste of time in my experience) then why aren't you compensated as such and if it's because of pointy haired bosses, you should be able to start a new company with your 10x productivity to shut him and me up.

Provide links to your evidence in the replies

> I am the AI-hater's nightmare...

I-know-what-kind-of-man-you-are.jpeg

You come off as a zealot by branding people who disagree as "haters".

Edit: AI excels at following examples, or simple, testable tasks that require persistence, which is intern-level work. Doing this narrow band of work quickly doesn't result in 10x productivity.

I'm yet to find a single person who has shown evidence to go through 10x more tasks in a sprint[1], or match the output of the rest of their 6-10-member team by themselves.

1. Even for junior level work

How do you know they’re not lying?

The outputs of AI are most likely in the public domain. As automated process output are public domain, and the companies claim fair use when scraping, making the input unencumbered, too.

It wouldn't be OpenAI holding copyright - it would be no one holding copyright.

What about patents - if you didn't use cleanroom then you have no defence?

Patent trolls will extort you: the trolls will be using AI models to find "infringing" software, and then they'll strike.

¡There's no way AI can be cleanroom!

If you have them, post them.

A compiler does so deterministically and there is no AI involved.

>They are if you define them as such.

If a compiler counts as AI then so does literally every other program out there (at least the ones with well-defined inputs and outputs).

>Sure. As is natural language (e.g. criminal code).

Natural language is too ambiguous and self-referential to count as a programming language, per se. While a subset of natural language can obviously be used to describe programs, we distinguish programming languages from natural languages in that they are formally defined and bound to be interpreted in one way by a machine with a relatively small amount of context (notwithstanding minor differences between implementations). Natural language has the unfortunate property of semantic drift (or whatever it's called). The sounds, spellings, meanings of words, etc. are extremely context-sensitive and unsuitable for reliably encoding computer programs or anything else over long periods of time. It is very common for a single word in a natural language to have several meanings, even contradictory meanings.

>They took the higher level instructions written by the software engineers and translated that into machine code. Hence the name. Developer in the above referred to what you call software engineer.

I am well aware of what you're trying to say, and the historical context, but I think you're applying modern terminology to old practices to draw a bad conclusion.

>It seems your misinterpretation is down to thinking that software engineer and coder were intended to be the same person. That was not the intent.

I didn't misinterpret anything. These jobs were not "intended" into existence. It just so happens that writing any kind of code is challenging enough to require its own dedicated professionals. That has always been true.

>Once the job of coding went away it has become common to use those terms synonymously, but the above was clearly written about the past.

The job of "coding" never went away. The type of code being written changed. The product is still CODE as in a procedure or specification encoded in a purpose-built, machine-oriented, unambiguous, socially neutral, and essentially eternal language.

>Again, if you're looking for a silly semantic discussion, there is already another thread for that.

It's not a silly semantic discussion, it's a serious one. You think that one can be a "software developer" merely by using natural language, and that there is historical precedent for that. But this is very wrong, especially in the historical context. By your own argument, any dumbass manager could be a "software developer" if only he found an entity to write the software for him based on natural language instructions. It matters not whether the entity generating the actual code is a human being or a machine. Since there are actual people trying to hire software developers and engineers with real skills, it is a waste of everyone's time for vibecoders to call themselves "software engineers" or "software developers" because they're not. They are JUST vibecoders. That skill set may be sufficient for... something. But stop trying to make it into something it isn't with these misleading arguments and analogies.

It is slightly hilarious that this entire "silly semantic discussion" is a product of the properties of natural language. One of the massive benefits of computer languages is that you DON'T get into stupid discussions about the meanings of things very often. When you DO, it is usually because some goofball wrote a bad spec. The ambiguities and other nonsense are hammered out in the spec, and from there on the language has a concrete meaning that is not up for debate.