[kcrwfrd_]

We are doing this on my team (I am the frontend engineer) and honestly I really miss the old way of doing things.

Written specifications are being reduced in favor of these working prototypes, and now there’s this extra cognitive burden of reading the code and trying to determine what were the intended changes, and what’s the slop that needs to be tossed aside.

We also have to figure out, should we take over this generated PR and make any needed changes? Or do we start over from scratch? There’s often a sense of friction either way.

There have been times where a bunch of unintended changes were generated and I took time to port them over on my reimplementation, and then later on it’s “oops! Sorry! We didn’t mean to change that.”

I get it’s empowering but it does take away from some of the joy I used to find in my work and replaced it with some headaches.

[drpotato]

I am in a similar boat. Design and product use Claude to vibe design/code a feature/experience and rapidly prototype it, getting it in front of customers to get feedback with minimal engineering time. Amazing! However, you might be surprised to find out it hasn’t really helped us ship stuff faster overall.

The reason, I believe, is we’ve lost something along the way. Thinking. A non-trivial amount of which is now outsourced to a language model. It paints over the cracks in the prompt, hallucinates how things should work when unspecified, what would normally make someone stop and say “this isn’t quite working”, “how should I communicate this idea” or “what happens when…” has gone. Now, these details are left for after it’s been built proper.

Sure, we can improve the process and reflect more on how to utilise this new technique … but is it better than how things used to be? Yeah nah

[hparadiz]

I did this before AI though. I'd sometimes just build mockups directly in React using real components because it was quick and easy to put a form together with existing UI elements. I remember one project where the whole team was waiting on designs and I just came into stand up and was like "I built this yesterday. Is this what we wanted?"

[drpotato]

Have a single thought, please.

[MikeNotThePope]

My experience has been there’s more “what did it make and does it work?” overhead. It’s like a junior developer throwing stuff over the wall and I’m responsible for seeing if it sticks.

[Iolaum]

Why not ask Claude design to write a document fully specifying the prototype?

[_zoltan_]

The code is not meant to be read anymore. That's the mistake.

Do you look at generated assembly that comes out of your compiler? You don't. So why are you looking at this code?

We have pushed up the abstraction layer.

[movedx01]

> So why are you looking at this code?

Because I am getting the call to fix it when it breaks. I don't have to fix assembly by hand because compilers are deterministic and I have maybe encountered a single real compiler bug in my whole career. Compilers have earned my trust. LLMs are eroding that trust more and more every day I work with them. I encounter LLM-created problems in basically every single diff they surface for me, just over the months the diffs are getting bigger and harder to review and uncover the problems.

LLMs are not an abstraction(not even a bad one) because by design what they are doing is disambiguation. Compilers are not doing that, what you put IN the compiler has to be unambiguous in the first place.

Disambiguation is not a functionality of an abstraction layer. A good abstraction layer is the one I don't have to understand and can trust, if I have to understand its inner workings to use it it ceases to be an abstraction. Except with LLMs you can't even do that, they are a black box you can have no hope of understanding.

And it is not to say LLMs and agentic coding tools are not useful, they are absolutely very useful. They are just not an abstraction layer.

[lelanthran]

> We have pushed up the abstraction layer.

That's not what "abstraction" means. You wouldn't hire a designer and then call their work an "abstraction", would you?

It's something, but "abstraction" it aint.

[Profan]

Good engineers should understand what goes on underneath them in the stack (at decreasing accuracy probably the more layers away it is) if they care about their craft and the quality of it, even if not in perfect detail, if you're just acknowledging that you've never even tried, then perfect! The AI "revolution" is just right for you.

[_zoltan_]

your two statements can be true at the same time: I do not need to look at the code because I know exactly what it does.

do I care for every snippet? every call's signature? no I do not.

do I understand what it does 100%? yes, because I directed it to be built like that.

I don't get people like you. "care about their craft" - what craft? my job is to make ideas into reality, how I get there is irrelevant. this is what I get paid for and this is what gets me satisfaction.

I've always disliked spending weeks arguing with people about every little detail and having an ideaological war. From the end output most of the decisions that people who "care about their craft" care about are utterly irrelevant.

[kcrwfrd_]

I catch so much shit when I read the code. I’ll take this into consideration when I’m no longer catching poorly made slop all the time.

[_zoltan_]

that's not the LLM's fault. I iterate and give very specific instructions and my code is really good.

[zuzululu]

old way that was clunky, long feedback cycles and gate keeping UI

no thanks. BE boys do FE now