Even just some AI-assisted development in the trickier parts of my code bases completely robs me of understanding. And those are the parts that need my understanding the most!
Especially for large commits, it's become indispensable.
This part is honestly one of the most satisfying, where you merge the already existing functionality with beautiful patterns.
I also make good use of precommit hook scripts to catch drift where possible
I believe the argument from the other camp is that you don't need to understand the code anymore, just like you don't need to understand the assembly language.
Gave me way more control/understanding over what the AI would do, and the ability to iterate on it before actually implementing.
For small personal projects, it's more vibey.. eg. Home automation native UIs & services for Mac & Windows, which I wouldn't otherwise start.. more itches that can be scratched in my limited time.
If you only understand the code by talking to AI, you would’ve been able to ask AI “how do we do a business feature” and ai would spit out a detailed answer, for a codebase that just says “pretend there is a codebase here”. This is of course an extreme example, and you would probably notice that, but this applies at all levels.
Any detail, anywhere cannot be fully trusted. I believe everyone’s goal should be to prompt ai such that code is the source of truth, and keep the code super readable.
If ai is so capable, it’s also capable of producing clean readable code. And we should be reading all of it.
> We don’t have to look at assembly, because a compiler produces the same result every time.
This is technically true in the narrowest possible sense and practically misleading in almost every way that matters. Anyone who's had a bug that only manifests at -O2, or fought undefined behavior in C that two compilers handle differently, or watched MSVC and GCC produce meaningfully different codegen from identical source, or hit a Heisenbug that disappears when you add a printf ... the "deterministic compiler" is doing a LOT of work in that sentence that actual compilers don't deliver on.
Also what's with the "sides" and "camps?" ... why would you not keep your identity small here? Why define yourself as a {pro, anti} AI person so early? So weird!
Re: “other side” - I’m quoting the grandparent’s framing.
Engineering in the broader sense often deals with managing the outputs of variable systems to get known good outcomes to acceptable tolerances.
Edit: added second paragraph
> significant extra effort is required to make them reproducible.
Zero extra effort is required. It is reproducible. The same input produces the same output. The "my machine" in "Works on my machine" is an example of input.
> Engineering in the broader sense often deals with managing the outputs of variable systems to get known good outcomes to acceptable tolerances.
You can have unreliable AIs building a thing, with some guidance and self-course-correction. What you can't have is outcomes also verified by unreliable AIs who may be prompt-injected to say "looks good". You can't do unreliable _everything_: planning, execution, verification.
If an AI decided to code an AI-bound implementation, then even tolerance verification could be completely out of whack. Your system could pass today and fail tomorrow. It's layers and layers of moving ground. You have to put the stake down somewhere. For software, I say it has to be code. Otherwise, AI shouldn't build software, it should replace it.
That said, you can build seemingly working things on moving ground, that bring value. It's a brave new world. We're yet to see if we're heading for net gain or net loss.
I'm specifically addressing your use of the concept of determinism.
An LLM is a set of matrix multiplies and function applications. The only potentially non-deterministic step is selecting the next token from the final output and that can be done deterministically.
By your strict use of the definition they absolutely can be deterministic.
But that is not actually interesting for the point at hand. The real point has to do with reproducibility, understand ability and tolerances.
3blue1brown has a really nice set of videos on showing how the LLM machinery fits together.
They _can_ be deterministic, but they usually _aren't_.
That said, I just tried "make me a haiku" via Gemini 3 Flash with T=0 twice in different sessions, and both times it output the same haiku. It's possible that T=0 enables deterministic mode indeed, and in that case perhaps we can treat it like a compiler.
This is a valid argument. However, if you create test harnesses using multiple LLMs validating each other’s work, you can get very close to compiler-like deterministic behavior today. And this process will improve over time.
You're just amplifying hallucination and bias.
I guess it would be similar here: a small few people will hand write key parts of code, a larger group will inspect the code that’s generated, and a far larger group won’t do either. At least if AI goes the way that the “other side” says.
Give them gdb/lldb and have your mind blown!
Usage is somewhat like:
$ debug.py start $ debug.py -c "break main" $ debug.py -c "continue"
Cursor at least doesn't seem to like running interactive programs yet.
It was during university to get access to CPU counters for better instrumenting, like 15 years ago. Havent needed it since
Then what stops anyone who can type in their native language to, ultimately when LLM's are perfected, just order their own software instead of using anybody else's (speaking about native apps like video games, mobile phones, desktop, etc.)?
Do they actually believe we'll need a bachelor's degree to prompt program in a world where nobody cares about technical details, because the LLM's will be taking care of? Actually, scratch that. Why would the companies who're pouring gorrilions of dollars in investment even give access to such power in an affordable way?
The deeper I look in the rabbit hole they think we're walking towards the more issues I see.
LLMs can't read your mind. In the end they're always taking the english prompt and making a bunch of fill in the blank assumptions around it. This is inevitable if we're to get any productivity improvements out of them.
Sometimes it's obvious and we can catch the assumptions we didn't want (the div isn't centered! fix it claude!) and sometimes you actually have to read and understand the code to see that it's not going to do what you want under important circumstances
If you want a 100% perfect communication of the system in your mind, you should use a terse language built for it: that's called code. We'd just write the code instead
An LLM coding assistant today is an erratic junior team member, but its destructive potential is nowhere near some of the junior human engineers I've worked with. So it's worth building the skills and processes to work with them productively. Today, Claude is a singular thing. In six months or a year, it'll be ten or a hundred threads working concurrently on dozens of parts of your project. Either you'll be comfortable coordinating them, or you'll nope out of there and remain an effective but solitary human coder.
Driving is a skill that needs to be learnt, same with working with agents.
Claude set up account creation / login with SSO login, OTP and email notifications in like 5 mins and told me exactly what to do on the provider side. Theres no way that wouldn't have taken me few hours to figure out
There is no way its not faster at a large breadth of the work, unless youre maybe a fanatic with reviewing and nitpicking every line of code to the extreme
Probably less time, because you understood the details better.
You have to do more than prompts to get the more impressive results
sorry for being blunt, but if you have tried once, twice and came to this conclusion, it is definitely a skill issue, I never got comfortable by writing 3 lines of Java, Python or Go or any other language, it took me hundreds of hours spent doing non-sense, failing miserably and finding out that I was building things which already exists in std lib.