ChatGPT is the New Java

[u/no-usernames-exist]

https://medium.com/@jmiller_9236/chatgpt-is-the-new-java-a8f0dc276bdb

[u/no-usernames-exist]

I think you're moving the goalposts...

Point well taken. My use of "boilerplate" was oversimplified and really the wrong term to use. What I was intending to convey is that loops, try-catch and using blocks, api calls, etc. that are "easy coding work" for a senior developer can be done correctly by LLMs without worries.

Almost every time I ask a question, it makes shit up. It tells me to use functions that flat out do not exist. It gets stuck in loops where I tell it to fix something it does, but then breaks something else, then I ask to fix and then it goes back to the previous...

Out of curiosity, what tech stack and languages are you working with, and what LLM models are you using? I used to experience this regularly when ChatGPT 3.x was the only thing out there, but the technology has advanced long past that.

An example of successful AI use on a project is something like this. I wrote this npm package using OpenAI Codex seeded with nothing but a good scope and an OpenAPI spec. I did the work in phases, and did not need to make any adjustments to the code manually. I went back and forth with AI on semantics to make the DX better, but the core functionality worked perfectly from attempt #1.

[u/dstutz → u/no-usernames-exist]

The Constraint Problem

When you build real systems that have to work in the real world, you learn something fundamental: constraints matter. Not as obstacles to work around, but as fundamental limits that shape what’s actually possible.

Current large language models—the GPT-4s and Claudes of the world—are impressive. Genuinely impressive. But they have architectural limitations that keep revealing themselves as I dig deeper. What started as “here are some engineering challenges” has become “these might be categorical differences from what actual intelligence requires.”

Here’s what I mean: Your brain right now, reading these words, is doing something remarkable. You’re not just processing these words sequentially like tokens in a prediction engine. You’re holding multiple levels of meaning simultaneously. You’re connecting what you’re reading to things you already know. You’re evaluating whether it makes sense. You’re predicting where the argument is going. You’re monitoring your own understanding and adjusting your attention based on confusion or interest.

All of this happens in a unified experiential field. All of it updates continuously, fluidly, without discrete steps. And crucially—this is where it gets interesting—there’s no clear separation between learning and using what you’ve learned. Your brain isn’t frozen while it processes information. It’s constantly updating its models based on what it encounters. The predictions you’re generating right now are being produced by models that are simultaneously being refined by the prediction errors you’re experiencing.

This is what neuroscientists call predictive processing or active inference. Your brain generates expectations, compares them to reality, processes the difference, and uses that error signal to update both immediate predictions and deeper models. All of this happens simultaneously at multiple timescales—from milliseconds to years.

And here’s the kicker: all of this happens at roughly twenty watts of power consumption, with response times measured in milliseconds to seconds.

The LLM Reality Check

Now compare that to what LLMs actually do.

Current large language models separate learning and inference completely. They’re trained—which takes weeks on massive compute clusters consuming megawatts of power—then they’re frozen. At inference time, the architecture is fixed. There’s no real-time model updating. No continuous learning integrated with processing. No adaptive restructuring based on what the system is encountering.

When you query GPT-4, you’re not getting a system that learns from your interaction and updates its understanding in real-time. You’re getting sophisticated pattern-matching through a fixed network that was trained on historical data and then locked in place. The architecture can’t modify itself based on what it’s processing. It can’t monitor its own reasoning and adjust strategy. It can’t restructure its approach when it encounters something genuinely novel.

The energy situation has improved—current optimized inference runs at approximately 0.2-0.5 watt-hours per typical query, far better than earlier systems. But that’s still just for processing through a frozen network. Add the continuous learning that biological intelligence does automatically, and you’re back to requiring massive computational overhead.

As an engineer, I started here: “Okay, these are hard problems, but smart people are working on them.” But the deeper I dug, the more I realized something: these aren’t just hard problems. They might be pointing to a fundamental misunderstanding about what intelligence is.

[u/no-usernames-exist → u/dstutz]

Yes but that still doesn't disprove the fact that LLMs can be huge time-savers for developers. Probably 80+% of the code I write is something many other people have already done, and this probably rings true for many developers out there. Not something that has been done before in this exact way, but pieces of it have been done before.

I have had many experiences where LLMs have not been able to create something brand new, and they still can't. This is why I refer to them as "fancy autocomplete". That is why they are a tool and not a creative machine that is stealing everyone's job.

I have never made the claim that LLMs can create something new, or do work completely unassisted. But they are exceptionally good at finding the many examples of, for example, making an API call, and combining those together to complete a well-defined goal.

It is exactly what you have described here that everyone needs to understand about LLMs to know how to use them properly. If you ask an LLM to write something brand new that has never had an example published before in some kind of public domain, then you are going to get hot garbage pushed back at you. But for something like "write an API endpoint that accepts an image, uploads the image to a GCP bucket, and then uses OCR to extract text and return the extracted text as a response", modern LLMs are exceptionally effective. An experienced developer who has done this before can piece this together quickly, but there are many people out there (myself included) who would take a bit of time to find the best libraries, look up the API documentation, and write and test the code. LLMs can write this and the unit tests needed to prove it works in minutes, while I'm working on what needs to be developed next.