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.
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
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?"
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.
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.
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.
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.
Yes you could, or even just a vanilla DOM event handler on a button click.
The problem is that you cannot introspect the browser’s history with the history API. So you have to hack your way around that if you want the “go back in history if possible, otherwise navigate to fallback url” behavior. Which I guess is easier if you’re in a react SPA. Or if you’re fully a MPA and can just check document.referrer
There’s a brand new Navigation API that does let you introspect history entries from the same origin, which perfectly addresses the issue.
They are actually speaking to trying to make an in-app back button use the history stack so that it _doesn’t_ “break” your browser’s back button.
The problem with just calling history.back() with no fallback is it will bounce users out of your app (back to Google or wherever they came from) and PMs won’t like that…
`history.back()` shouldn't even exist, it's almost never correct to use it instead of a logical back button that works on the logical navigation structure e.g. going up a level, or to the previous page, etc.
For example, if you are on Page 5, then pressing "back" inside the app should always take you to Page 4. `history.back()` could take you to any page, it's unpredictable.
Disagreed. In everyday speech "going back" means going to where you came from. If I'm at a friend's place at 123 Main Street and I tell him I'm going back, what I'm saying is I'm heading back to my home, not to 122 Main Street. The web should work similarly.
And the idea of logical navigation is flawed because most websites don't have a well defined logical structure, nor is it feasible to have one. What is the previous page of a Wikipedia article, or an HN submission, or an Amazon listing, or a search result of cheapest direct flights between New York and Cancun? With how the back button currently works, at least there is consistency in what to expect when clicking it. Under your suggestion, there is no way a user knows what the back button does on each website unless he clicks on it first and find out himself.
I'm not talking about the back button. I'm talking about history.back() API. If you have a "back" button that is inside the page's viewport, it should work based on the page's logical model. So you go back from Page 5 to Page 4, regardless of where you were before. Only back buttons outside the viewport should work based on browser history. The history is part of the browser it's not part of the page.
It’s really common that you can arrive on a view from different places.
For example on instagram you might click through to a post from the explore page or from someone sending it to you via DM. In either case pressing the back button rendered in the app, or swiping back, will take you back to where you came from. It feels natural and seamless. Although I guess there are other ways to skin that cat than history.back()
But I agree with you when there’s a clear hierarchy. Like on a job ad a “back” button should just be a normal link to the index of job openings.
I’ve also been writing CSS professionally for nearly 20 years and am a big fan of tailwind.
The ergonomics in my day to day work are quite nice. To me, the better boundary of abstraction shifted to components, rather than the html/css/js “separation of concerns” that some of the older folks still like to parrot.
However, take a look at the markup and styling for the https://maps.apple.com/ web property.
I can’t deny that it’s quite beautiful and easy to holistically understand. Especially when it comes to the responsive styling—which is when I tend to find tailwind most awkward.
It’s my favorite example of “traditional” CSS structure in recent memory that has given me some pause when it comes to Tailwind.
For a human this advice is true. But what if a computer can near-instantly calculate a perfect swerve within the performance envelope of the car and driving conditions?
He said it was overpriced but bought it again from a different Erewhon so I assumed he liked it (Canadian understatement).
There's apparently a quality gap between locations. The pre-Waymo one was from Erewhon Grove and was freshly blended. Erewhon Beverly Hills on Rodeo Drive premade a bunch of them and left them lying around for a while before selling.
My brother's theory is that Erewhon Grove customers are people who legitimately wanted a smoothie and Erewhon Beverly Hills customers just want photos with the smoothie since it was very popular on Instagram at the time.
Most surprising fact was despite being a licensed product, it was better than the best non-licensed smoothie (coconut cloud).
Licensing deals should make the product worse because the royalties cut into the product margin. The company cuts costs or doesn't take creative risks as a result. But somehow Erewhon resisted these pressures when designing the Hailey Bieber smoothie. We had a discussion about why that was the case but couldn't come up with an answer.
I think they have rotating specials. These are pre-made, cheaper, and smaller. When you have a membership this is the one you get for free (once a month).
They used to have a “Dr. Paul's Raw Animal-Based Smoothie” that I looooved, but unfortunately they stopped making it. Still sad about that one :(
reply