Exactly my thinking, nearly 50, more than 30 years of experience in early every kind of programming, like you do, I can easily architect/control/adjust the agent to help me produce great code with a very robust architecture. By I do that out of my experience, both in modelling (science) and programming, I wonder how the junior devs will be able to build experience if everything comes cooked by the agent. Time will tell us.

It might be as simple as creating awareness about how everything works underneath and creating graduates that understand how these things should work in a similar vein.

I do think that for most of the people, you are right, you do not need to know a lot, but my philosophy was to always understand how the tool you use work (one level deeper), but now the tool is creating a new tool. How do you understand the tool which has been created by your Agent/AI tool?

I find this problem interesting, this is new to me and I will happily look at how our society and the engineering community evolve with these new capacities.

Juniors need experience to know if the machine is going in the right direction or guide it. That experience is now nigh impossible to get, nobody has the time for apprentices now. It’ll take some brave management to pave a way forward, we don’t know what it’ll be exactly yet.

To continue this thought - what could have been different in the last 10-15 years to encourage junior developers to listen more where they might not have to those who were slightly ahead of them?

I’ll probably get over it, but I’ve been realizing how much fun I get out building something as opposed to just having be built. I used to think all I cared about was results, and now I know that’s not true, so that’s fun!

Of course for the monotonous stuff that I’ve done before or don’t care a lick about, hell yeah I let em run wild. Boilerplate, crud, shell scripts, CSS. Had claude make me a terminal based version of snake. So sick

There's no way I could hire someone who'd want me hovering over their shoulder like this.

This sounds tedious I guess, but it's actually quite zen, and faster than solo coding most of the time. It gives me a ton of confidence to try new things and new libraries, because I can ask it to explain why it's suggesting the changes or for an overview of an approach. At no point am I not aware of what it's doing. This isn't even close to what people think of as vibe coding. It's very involved.

I'm really looking forward to increasing context sizes. Sometimes it can spin it's wheels during a refactor and want to start undoing changes it made earlier in the process, and I have to hard correct it. Even twice the context size will be a game changer for me.

This is exactly what bothers me about the present moment. Not that the pride of craftsmanship is everything, but dialing it down to zero with extreme pressure to stay that way is a bit sad.

But we’ve clearly gone through this with other mediums before, perhaps someday people will appreciate hand written code the way we appreciate hand carved wood. Or perhaps we were all wasting time in this weird middle ground in the march of progress. I guess we’ll find out in 5-15 years.

I think it’s more nuanced than that.

Not every project one does will be or should be considered art or a source of joy and pride.

The boring CRUD apps that put the “bread on the table” are just that, a means to an end, they will not be your main source of pride or fulfillment. But somewhere in between there will be projects where you can put all your heart in and turn off that LLM.

Think of the countless boring weddings playlists a DJ has to do or the boring “give me the cheapest” single family homes an architect has to design.

Which means clearly we need to feed video of the dancefloor to a vision model and output MIDI tokens!

For example:

If I tell it to not use X, it will do X.

When I point it out, it fixes it.

Then a few prompts later, it will use X again.

Another issue is the hallucinations. Even if you provide it the entire schema (I did this for a toy app I was working with), it kept on making up "columns" that don't exist. My Invoice model has no STATUS column, why do you keep assuming it's there in the code?

I found them useful for generating the initial version of a new simple feature, but they are not very good for making changes to an existing ones.

I've tried many models, Sonnet is the better one at coding, 3.7 at least, I am not impressed with 4.

If Sonnet 3.7 is the best you've found, then no, you haven't tried many models. At least not lately.

For coding, I'd suggest Gemini 2.5 Pro, o3-mini-high, or Opus 4. I've heard good things about Grok 4 as well, so if you're OK with that whole scene and the guy who runs it, maybe give it a shot.

If you have already done so and still think Sonnet 3.7 is better than any of them, then the most likely explanation is that you got incredibly lucky with Claude and incredibly unlucky with the others. LLMs aren't parrots, but they are definitely stochastic.

Are people implementing stuff from start to finish in one go? For me, it's always been iterative. Start from scaffolding, get one thing right,then the next. It's like drawing. You start with a few shapes, then connect them. After you sketch on top, then do a line art, and then you finish with values (this step is also iterative refinements). With each step, you become more certain of what you want to do, while also investing the minimum possible effort.

So for me coding is more about refactoring. I always type the minimal amount of code to get something to work. And it usually means shortcuts which I annotate with a TODO comment. Then I iterate over, making it more flexible, adds more flexibility, makes the code more clean.

