Diogo

Lead Frontend Engineer @ren_systems loves to build stuff to help humans

[Benjamin Code @benjamincode]

Ma mère souffre d'un Alzheimer précoce.

Je passe la semaine avec elle.
Je tente d'utiliser toute la technologie dont on dispose aujourd'hui pour réaménager l'appart afin de l'accompagner au mieux dans sa maladie.

Domotique, Capteurs, IA...
Tout ce que je peux trouver pour l'aider.

Le jour, je suis avec elle, je réponds à ses questions. Je lui confirme plusieurs fois par jour que je suis bien son fils, le nom de mes frères, je réponds en boucle, peut être 30x par jour aux mêmes questions, ainsi qu'à ses hallucinations.

La nuit, je vibecode les interfaces qui nous permettront de l'assister à distance et de calmer ses anxiétés.

Je suis en miette mais c'est la première fois que je mets mon ingéniosité au service d'une personne aussi proche de moi, sur de telles problématiques. Ça donne de la force et de l'espoir.

Tiens bon Maman.

[Lee Robinson @leerob]

"Engineering, product, and design are all merging into a 'builder' role"

Yeah... I'm not so sure. This feels like an oversimplification and podcast talking point. Reality is a lot more complex.

Even with 1000 "Member of Technical Staff" titles, someone still has to wake up and care 100x more about Product or Design than anyone else. It is their Main Thing™

That's not to say MTS titles are universally bad, but I think they're an example of this 'builder' talking point that's become bastardized.

AI and coding agents have made generating code easy and yet... you're in for a world of pain if non-engineers ship a bunch of slop and don't have great engineers to tame the complexity.

The SF hivemind has a tendency to overfit what works at startups for every company. And to be fair, sometimes this is true! Startups can be a leading indicator for how the industry is changing and often cause disruption.

However, it is going to be incredibly hard to disrupt the extremely human parts of corporate jobs. You really think there's going to be a PM who also does some engineering and design on the side at JPMorgan Chase?

This is true for the simple parts of most jobs, like people wanting to have ownership over something and do good work, move up a career ladder, support their family, get paid well, make an honest living...

And also the hard parts: internal politics, some critical business system that has a bus factor of 1 which has been running for 15 years and isn't documented anywhere because it's that guy's job security. The real world has a lot of this stuff.

It's easy to pontificate about all roles collapsing but it's actually really nice to have a specific person or team who is an expert in one thing that you can work with. I don't expect that to change. Further, I think AI disruption to knowledge work will take decades to play out because it is more fundamental to the human condition (e.g. sociological/organizational) than pure intelligence.

[Karri Saarinen @karrisaarinen]

The fallacy of this is that more creates more. More hours, more hiring, more something.

And it is true in a sense. If you put in more work, more work will happen. But I think for most startups, the leverage is really in how differently you approach the problem, how well you cultivate your team, and the strategy.

Any large company can outspend you on hours. They have thousands or tens of thousands more people, spending more hours. If hours worked were the metric, every large company and government organization would always win and do the best work. More hours, better output.

This thinking is often representative of younger founders, where the startup becomes their identity and life. They have a hard time doing anything else, and cannot understand that your work is not the person that is you. But activities outside of work can grow you as a person too and make you do better work.

I’ve never worked this way. As a designer, I always saw the need to take a step back, to take a break. At times, I might work 12 hours or 16 hours, or whatever amount was needed, but it wasn’t the norm. You just can't grind design, you need inspiration. But taking that step away from the work, would give me more perspective, inspiration and I could approach the problem differently or I could just see the solution.

Grinding is never good for any creative problem, and startups or creating new products are often mostly about creative problem solving. Grinding works ok for email jobs, or where you just executing on very clear playbook.

With Linear, we’ve never worked this way. We work reasonable hours, 5 days a week. All of us founders have families. Many of our employees have families. I personally stop every evening, spend time with the family, cook dinner for the family, eat dinner together, and focus on things outside of work. Sometimes I work in the late evenings or weekends, but to me the pride is that I don’t need to. Company should be succesful without it.

My goal is to build a company that is sustainable in the long term, and doesn’t require heroics or personal sacrifices every single day.

There are times when our team is heroic. Launches, incidents, some other work that just needs to be done. They will work late into the night because they know it is the right thing. But we don’t require that every day or every week, and the more this happens, the more I think it is a failure of our company and leadership. The team and the leaders should always keep a reserve to use when something is needed.

Our thinking was also that quality, which we value, doesn’t emerge from working more or stressing people more. It emerges when you create the conditions for it to emerge. Often it is the appreciation, space, time, and how the person feels. A person who is rested will do better work.

I wouldn’t attribute much of our success to working a lot. The success came from having clear thinking, ideas, and focus to do the right things.

