Remix.run Logo
▲ glouwbug 3 hours ago

When you write something you constantly remodel your understanding through refactors and rewrites until you internalize it. By internalizing it you gain the capacity to reason about it (during critical downtime) and communicate it. An entire team that can communicate can solve problems together, from one guy's vision to products white boarding to engineering's infrastructure to UX and UI's artistry.

It boggles me we completely forgot that the world operated like this just 4 years ago

▲breadzeppelin__ 3 hours ago | parent | next [-]

I feel this in my bones. My team is one of the most communicative in our org and have garnered a widely positive reputation I think largely as a result of our coming together every day to solve problems. Trying to get information out of the less communicative groups is like pulling teeth, i wonder how they get anything done at all

▲binarin an hour ago | parent | prev | next [-]

There are still some places that operate that way, as outlined in this Jane Street talk https://www.youtube.com/watch?v=zR9PpXWsKFQ (Production Engineering When Trading Billions of Dollars a Day).

> capacity to reason about it (during critical downtime) and communicate it

That's one of the things that's put into limelight in that talk.

I personally think that most of "Web Scale" software is inconsequential (inconsequential for its creators, not for users) - as there are no consequences for bugs and outages at all. A data breach -> slap on a wrist. Reputational damage because on an outage/data loss amidst general public? - almost impossible (clownstrike, anyone?)

The funny thing is that web scale software that's consequential is often in an ethically grey zone - but at least you won't be surrounded by colleagues who don't give a shit.

▲poisonborz 2 hours ago | parent | prev | next [-]

Assuming we don't speak about some vibed "one-shot-deploy" situation (for which there were options in the old world as well, with the same bad results), in a well disciplined team, why would AI make this worse?

You can still write anything by doing it either small steps, or at once followed by a lot of refactors while skimming over code and asking tons of questions / making refinements via prompts, guidelines, test guardrails. A team can still reason and whitepaper about the same things. Devs who were previously shy to ask some specific details (to not seem dumb) can now confidently survey big codebases and get insights in whatever style they can swallow.

The bigger problem I see is that all this requires a lot of communication, and most importantly writing skills, something that disappears in thin air in the last decades.

▲desmondl 3 hours ago | parent | prev | next [-]

> When you write something you constantly remodel your understanding through refactors and rewrites until you internalize it.

Unfortunately I learned that not everybody thinks this way. Some orgs do imperfectly fine without good engineering discipline, and that has been the case before AI... AI has only made it easier to give the appearance of good engineering, which is exactly the pre-AI goal of many orgs

▲cmrdporcupine 3 hours ago | parent | prev | next [-]

I am simultaneously deep down in the agentic treadmill and also supremely frustrated by this.

And I don't think it was ever necessary to go to the point where people just gave up authorship. These were choices made by adopting the "I'll do everything for you" agentic "harness" model that shipped with Claude Code but it was never inevitable.

e.g. we completely dropped fill-in-the-middle completion OG CoPilot auto completion model. That combined AI authorship with a human always in the mix and I actually really enjoyed it. It's just that the models involved were pretty stupid. We totally could have had IDE / shell / tooling integration that kept people in the driver's seat while automating parts of the drudgery away. Instead what we got was a simple chat loop with "oh, whatever, you go do it" being the ultimate result. Cuz, you'll totally review everything after and understand it, right?

The things should end by quizzing you on what was just made and if you don't pass, just throw it away. That'd be funny to watch.

▲dannyw 3 hours ago | parent | next [-]

Our brains are hard-wired to enjoy (at least in the short term) immediate gratification, and the removal of friction. It's a hard battle to fight.

▲d0mine 3 hours ago | parent | next [-]

Have you ever asked a long distance runner how are they feeling during a run?

▲danielbln 2 hours ago | parent | next [-]

Long distance runner here, feels amazing from start to finish. Ok, amazing maybe only during runners high, but definitely good all the way through. Running sucks until it doesn't.

▲kaffekaka 2 hours ago | parent | prev [-]

Running (especially long distance) is both immediate and long term satisfaction to me. Exhausting but very enjoyable.