one thing at a time. slowly adding features and fighting against bug regressions, same as when I was writting the code myself.

I see it as a worrying extension of a pre-LLM problem: No employer wants to train, they just want to hire employees after someone else trains them.

So more work gets to penetrate a part of your life that it formerly wouldn't. What's the value of “productivity gains”, when they don't improve your quality of life?

Wish I had your confidence in this. I can easily see how this nullifies my hard earned experience and basically puts me in the same sport as a more mid level or even junior engineer.

I saw this as a chance to embrace AI, after a while of exploring I found Claude Code, and ended up with a pretty solid workflow.

But I say this as someone who has worked with distributed systems / data engineering for almost 2 decades, and spend most of my time reviewing PRs and writing specs anyway.

The trick is to embrace AI on all levels: learn how to use prompts. learn how to use system prompts. learn how to use AI to optimize these prompts. learn how to first write a spec, and use a second AI (“adversarial critic”) to poke holes in that plan. find incompletenesses. delegate the implementation to a cheaper model. learn how to teach AI how to debug problems properly, rather than trying to one-shot fixes in the hope it fixes things. etc

It’s an entirely different way of working.

I think juniors can learn this as well, but need to work within very well-defined frameworks and probably needs to be part of college curriculum as well.

LLMs have changed me. I want to go outside while they are working and I am jealous of all the young engineers that won’t lose the years I did sitting in front of a screen for 12 hours a day while sometimes making no progress on connecting two black boxes.

Those young engineers, in 10 years, won't be able to fix what the LLM gave them,because they have not learned anything about programming.

They have all learned how to.micromanage an LLM instead.

I have heard a version of this plenty of times, and it was never correct. In the early 90s it was the "electronics" people that were saying "I come from an electronics background, these young'uns will look at a computer and don't know what to do if it breaks". Well, bob, we did, the whole field moved to color coded anti-stupid design, and we figured it out.

Then I heard it about IDEs. Oh, you young people are so spoiled with your IDEs and whatnot, real men code in a text editor.

Then it was about frameworks. BBbbut what if your framework breaks, what do you do then, if you don't know the underlying whatever?

... same old, same old.

Every single finance person uses a calculator. How effective do you think a person in any aspect of finance would be if they had never learned what multiplication is? Would they perform their job adequately if they don't know that `X * Y` is `X repeated Y times`?

IOW, if you gave a finance person (accountant, asset manager, whatever) a non-deterministic calculator for multiplication, would you trust the person's output if they never learned what multiplication is?

This is the situation I am asking about; we aren't talking about whether deterministically automating something that the user already knows how to do is valuable, we're talking about whether non-deterministically generating something that the user is unable to do themselves, even if given all the time in the world, is valuable.

All those examples you give are examples of deterministic automation that the user could inspect for accuracy. I'm asking about a near-future where people managing your money have never learned multiplication because "Multiplication has been abstracted away to a tool that gets it right 90% of the time"

IMO the dichotomy should not be deterministic/stochastic, but proved/unproved reliable. gcc has been shown reliable, for instance, so I don't need to know whether it was built by deterministic (clever engineers) or stochastic (typewriting monkeys) processes. I'm certain the former are more efficient, but this is ultimately not what makes the tool valuable.

As a bit of an artificial example, there's stochastic processes that can be proved to converge to a desired result (say, a stochastic gradient descent, or Monte-Carlo integration), in the same way that deterministic methods can (say a classic gradient descent or quadrature rules).

In practical cases, the only proof that matters is empirical. I write (deterministic) mathematical algorithms for a living, yet they very rarely come out correct on first iteration. The fact there is a mathematical proof that a certain algorithm yields certain results lets me arrive at a working program much faster than if I left it to typewriting monkeys, but it is ultimately not what guarantees a valid program. I could just as well, given enough time, let a random text file generator write the programs, and do the same testing I do currently, it would just be very inefficient (an understatement).

Yup, my mom used to say "you need to be able to do it without a calculator, because in life you won't always have a calculator with you"... Well, guess what mom :)

But on a serious note, what I'm trying to say (perhaps poorly worded) is that this is a typical thing older generations say about younger ones. They'll be lost without x and y. They won't be able to do x because they haven't learned about y. They need to go through the tough stuff we went through, otherwise they'll be spoiled brats.

And that's always been wrong, on many levels. The younger generations always made it work. Just like we did. And just like the ones before us did.

There's this thing that parents often do, trying to prepare their children for the things they think will be relevant, from the parent's perspective. And that often backfires, because uhhh the times are achanging. Or something. You get what I'm trying to say. It's a fallacy to presuppose that you know what's coming, or that somehow an entire generation won't figure things out if they have a shortcut to x and y. They'll be fine. We're talking about millions / billions of people eventually. They'll figure it out.

