I suspect Newton is rolling in his grave at your words. Standing on the shoulders of giants also means respecting the giants. That means dedicating time to learning what they have to teach. Not treating them as a black box with no credit or consent, in the name of your own "glory".

Maybe that's because you're not using your time well in the first place

To be fair browsers/CSS have been solving a lot of use cases you'd normally turn to js for, lately. We should continue escalating this effort.

I fear this is an analogy for what's happening with LLMs and context engineering.

I had basically the same thought: This sounds a lot like how they describe LLMs working!

I find this a bit like saying that we can't understand East of Eden because Steinbeck is dead.

Yeah, we all own all code, if we can't understand the code we own, we study it. If we need to change it, we change it.

"Legacy" for me is a bad word. I refuse to use it, and I scold my colleagues when they do: it's our code, we modernize it if we don't like it, and if we stop using it, then it's finished code. What is this false dichotomy between legacy code and "not in prod yet code" ?

In companies we call our regulatory prosecutions for fraudulent behavior that are so complex that they last for 10 years "legacy matters". Do you think that points at a statement of factual representation, or at a ridiculous attempt at distancing ourselves from our actual responsibilities ?

A program is not a novel, despite the arguments of literate programming fans. It is more like interactive fiction. In the small, it is just short pieces of text. In the large, there is an invisible network connecting each of them. And the challenge you are facing when assigned to legacy code, is to make changes in the small pieces of text that are consistent with that network, or even sometimes changing the connections.

Seems like more of a subtextual/accidental ability than an emergent ability.

Exactly. If I'm going to be solving bugs, I'd rather they be my own.

Building a basic static html landing page is ridiculously easy though. What js is even needed? If it's just an html file and maybe a stylesheet of course it's easy to host. You can apply 20 lines of css and have a decent looking page.

These aren't hard problems.

A big part of my job is building proofs of concept for some technologies and that usually means some webpage to visualize that the underlying tech is working as expected. It’s not hard, doesn’t have to look good at all, and will never be maintained. I throw it away a few weeks later.

It used take me an hr or two to get it all done up properly. Now it’s literal seconds. It’s a handy tool.

> These aren’t hard problems.

Honestly, that’s the best use-case for AI currently. Simple but laborious problems.

Laziness mostly - no need to think about design, icons and layout (responsiveness and all that stuff).

These are not hard problems obviously, but getting to 80%-90% is faster than doing it by hand and in my cases that was more than enough.

With that being said, AI failed for the rest 10%-20% with various small visual issues.

> These aren't hard problems.

So why do so many LLMs fail at them?

And humans also.

There's a balance. Not every team is made up of infallible devs, even at decent companies. Human nature is never full-trust.

I've known talented devs who are great people who still need more oversight than you describe. Usually they are ~5 years off from being full-trust, yet still valuable team members. Yes they benefit from daily standups.

I'd argue they'd probably benefit more from 1-1 mentorship, and as a bonus you don't have to force your entire team to adopt agile.

Maybe that other dev has a unique ability you should reward. Sound awesome. Focus on that.