I'm a bit joking, but we've been working in deterministic computation for so long, we don't even think of there being another way.

But seriously, I do view AI as the input to a deterministic machine. Junior engineers (well all engineers) aren't deterministic, and we've made processes to direct their behavior towards making better software. AI agents do a better job of following my processes than engineers. We move up the stack towards testing and verification rather than writing. That doesn't make me sad, after 40 years of coding, I'm kind of tired of it. I have more ideas than I can code, so I'm happy to give AI my ideas and have it code for me.

I had a former manager tell me that all technology problems are really people problems, now maybe all technology problems are all agent problems and we just have to get comfortable with managing agents like we got comfortable with managing people.

I guess I'm not spun up about the determinism because I've been working at the "treat it like a person" level more than the "treat it like a compiler" level.

To me, it's really like an engineer who knows the docs and had a good memory rather than infallable code generator.

I work at a small company, so we don't have tons of processes in place, but I imagine that if you already had huge "standards" docs that engineers need to follow, then giving the LLM those standards would make things even better.

We had to migrate to a new customer who didn't want the python middle layer, they wanted our software (Java) to read the output directly (don't argue on why this was necessary, just a requirement from a big customer). Since the python script grew up over time by many developers with small changes for new features, it was nearly impossible to understand exactly what it was doing.

I took only the parser code gave it to Opus 4.7 and said "This python code parses an undocumented file format. All of our tests pass and this code is the spec for the file format. Read the python code and create me a BNF document that describes what it parses." I took the BNF and started a new session and said "write me a parser in Java that parses the grammar in this BNF." It got it in one shot. Then all I needed to do is take what was parsed and pipe it into our existing software that took the structured format the python created.

Most of what I do is brownfield work and I really can't put our whole code base into an LLM because of IP issues, but for little things like this, is saves me weeks of work.

In the olden days we used Duff's devices and manually unrolled loops with duplicated code that we wrote ourselves.

Now, the compiler is "smart" enough to understand your intent and actually generates repeated assembly code that is duplicated. You don't care that it's duplicated because the compiler is doing it for you.

I've had some projects recently where I was using an LLM where I needed a few snippets of non-trivial computational geometry. In the old days, I'd have to go search for a library and get permission from compliance to import the library and then I'd have to convert my domain representations of stuff into the formats that library needed. All of that would have been cheaper than me writing the code myself, but it was non-trivial.

Now the LLM can write for me only the stuff I need (no extra big library to import) and it will use the data in the format I stored it in (no needing to translate data structures). The canon says the "right" way to do it would be to have a geometry library to prevent repeated code, but here I have a self contained function that "just works".

Pick your favorite GoF design pattern. Is that they best way to do it for the computer or the best way to do it for the developer?

I'm just making this up now, maybe it's not the greatest example; but, let's consider the "visitor" pattern.

There's some framework that does a big loop and calls the visit() function on an object. If you want to add a new type, you inherit from that interface, put visit() on your function and all is well. From a "good" engineering practice, this makes sense to a developer, you don't have to touch much code and your stuff lives in it's own little area. That all feels right to us as developers because we don't have a big context window.

But what if your code was all generated code, and if you want to add a new type to do something that would have been done in visit(). You tell the LLM "add this new functionality to the loop for this type of object". Maybe it does a case statement and puts the stuff right in the loop. That "feels" bad if there's a human in the loop, but does it matter to the computer?

Yes, we're early LLMs aren't deterministic, and verification may be hard now. But that may change.

In the context of a higher-level language, y=x/3 and y=x/4 look the same, but I bet the generated assembly does a shift on the latter and a multiply-by-a-constant on the former. While the "developer interface", the source code, looks similar (like writing to a visitor pattern), the generated assembly will look different. Do we care?

But in the bigger picture, where does it stop?

You had to do manual spark advance while driving in the 30's

You had to set the weights in the distributor to adjust spark advance in the 70's

Now the computer has a programed set of tables for spark advance

I bet you never think of spark advance while you're driving now, does that take away from deeply understanding the car?

I used to think about the accelerator pump in a the carburetor when I drove one, now I just know that the extra fuel richening comes from another lookup table in the ECU when I press the gas pedal down, am I less connected to the car now?

My old Jeep would lean cut when I took my foot off the gas and the throttle would shut quickly. My early fuel injected car from the 80's had a damper to slow the throttle closing to prevent extreme leaning out when you take your foot off the gas. Now that's all tables in the ECU.

I don't disagree with you that a manual transmission lets you really understand the car, but that's really just the latest thing were losing, we don't even remember all of the other "deep connections" to a car that were there 50-100 years ago. What makes this one different? Is it just the one that's salient now?

To bring it back on topic. I used to hand-tune assembly for high performance stuff, now the compilers do better than me and I haven't looked at assembly in probably 10 years. Is moving to AI generated code any different? I still think about how I write my C so that the compiler gets the best hints to make good assembly, but I don't touch the assembly. In a few years will be be clever with how we prompt so that the AI generates the best code? Is that a fundamentally different thing, or does it just feel weird to us because of where we are now. How did the generation of programmers before me feel about giving up assembly and handing it over to the compilers?

