Of all the points the "other side" makes, this one seems the most incoherent. Code is deterministic, AI isn’t. We don’t have to look at assembly, because a compiler produces the same result every 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.
“Of all the points the other side makes, this one seems the most incoherent. Code is deterministic, AI isn’t. We don’t have to look at assembly, because a compiler produces the same result every time.”
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.
It helps, but it doesn't make it deterministic. LLMs could all be misled together. A different story would be if we had deterministic models, where the exact same input always results in the exact same output. I'm not sure why we don't try this tbh.
Are you sure that it’s T=0. My comment’s first draft said “it can’t just be setting temp to zero can it?” But I felt like T is not enough. Try running the same prompt in new sessions with T=0, like “write a poem”. Will it produce the same poem each time? (I’m not where I can try it currently).
> 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!
You just described deterministic behavior. Bugs are also deterministic. You don’t get different bugs every time you compile the same code the same way. With LLMs you do.
Re: “other side” - I’m quoting the grandparent’s framing.
> 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.
If we want to get really narrow I'd say real determinism is possible only in abstract systems, to which you'd reply it's just my ignorance of all possible factors involved and hence the incompleteness of the model. To which I'd point of practical limitations involved with that. And that reason, even though it is incorrect and I don't use it in this way, I understand why some people are using the quantifiers more/less with the term "deterministic", probably for the lack of a better construct.
I don't think I'm being pedantic or narrow. Cosmic rays, power spikes, and falling cows can change the course of deterministic software. I'm saying that your "compiler" either has intentionally designed randomness (or "creativity") in it, or it doesn't. Not sure why we're acting like these are more or less deterministic. They are either deterministic or not inside normal operation of a computer.
This is a good point, but with ai it’s a little different, because both your process and ai are getting better. You build processes that can aspirationally support inferior AIs, while at the same time AIs themselves improve and meet you half way. This thought does not help my mental well being unfortunately.
Somehow, "deep state" is always there as the god of Trump's failures. The concept of "deep state" should be excised from conversation now that we can clearly see the unilateral rule of this administration. At this point, I wish there was a deep state, but unfortunately there's just Trump. His personal idiosyncrasies explain things much better than any conspiracy theory ever could.
No, there is a deep state. It's people who are in the government, who hold to the constitution and the rule of law, rather than implementing whatever wild idea Trump currently proposes that is illegal and/or unconstitutional, and who therefore work internally to block a bunch of Trump's plans.
Or at least they must feel like the deep state to Trump. It's just that, for those who like the rule of law, those people are the good guys.
I think there's probably a 5th one that's new-ish. Code isn't where the value is now that agentic tools can whip out a solution to just about anything in no time, so the commentary provides semantic grounding that allows you to navigate generated code easily.
It's kind of like some of the existing reasons, but there is a difference there.
For those who build in Ruby on Rails, does htmx have an advantage over Turbo/Stimulus? For me, the sense that it doesn't is why I've been avoiding it. Prefer to stick with vanilla stack unless there's a very compelling reason not to.
I like to say that you can either learn to be fast at doing low quality work, or learn to be fast at doing high quality work. It’s your choice really. But the only way to learn the latter is to start by prioritizing quality over speed.
Funny how this exactly applies to instrument playing. Unearned speed only begets sloppiness. The only way to go past a certain velocity is to do meticulous metronome work from a perfectly manageable pace and build up with intention and synchrony. And even then it is not a linear increase, you will need to slow back down to integrate every now and then. (Stetina's "Speed Mechanics for Lead Guitar"; 8 bpm up, 4 bpm down)
At slow, manageable tempos, you can afford to use motions that don't scale to fast tempos. If you only ever play "what you can manage" with meticulous, tiny BPM increments, you'll never have to take the leap of faith and most likely will hit a wall, never getting past like 120-130 BPM 16ths comfortably. Don't ask how I know this.
What got me past that point was short bursts at BPMs way past my comfort zone and building synchrony _after_ I stumbled upon more efficient motions that scaled. IIRC, this is what Shawn Lane advocated as well.
I recommend checking out Troy Grady's (Cracking The Code) videos on YouTube if you're interested in guitar speed picking. Troy's content has cleared up many myths with an evidence-based approach and helped me get past the invisible wall. He recently uploaded a video pertaining to this very topic[0].
> What got me past that point was short bursts at BPMs way past my comfort zone and building synchrony _after_ I stumbled upon more efficient motions that scaled.
This is actually pretty close to what Stetina says. I just probably didn’t do a good job expressing it.
You’re oscillating above and below the comfort zone and that iteration like you say affords insights from both sides, and eventually the threshold grows.
Depends on the instrument. For wind instruments, the motions basically don’t change, and your focus is on synchronizing your mouth with your hands. Tonguing technique is different at high speed but you would typically practice with the same technique at low speed when learning a fast piece.
But the motions do change, at very slow tempos you can move basically one finger at a time, at faster tempos you have simultaneously overlapping motions.
On a trumpet? A clarinet? No, the motions don't simultaneously overlap. The fingering mechanics are slightly different at speed, but you would still start slow while using the higher speed mechanics and tonguing technique, not jump into high speed practice first.
No one is saying not to practice slow first. This advice is specifically for intermediate or advanced students who are putting a focus on developing speed specifically. Practice slow first, increase tempo slowly next, but when you hit a plateau, you need to add some repetitions that are well outside your comfort zone. You need to feel what it feels like to play fast, then clean it up.
It seems like this is a far more time efficient methodology to build speed on guitar, I do not know why it wouldn’t apply to other instruments like trumpet.
When I was in high school, a friend who played drums in a band would try to pull off these super complicated fast fills. He couldn't pull them off and I always thought, "why doesn't he play something he can get right?" Well, after months of practice, he was able to pull them off. He was a great drummer, but he worked at incredibly hard to get there. It's a little tangential to what you said, but it feels appropriately related.
I guess I'm agreeing while also saying that you can get there by failing a lot at full speed first. Maybe he practiced at half-speed when he was alone and I never saw that part.
One could argue that learned speed has the hours of practice "baked in" so it's actually much slower. And that's not a bad thing IMO.
I think this post only covers one side of the coin. Sure, getting things done fast achieves the outcome, but in the long run you retain and learn less. Learning new stuff takes time and effort.
> the exact same things the sloppy player is doing, but you do it in time and in tune.
It depends on the level we look at it, but I think there is fundamental difference in what excellent (professional grade?)players are doing compared to "sloppy" ones.
It is not just done with more precision and care, they will usually have a different mental model of what they're doing, and the means to achieve the better result is also not linear. Good form will give good results, but it won't lead to a professional level result. You'll need to reinvent how you apply the theory to your exact body, the exact instrument in your hand, what you can do and can't and adjust from there.
That's where veteran players are still stellar while you'd assume they don't have the muscle and precision a younger player obviously has.
PS: I left aside the obvious: playing in time and in tune is one thing, conveying an emotion is another. It is considerably hard to move from the former to the latter.
Absolutely. I can't tell you how many times I've been starting at a project that I basically know how to do, but it's got a bunch of moving parts that I need to account for. I'll just stare at the screen, drink more coffee, read HN, basically do anything besides actually work on it, because it's too big and unactionable. Some of this is actually useful brain-organization time, but some is just time wasting.
Eventually I'll get the bright idea to make a notes doc listing all the things that are bothering me. Just writing them down gets them out of my nebulous headspace into a permanent record, which inevitably makes it less scary - and before you know it's I'm either halfway to a runbook or technical design, and it turns out this project actually will only take a day or two once I have all the prep work done.
Some of you might remember an article from a while back titled "Don’t Build A General Purpose API To Power Your Own Front End". This is a follow up to share how things played out, answer additional questions, and help figure out, discuss, or debate anything else that might have come up based on my advice that not everyone agrees with.
This used to be a blog comment service. It looks like the domain name registration expired yesterday, and nobody seems to be responding to support (likely the email under the same domain is not even working). If the owner decided to abandon the project, I would at least like to get my data export (and ideally partial refund too).
I built portrayal[1] (a much simpler replacement for those dry libs), and was also experimenting[2] with runtime-enforced types based on this lib.
My general thoughts is that declaring types in Ruby is unnecessarily complicated, because you're basically just running values through pieces of boolean logic, and nothing else. Might as well make that explicit, which is what my experiment did. I didn't however publish the types library, but the concept was proven.
I wrote this controversial thought[1] once, but for what it's worth, it applied to me just as much as to anyone else. Projects like these type gems are incredibly fun and satisfying to build. Your vision is clear, you've seen types before, you're proficient enough with Ruby to do clever things. The work seems cut out for you. Go nuts!
Problem is, these kinds of solutions (I also see this in "service objects" world) take Ruby away from you, and offer you a whole new vocabulary. With time I started appreciating libraries that avoid solving a problem that plain Ruby can solve, because Ruby is incredibly clear and concise already. If you leave more opportunities for people to write plain Ruby, you will solve everything with much less library code.
I think that's where the fun of building goes against the end developer experience. Builders love "owning" everything. E.g, "No, don't write `&&`, I have a special way for you to compose types!"
These are general thoughts, but I'm happy to get concrete with specific examples too.
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.
reply