▲cmrdporcupine 2 hours ago | parent | prev [-]

Imagine if you will two product proposals coming across Dario's desk.

One is:

1) Complex IDE integration where our AI model is called to assist users in making decisions, assisting them to do the things they already intended to do. It appears more as a function of the IDE rather than something separate. It shows off the intelligence of the model but doesn't show off any autonomy.

2) A separate tool that can be branded Anthropic. It takes over completely. It advances the narrative that we've already been spreading that AI is going to make some human jobs obsolete. It looks to employers (the actual people who spend money) like it replaces an expensive developer even if at first it requires one. It has minimal to no integration point.

Which do you think they'll approve. I think it has less to do with the user motivation and more with the producer's.

▲ 3 hours ago | parent | prev [-]
[deleted]
▲enraged_camel 3 hours ago | parent | prev | next [-]

The way I think about it is that understanding is formed in a top-down fashion now, instead of bottom-up. You can look at a feature developed by AI from the outside, and keep peeling the layers and examining them (or having AI explain them to you) until you learn how it works. It's like reading a textbook. It is different than writing the code yourself, or practicing the topic of the textbook yourself. But if you invest the time, it can be just as effective.

The issue of course is that if you do invest the time, then you're no longer saving time by using AI. You're just spending it reading and trying to understand something you didn't write. And that can be unpleasant in its own way.

My hot take is that for parts of a system that can be considered its core, forming a deep understanding is almost always important, and so is knowing how the different business domains integrate and where the connection points are. For many others, a high level understanding is sufficient. The difference is that now, with AI, you can make that choice. Before, you had to write everything yourself, and for any sufficiently complex and long-lived system it became impossible to hold all of it in your head.

▲wholinator2 3 hours ago | parent [-]

I disagree that reading a textbook is just as effective as solving problems yourself (this is what i read your statement to mean). It seems fairly obvious from university experience that doing the homework yourself gets you better test grades in the end. You can of course have the AI write the homework but you can't then just watch the AI solve it lest it be drastically muted in effect. Trying things that fail, working hard towards a problem, banging your head against something impossible, these are all worthwhile endeavors. Of course reading the textbook is useful too, very useful! But the textbook does not teach you experience.

▲shagie 2 hours ago | parent [-]

> Trying things that fail, working hard towards a problem, banging your head against something impossible, these are all worthwhile endeavors.

I believe that this is the most important thing... and something that people are afraid of. I've got dozens of personal projects and more than a few branches in my employers repo of things that didn't work... things that I tried, figured out it wasn't going anywhere and went to try some other approach.

I suspect that there's a bit of sunk cost fallacy going on elsewhere. "If I don't know how to do it, I'm not even going to try" and "I got this far, I'll keep doing it despite it being wrong."

As a programmer, I am often disappointed at the lack of curiosity in the language and how things could be done. My example would be people writing Java code as if it was still Java 7 - no streams, no Optionals... The fear of having to go back and do it again if using something new doesn't work they'll be in a worse position than if they did it the old way and not realizing that learning what doesn't work or seeing how things that didn't work in this situation may be the right thing for some other future problem.

▲caaqil 3 hours ago | parent | prev | next [-]

> It boggles me we completely forgot that the world operated like this just 4 years ago

I'd think that's what they call paradigm shift, and this probably repeated across generations from the introduction of the printing press, PC, the wheel, the internet to stochastic parrots that reduced what we still stubbornly insist require our special neurons to mere statistical modelling that can be aggressively scaled.

▲vividfrier 3 hours ago | parent | prev [-]

As part of a reorg, my team received a new system to maintain. I sat down with a great engineer and together we refactored that shit to get into something more maintainable. I became the go to guy for that system because our redactor led to such a deep understanding of the codebase.

Now in the age of AI... we adopted another system from a team and when we asked for knowledge sharing to prep for the handover the answer we got was "do we still do that? Just ask Claude".

It's now been a few months. We've shipped features in this new system. I still have no idea how it works. Okay I kind of know, but only at a very shallow level.

AI is the worst thing to happen to our industry.