People who "take the time to really understand the code" will rapidly be outcompeted by people who don't. You don't like that, I don't like that, but guess what: nobody cares.

I suppose we'll get over it, eventually, just like last time.

And I don't think there's anything to get over about them. They are useful but people elevate their significance too much over what they actually are.

As for "autocorrect," let us know when your "autocorrect" takes gold at the International Math Olympiad, with or without steroids.

I might offload multiplying some numbers to a calculator, but Kids These Days™ are trying to offload executive function, like "what should I do next" or "is there anything I've forgotten".

Developers throwing huge amounts of money (in cloud resources) at performance problems that would’ve been prevented if they had some understanding of how their tech stack actually worked.

...and today, Nvidia ships self-immolating graphics cards because nobody wanted to figure out how to design a safe electric connector.

> Oh, you young people are so spoiled with your IDEs and whatnot, real men code in a text editor.

...and today, a lot of so-called programmers are trapped in AbstractHellFactorySingletonFactories that they cannot and never will understand, because generations of code monkeys have abused IDE assistance to dig themselves deeper into their hole.

And as a user, you'll know, because the software they write is garbage and never works reliably.

> Then it was about frameworks. BBbbut what if your framework breaks, what do you do then, if you don't know the underlying whatever?

Going by software like Teams, or Slack: They just ignore it, because consumers can't fight back against the the enshittification of increasingly useless software nobody understands.

Like, this is how we've always done it.

Finding a way to better learn first principles compared to sitting in front of a screen for 12 hours a days is important.

"That's OK, I found a jetpack."

I think if I was just starting out learning to program, I would find something fun to build and pick a very correct, typed, and compiled language like Haskell or Purescript or Elm, and have the agent explaining what it's doing and why and go very slow.

They are entering the job market with sensibilities for a higher-level of abstraction. They will be the first generation of devs that went through high-school + college building with AI.

Repeat that a few hundred times and you'll have some strong intuitions and sensibilities.

The junior dev who has agents write a program for them may not understand the code well enough to really touch it at all. They will make the wrong suggestions to fix problems caused by inexperienced assumptions, and will make the problems worse.

i.e. it's because they're junior and not qualified to manage anybody yet.

The LLMs are being thought of as something to replace juniors, not to assist them. It makes sense to me.

Or... just pick up that book, watch a couple of videos on Youtube and avoid all that trying.

That's not true at all, and hasn't been for a while. When using LLMs to tackle an unfamiliar problem, I always start by asking for a comparative review of possible strategies.

In other words, I don't tell it, "Provide a C++ class that implements a 12-layer ABC model that does XYZ," I ask it, "What ML techniques are considered most effective for tasks similar to XYZ?" and drill down from there. I very frequently see answers like, "That's not a good fit for your requirements for reasons 1, 2, and 3. Consider UVW instead." Usually it's good advice.

At the same time I will typically carry on the same conversation with other competing models, and that can really help avoid wasting time on faulty assumptions and terrible ideas.

Do you think humanity will be better off because we'll have humans who don't know how to do anything themselves, but they're really good at asking the magical AI to do it for them?

What a sad future we're going to have.

[1] https://www.vox.com/technology/23882304/gen-z-vs-boomers-sca...

The short version is that they mistake confidence for competence, and the younger consumers are more confident poking around because they grew up with superior idiot-proofing. The better results are because they dare to fiddle until it works, not because they know what's wrong.

It used to be you could learn to program with a cheap old computer a majority of families can afford. It might have run slower, but you still had all the same tooling that's found on a professional's computer.

To use LLMs for coding, you either have to pay a third party for compute power (and access to models), or you have to provide it yourself (and use freely available ones). Both are (and IMO will remain) expensive.

I'm afraid this builds a moat around programming that will make it less accessible as a discipline. Kids won't just tinker they way into a programming career as they used to, if it takes asking for mom's credit card from minute 0.

As for HS + college providing a CS education using LLMs, spare me. They already don't do that when all it takes is a computer room with free software on it. And I'm not advocating for public funds to be diverted to LLM providers either.

Like there's a mindset where you just want to get the job done, ok cool just let the llm do it for me (and it's not perfect atm), and ill stitch everything together fix small stuff that it gets wrong etc, saves alot of time and sure I might learn something in the process as well. And then the other way of working is the traditional way, you google, look up on stackoverflow, read documentations, you sit down try to find out what you need and understand the problem, code a solution iteratively and eventually you get it right and you get a learning experience out of it. Downside is this can take 100 years, at the very least much longer than using an llm in general. And you could argue that if you prompt the llm in a certain way, it would be equivalent to doing all of this but in a faster way, without taking away from you learning.