I sometimes wish we could move the culture more toward a Zen master.

Real mastery is not exerting the most effort. It is achieving the outcome with the least necessary effort.

[shadcn @shadcn]

You know why I don’t buy the “everyone will build their own software” take?

I can build this. I have the tools. I know how (probably). But I don't want to.

I want someone else to to build it maintain it, and charge me for it.

[Diogo @__diog]

Some people really think frontend is only doing landing pages…

[Rohit @rxhit05]

I don't think learning frontend dev is useful anymore

[Rhys @RhysSullivan]

The problem with the statement “I don’t write code anymore” is everyone has a different version of what it means

For instance to me I don’t hand write code, but the LLMs are still essentially a really dumb scribe that if I didn’t read their code things would go south fast

[Lee Robinson @leerob]

You might believe you should spend less time thinking about code because of AI.

I strongly disagree! We’re watching this play out live where tons of AI generated code becomes a liability.

At the end of the day, an engineer needs to be responsible / on call for code that gets shipped to production. If you don’t understand the system you’re trying to debug, you’re probably going to have a bad time.

Yes, AI can help with all of this, if you set up the proper systems. You can have agents triage prod logs, look at errors, etc. You can speed up parts of the investigation, but an engineer needs to make the call. There might be serious customer or financial implications from that change.

I expect the trend continue for trimming dependencies, vendoring code so you can modify it directly, preferring simpler systems with fewer abstractions, and spending waaaay more time thinking about system design and code maintenance.

I’ve said this before, but it’s a great time to get familiar with CS fundamentals and some of the history behind what great software looks like. Many parts will be different in the coming years as AI progresses, but also a lot more than people realize will stay the same.

[David @marconoiz]

People who can design AND animate are built different 💀

[Lee Robinson @leerob]

Code is actually the right abstraction.

Too often I see the future of software engineering diminished down to, effectively, writing and reviewing markdown files.

Yes, it will be hard to review thousands of lines of agent code. But maybe the takeaway is that you want less code?

Rather than just giving up ("well I guess we won't read the code, or we'll read this lossy markdown summary") this should be a signal forcing you to think about better systems.

- How can we make our codebase more verifiable? For example, fast/robust/stable tests, or moving to a typed language.

- How can we deslop or improve the architecture/abstractions of the code generated by agents? For example, spending more time up front on the codebase architecture/types before yolo generating all of the code.

- How are we going to maintain and evolve this codebase over time? The slop compounds. One great solution here is... you guessed it, learning from the past decades of software engineering! For example, you might just have the wrong abstraction entirely, leading to a ton of duplicated code.

I think the markdown folks *are* right in some ways. If you are using skills every day, for many different prompts and workflows, isn't that effectively "coding with markdown"? Kinda.

There's been plenty of ink spilled on the merits and benefits of skills. To me, skills make your style of working legible for agents. They don't replace code and that's not really the point.

In reality, there's this messy and constantly re-evolving future in which both of these things are true:

1. Skills (and markdown) are important for how you give input to the agents and ensure high-quality code & systems are created
2. Looking at the actual code will not be replaced by markdown summaries or a collection of spec documents that ignore the lower level details of the code

In summary: reality has a surprising amount of detail (and nuance)!

[dany @danywander]

if you've ever questioned your presence on x, i'd send you this screenshot.

but i agree with @bchesky it sounds easy to say "need a nice cabin within 2h drive" but that's super naive.

in marketplaces data mismatch have a price.

let me elaborate.

a user says: "i need a nice cabin within 2h drive"

okay.

- 2 hours from where? current location? home? by car or train?
- what does "nice" mean? luxury? cozy? cheap but charming?
- does cabin mean an actual wooden cabin in the woods or just a house in the countryside?
- when? this weekend? flexible dates? 2 adults? family? dog? budget? wifi? instant booking only?

as a human we compress intent. but it doesn't work for booking systems. it needs exact constraints.

chat makes the problem feel solved because the conversation feels natural.

but finding a place to book is not JUST a conversation.

the listings themselves are messy.

- one host says "cozy" and means small. another says "cozy" and means dark basement.
- photos make places look bigger.
- listings are incomplete.
- locations are hidden before you book.
- descriptions are written like marketing copy.

in natural way you could say "find me a quiet cabin with sunset views". then the question is - where is "quiet" and "sunset view" stored in database?

so the ai guesses from whatever metadata it can find. sometimes it works. often it doesn't.

and when wrong answer in chatgpt costs you nothing, on marketplaces mistakes cost money.

- wrong cancellation rules.
- pets actually not allowed.
- listing unavailable.
- distance wrong.
- hidden fees.
- bad check-in assumptions.

travel is a transaction and accuracy matters way more than just add an entry on my calendar.

travel is visual.