Is learning to drive stick as out dated as learning how to do spark advance on a Model T? Do I just give in and accept that all of my future cars, and all the cars for my kids are just going to be automatic? When I was learning to drive, I had to understand how to prime the carburetor to start my dad's Jeep. But I only ever owned fuel injected cars, so that's a "skill" I never needed in real life.

It's the same angst I see in AI. Is typing code in the future going to be like owning a carbureted engine or manual transmission is now? Maybe? Likely? Do we want to hold on to the old way of doing things just because that's what we learned on and like?

Or is it just a new (and more abstracted) way of telling a computer what to do? I don't know.

Right now, I'm using AI like when I got my first automatic transmission. It does make things easier, but I still don't trust it and like to be in control because I'm better. But now automatics are better than even the best professional driver, so do I just accept it?

Technology progresses, at what point to we "accept it" and learn the new way? How much of holding on to the old way is just our "identity".

I don't have answers, but I have been thinking about this a lot lately (both in cars for my kids, and computers for my job).

When I lived in a rural area with a few acres of property, I was much more social and engaged with my community.

Now I live at the edge of the city in a medium-high density townhouse area with no private outdoor space. Since I can never really get away from people and be alone, I also have no desire to go out and do things and engage with the community.

I think the variability is nice. If I can get home, relax, not have people around, have some private outdoor space, then I can recharge and have the energy to engage more.

It's a good point about the routine daily purchases, I never thought of that. But I live semi-rural so I'm not out every day wandering around the city and picking up a snack or anything like that. I imagine that could add up.

They say the prevalence of virus is down. They don't say that the cancer rate is down (granted too early to tell), nor do they talk about any adverse events or all cause mortality differences (again, probably too early to tell)

The only thing they can conclude is that the treatment given to stop the virus, stops the virus. But they don't mention any tradeoffs.

Not trying to be an anti-vaxxer conspiracy theorist, but good science needs to talk about the whole picture.

As soon as we got real jobs with a real income, we didn't waste time with that. Our philosophy now is to just make sure that we spend well under our means and not track. We don't penny-pinch, but we still keep some of the grad school "do I really need this?" mentality.

Our normal spending is somewhere under 1/2 of our take-home (including mortgage), so we just don't worry about it and keep saving. It helps that we don't have fancy tastes. It's a nice stress free way of saving and we don't have to get neurotic about tracking every penny either.

The thing that, I think, has given me a competitive advantage is that I put a significant amount of effort into learning the domain I'm working in. I've gone from health care system to theoretical physics to image processing to logistics to financial plumbing to electricity markets to obscure stuff for the War Department, and so on.

The value that you really provide to a customer is deeply understanding their domain and the problem they have in that domain and then translating that for a computer. If you're just taking tickets off of Jira and writing code without context you're no better than an LLM (just kidding...maybe).

So yes, I suggest that whatever field you're working in, you put the effort into learning the domain as well as practitioners in that domain. That's how you become valuable. It's not easy, but after a few iterations you start to see patterns and it becomes easier.

Maybe some of my bias is that when you have a hammer everything looks like a nail - or in my case: when you have a matrix everything looks like an eigenvalue. YMMV.

The elementary school tried adding the "share table" where you can put anything you don't want so that someone else could pick it up, but that was shut down because they could assure the feds that everyone was getting a "balanced" lunch.

My highschooler tells me of all the kids going through line multiple times to get pizza on pizza day and then throwing the rest away because they don't want that.

Of course we had a second tax that was approved this year because the free lunches were more expensive than they had planned. Wonder why.

I remember when I was 10 or 12 or so hacking with my IBM 8086 and using basic, I accidentally "invented" the bubble sort. In fact, mine was extra slow and inefficient because both my outer and my inner loop went from 1 to N and there was no early exit if no swaps were made. A true O(N^2) algorithm. I didn't now what O(N^2) meant, but I had some understanding the things quickly got slower.

Then later in CS101 I learned about big-O and all the theories around sorting and it immediately clicked because I had a deep understanding of something that I experienced and then could tie it to real theory. The other way around - learning the theory before the experience - wouldn't have worked as well.

To tie it to your comment, you should have a deep experience with your OS of choice and then when you go to school, you learn why things are the way they were.

When I say this I often get accused of gate keeping, but I don't view it that way. I look at it as other types of majors that have existed longer than CS. I often make an analogy to music majors. I can't enroll as a freshman and say I'm going to be a music major without ever having played an instrument. People get accepted to a music department after they demonstrate the ability (usually though the equivalent of hacking while they were kids), and in their music classes they learn theory and how to play different instruments (just like learning different OSes or languages).

I kind of feel that CS should be the same way, you should show up to CS101 knowing how to do things from deep experience. You may not know any of the whys or theory, that's fine, but you should have experience in doing.

To tie it back to the parent: you should come to CS knowing how to run Linux, maybe because you copied configurations or scripts from the dark corners of the internet. And then the CS classes should be around why it's all that way. E.g., you know that to schedule something you use cron; and CS would be a discussion around how generic OSes need a way to schedule tasks.

Both yuml and mermaid don't get you control over layout. I think that's a feature. If the layout engine can make a pretty picture that means your dependencies aren't too complex, but if the graph looks terrible and complicated, that means you're system is also probably terrible and complicated.