For seniors it might be another story, it's like they have the critical thinking, experience and creativity already, through years of training, so they don't loose as much compared to a junior. It will be closer for them to treat this as a smarter tool than google.

Personally, I look at it like you now have a smarter tool, a very different one as well, if you use it wisely you can definitely do better than traditional googling and stackoverflow. It will depend on what you are after, and you should be able to adapt to that need. If you just want the job done, then who cares, let the llm do it, if you want to learn you can prompt it in certain way to achieve that, so it shouldn't be a problem. But this sort of way of working requires a conscious effort on how you are using it and an awareness of what downsides there could be if you choose to work with the llm in a certain way to be able to change the way you interact with the llm. In reality I think most people don't go through the hoops of "limiting" the llm so that you can get a better learning experience. But also, what is a better learning experience? Perhaps you could argue that being able to see the solution, or a draft of it, can be a way of speeding up learning experience, because you have a quicker starting point to build upon a solution. I dunno. My only gripe with using LLM, is that deep thinking and creativity can take a dip, you know back in the day when you stumbled upon a really difficult problem, and you had to sit down with it for hours, days, weeks, months until you could solve that. I feel like there are some steps there that are important to internalize, that LLM nowdays makes you skip. What also would be so interesting to me is to compare a senior that got their training prior to LLM, and then compare them to a senior now that gets their training in the new era of programming with AI, and see what kinds of differences one might find I would guess that the senior prior to LLM era, would be way better at coding by hand in general, but critical thinking and creativity, given that they both are good seniors, maybe shouldn't be too different honestly but it just depends on how that other senior, who are used to working with LLMs, interacts with them.

Also I don't like how LLM sometimes can influence your approach to solving something, like perhaps you would have thought about a better way or different way of solving a problem if you didn't first ask the LLM. I think this could be true to a higher degree for juniors than seniors due to gap in experience when you are senior, you sort of have seen alot of things already, so you are aware of alot of ways to solve something, whereas for a junior that "capability" is more limited than a senior.

This kind of working is relaxing and enjoyable until capitalism discovers that it is, and then you have to do it on five projects simultaneously.

Where I use it for is:

1. Remembering what something is called -- in my case the bootstrap pills class -- so I could locate it in the bootstrap docs. Google search didn't help as I couldn't recall the right name to enter into it. For the AI I described what I wanted to do and it gave the answer.

2. Working with a language/framework that I'm familiar with but don't know the specifics in what I'm trying to do. For example:

- In C#/.NET 8.0 how do I parse a JSON string?

- I have a C# application where I'm using `JsonSerializer.Deserialize` to convert a JSON string to a `record` class. The issue is that the names of the variables are capitalized -- e.g. `record Lorem(int Ipsum)` -- but the fields in the JSON are lowercase -- e.g. `{"ipsum": 123}`. How do I map the JSON fields to record properties?

- In C# how do I convert a `JsonNode` to a `JsonElement`?

3. Understanding specific exceptions and how to solve them.

In each case I'm describing things in general terms, not "here's the code, please fix it" or "write the entire code for me". I'm doing the work of applying the answers to the code I'm working on.

1. I usually just pull up the docs for the CSS framework, give it a quick look over to know what it offers and the nomenclature and then keep it open for all the code examples.

2. I've serialized json in enough languages to know the pain points, so what I usually do is locate the module/library responsible for that in that language. And then give the docs/code sample a quick lookover to know where things are.

3. With nice IDEs, you launch the debugger and you have a nice stack frame to go through. In languages with not so great tooling, you hope for a trace.

It's not that your workflow won't yield result. But I prefer to be able to answer 5 successive why's about the code I'm working on. With PRs taking hours and days to be merged, it's not like I'm in an hurry.

For 3 -- Sure, that can help. But sometimes it is difficult to follow what is going on. Especially if that comes from a library/framework you are unfamiliar with such as AWS.

I've also used it to help with build errors such as "Bar.csproj: Error NU1604 : Warning As Error: Project dependency Foo does not contain an inclusive lower bound. Include a lower bound in the dependency version to ensure consistent restore results." -- That was because it was using a fixed version of the module via the "[1.0]" syntax, but my version of NuGet and/or Rider didn't like that so once I new that and the range syntax specifying "[1.0, 1.0]" worked. I was able to understand that from the LLM response to the error message and telling it the specific `<PackageReference>`.