people scan photos, prices, maps, ratings, amenities all at once. even if its look complex ui etc.

but in chat ui it becomes just a queue: "here's option one." "here's option two." slower than a grid. way slower.

and ranking gets weird. if the ai picks 5 listings why those 5? best match? paid placement? hidden bias? safety call?

people still not ready to give up on personal control of the outcome. they want to be sure that they've done everything to find that exact place to stay.

speed matters too.

a good conversational booking needs intent parsing, availability checks, price lookup, policy fetch, ranking, maps, personalization. and many more.

nobody likes waiting 10 seconds, over and over, for "thinking…"

and this is just an exploration phase.

then we have "book it" part.
- which one?
- what dates?
- which card?
- who's traveling?
- did you accept house rules?

chat feels nice until you have to sign or pay. so chat probably doesn't replace forms. it just makes discovery better.

i'd bet on chat for intent to start with → filters for custom work and filtering → cards and maps for comparison → normal boring checkout.

you can just make a chat as ui when the moat is still the boring stuff - trust, clean inventory and control.

[Lee Robinson @leerob]

How to make your engineering job application stand out (from the perspective of someone looking at hundreds of resumes):

1. Your resume should be one page. If you really need more space, link to a website. You don't need 10+ bullets for each job.

2. You will immediately stand out >90% of applications if you link a personal website that has some intentionality behind it.

3. If you are going to link your X, you might want to clean up your posts? Seems obvious but... people post some wild stuff.

4. You should link your GitHub. Please avoid doing a profile README that looks like a MySpace profile with the badges and images. I'm trying to look at code and your ability to build interesting ideas.

5. You should try to customize your application to the company. If you're applying to a startup, the courses you took in college probably don't matter as much. Maybe more if you're trying to make it through the ATS screening for FAANG.

6. I'm seeing a surprising number of resumes which don't talk about AI or agents at all. Software engineering is changing and it's a pretty fair assumption that you will be expected to learn or understand coding with AI for your job. That should be reflected on your resume and projects (and I'm not just saying this because I'm at Cursor).

7. Take your LinkedIn seriously. Most devs are here hanging out on X but surprisingly still most people will send around your LinkedIn internally.

8. Find ways to show your unique strengths/tastes/interests. It's nice to see people are smart, well-rounded, and thoughtful. Maybe this is a collection of books you enjoyed and why. Or some writing you've done. Or films you liked. At the end of the day, people want to work with other people they like and respect. If nothing else, it will be a good conversation starter ("oh I love [book] as well!").

9. Do not use AI to write your cover letter or resume text. It's incredibly obvious, especially if you are applying to an AI company. You can still use it to ideate on ideas or phrases, but write it by hand (don't fall victim to the overused in-the-distribution-AI-phrases). See: /humanizer skill.

10. No photos on resumes. Save those for whatever you link out to.

11. Quality over quantity. 3 really good, thoughtful, detailed, interesting projects versus a wall of 27 AI-slop ones.

Remember that hiring managers / recruiters are getting hundreds or thousands of applications for a role. They're not going to spend 20 minutes on every single application. You need to cut the cruft and get to the point. I hope this helps you stand out!

[Manu Arora @mannupaaji]

Use 𝚟𝚒𝚎𝚠-𝚝𝚛𝚊𝚗𝚜𝚒𝚝𝚒𝚘𝚗𝚜 and 𝚌𝚕𝚒𝚙-𝚙𝚊𝚝𝚑 to animate theme switches instead of flipping them with a transition

𝚍𝚘𝚌𝚞𝚖𝚎𝚗𝚝.𝚍𝚘𝚌𝚞𝚖𝚎𝚗𝚝𝙴𝚕𝚎𝚖𝚎𝚗𝚝.𝚊𝚗𝚒𝚖𝚊𝚝𝚎(
{ 𝚌𝚕𝚒𝚙𝙿𝚊𝚝𝚑: ["𝚒𝚗𝚜𝚎𝚝(𝟶 𝟶 𝟷𝟶𝟶% 𝟶)", "𝚒𝚗𝚜𝚎𝚝(𝟶)"] },
{ 𝚙𝚜𝚎𝚞𝚍𝚘𝙴𝚕𝚎𝚖𝚎𝚗𝚝: "::𝚟𝚒𝚎𝚠-𝚝𝚛𝚊𝚗𝚜𝚒𝚝𝚒𝚘𝚗-𝚗𝚎𝚠(𝚛𝚘𝚘𝚝)", 𝚍𝚞𝚛𝚊𝚝𝚒𝚘𝚗: 𝟼𝟶𝟶 },
),

::𝚟𝚒𝚎𝚠-𝚝𝚛𝚊𝚗𝚜𝚒𝚝𝚒𝚘𝚗-𝚗𝚎𝚠(𝚛𝚘𝚘𝚝) {
𝚊𝚗𝚒𝚖𝚊𝚝𝚒𝚘𝚗: 𝚗𝚘𝚗𝚎;
𝚖𝚒𝚡-𝚋𝚕𝚎𝚗𝚍-𝚖𝚘𝚍𝚎: 𝚗𝚘𝚛𝚖𝚊𝚕;
}

Here the clipPath ensures the transition happens from top to bottom

[Marc Backes @marcba]

Don’t let bait content like this influence you. We need excellent frontend developers. There is a lot AI can’t do

[Karri Saarinen @karrisaarinen]

A common dynamic I observe with AI: it feels most impressive when you don’t know much about the subject, don’t care or don’t have a clear idea of what the you want.

This applies across design, code, legal, and more. If I don’t know code very well, every piece of code it writes feels very impressive.

Once you know what something should feel or look like, it becomes almost impossible to guide AI there. And you definitely can’t one-shot it.

[Samay @Samaytwt]

Unpopular opinion: "AI makes everyone a developer" is true the same way "cameras makes everyone a photographer"

[Klaas @forgebitz]

"software is solved" is always an argument by people who either have not built any software or are shipping the most absolute slop without users

[Leonardo Razovic @LRazovic]

“ It's time for a lot of backend engineers to give the frontend peeps their flowers, acknowledge some of this frontend stuff is Very Hard, and begrudgingly accept that React has some good ideas.”

💐🌷🌻

[Lee Robinson @leerob]

I really respect @antirez so I'd like to share my slightly different take on frontend development in 2026 (and especially in a coding agents world).

First, on his point around libraries/frameworks and company size:

> "We have things like Angular and React that are big-company-design stuff that became normal programming. It's like if every site runs on Kubernetes."

It's true that frontend frameworks had to uniquely solve for the design constraints of BigCos. How do you build a system where thousands of engineers need to ship components independently without muddying the rest of the app?

Composition! And if you take composition to its logical extreme and try to build a framework which works for both small *and* very large JavaScript apps, you end up with things like streaming, Suspense, and many of the other niceties of React and metaframeworks.

Often, you do want many of these things to build high quality products. But sometimes you don't, and you don't have to ditch React's composition model and all the libraries, ecosystem, bundlers, et al to get there.

Personally, I think Bun is one of the best realizations of this vision, where you can write React apps with a single toolchain. The layers of abstraction can fit in your head.

> "There was, in big companies, an extreme desire to do two things: totally isolate frontend from backend, because the internal organization of big companies has such a split, and to make applications so standardized that hiring new people, firing old people, is something possible and easy."

This might get into the HTMX holy war, but IMO this client/server debate has always been a thing. I'd also argue that, in many cases and now increasingly with AI, the client/server split is helpful for humans and agents to compartmentalize the codebase.

I'm personally very supportive of open-source libraries like React and friends that get battle-tested at scale and get security patches (while painful sometimes). Models can learn this abstraction, and for many many cases, stop reinventing the wheel. Similar feelings about Tailwind.

> "We later created a generation of programmers that can't even understand a single language very well in its internals, that is: Javascript, they often know the framework, not the language, nor even CSS well enough."

It's true that a lot of frontend devs end up focusing on the app layer code concerns like React/Tailwind and maybe aren't as proficient at debugging heap snapshots. But I don't think the solution is to throw out the abstractions entirely, but instead to keep teaching the next generation of devs how to go up and down the stack as needed.

This is now massively accelerated by AI and coding agents. Just like you can ask an agent to generate lots of frontend code for you, you can also ask it to deeply explain how every abstraction layer works. There's no forgoing competence to be a great frontend engineer.

> "The irony is that front-end developers highly suffer from all that, for a number of reasons: they are forced to continue learning new ways to do the same button, form, pagination, and so forth. And, also, if they are smart they understand they don't really know what programming really is in most cases, and are not happy about it."

Throughout my entire career doing frontend and product engineering, I've seen opinions like this over and over again. Back in the day, it was framing frontend as "just the HTML and CSS" / web developer, somehow less than"the great backend engineers. The reality is that there are many many incredibly talented frontend engineers who do lots of *extremely technical* work.

It's time for a lot of backend engineers to give the frontend peeps their flowers, acknowledge some of this frontend stuff is Very Hard, and begrudgingly accept that React has some good ideas.

And if you made it this far and still want to complain, I bet you can make an incredible frontend with Svelte/Tailwind and your coding agent of choice, taking 80-90% of the upside of the last decade of frontend dev

[Kyle Gawley @kylegawley]

Maintaining software is much harder than creating it.

[Hugo @striedinger]

The same ai labs telling you ui will no longer be a thing are selling you the same exact product with a different ui every other week