About this talk
This talk addresses the importance of code quality in the era of artificial intelligence. The speakers argue that while AI technologies are changing development practices, maintaining high standards for code quality is crucial. They emphasize the need for developers to be actively engaged in the coding process, even when utilizing AI tools for assistance. The discussion veers into topics like code reviews, emotional intelligence, and critical thinking as vital skills for developers today. Moreover, they explore the implications of AI-generated code on project management and the future landscape of software development, highlighting the accelerated pace of change and the need to adapt.
Full transcript
Hello there once again. Um so, we will be talking today about code quality. I just need to take a break. Um we need we'll be talking about code quality specifically in the AI era. So, but before we go deeper into AI, into technology, I would like all of you to introduce yourself. Maybe you are not uh we we we haven't heard about you yet. Um and tell
us one interesting fact about yourself. That's a difficult one, so maybe I will start. My name is Jacob. I'm introduced myself already. You know that I do D&D, but maybe you don't know that I'm also a mentor at my local university where I help um students get a first job, get a promotion, basically trying to help them grow in today's uh world, let's say. Okay. Uh hi
again. Uh I am Elise. Uh and I uh I am a front-end architect uh freelance. And also I happen to have spoken today. I am um I occasionally speak to conferences. And of course co-organizer of meetup in Paris. Still promoting it. And uh a fun fact about me, I don't know. Oh, um I like AZERTY keyboard. >> [applause] >> Hello. Hello everyone. Um I'm Evan and I
build a lot of stuff. And you probably use some of it. Um yeah, interesting fact about myself. Um I'll talk about pretty recent one. I started snowboarding 2 years 2 years ago. Now I'm like so addicted to it. I'm just like watching snowboard videos whenever I'm like have some time on my phone. And can't wait to snowboard again. Sounds good. >> Hello. Hello. It's me again. Uh
I am Debbie as you all probably know at this stage. And you might have known me from Next and then Playwright. And now I'm just I like to talk so you'll just hear me everywhere now. Um and a fun fact about me. I don't know. There's so many things. I don't even know what to say. But I was thinking maybe I've traveled to every single continent in
the world. Not many people can say that. And that means Antarctica as well. I actually gave a tech talk in Antarctica. To the penguins. It was amazing. >> Uh I'm Daniel Roe. I'm a full-time open source maintainer. Um I lead lead the Next team. And an interesting fact about myself. I uh when I was 7, I lived in China for a year. And not by myself. My
parents were there And [clears throat] uh and while I was there, I ended up being an actor on a TV show called Little Frog Learns English. And I I I I have the video and an autographed book featuring me. Um and and the the the illustrator of that book uh he gave me the greatest compliment he said that he could give. And he drew me with a
big nose. That's That's That's at least at least I would say his justification for anyway. >> So now I will ask you few quick fire questions for which I would like as the name suggests quick answer. And but for our audience there is the QR code here that you can scan and you can ask some questions. You can also like them if if you would like me
to to ask them to our amazing panelists. Um so in the meantime you can ask ask your questions, like them as well so that I can see them. But for the quick fire questions it's the question for everyone. Console log or debugger? Debugger for me. It really depends. I use both. Okay. But if I'm too bothered to fire up the actual debugger, probably console log. Always console
log. Console log, not a doubt. I learned everything I know by tinkering in node modules and writing console log. Same for me. Dark mode or light mode? Dark, definitely. Dark mode. Dark. Keyboard smashing or gentle typing? Gentle. Yeah, I I I I really don't like keyboard smashing. Like it makes me uncomfortable when people do it. But no judgment on that. I would consider myself gentle. >> [laughter]
>> Yeah, I learned to type on a typewriter where you had to bash. We don't need to bash anymore. And where's the the melodic uh playing of the keyboard? I feel that should be an option. I like the the clickety-clack of my mechanical keyboard. I will give you I will say. Okay. Makes sense. For code reviews, do you prefer human only or assisted by tools? Well, it
depends how much assisted by tools I would say. >> But yeah, I would say currently I prefer humans. I even so I find always interesting to see what assistance can do. I'm actually open to any kind of it cuz I think my perception of how far what kind of feedback tools can actually give has changed a lot in the past few months. it really depends on how
well the tool is implemented as well. Like some of the code review services are like trash, but some of them are actually pretty good. If I have to review, definitely agent. I don't want to review code. Well, you're going agent only. >> I think I would definitely I would pick every opportunity to make it better. So that's and agent if there are other tools, that's good too.
That thing to avoid is thinking that when you answer all of the things that the agent observes about your code that you now have a perfect PR because that is absolutely not true. It's like you don't want that to give you false confidence. So that will be all for the quick fire questions. So give a round of applause to our speakers. >> Honest. And now we'll move
into open questions where if you like if you would like to volunteer to speak you can do, but it's not mandatory for everyone. But I wonder what do you think front end will look like in 2 years from now if current trends continue. Like you know, the AI evolution LLMs and so on. How do you think it will look like from your perspective? Nobody knows. Yeah, but
maybe you have some suggestions or I think it's Right. So, when we AI things, we saw the AI-generated video I created for Next, right? And I created similar for another one, and they all look the same. So, that's something to take into account. We really need to feed in design brands into it so that we can stop having the same generated stuff. So, there are is going
to be a lot of stuff that kind of looks similar, and it's up to us to improve and make sure that stays that things stay different. Yeah, so um I don't want to be overly pessimistic about it, but 2 years is a long time. And just think about how things were 2 years ago from now. Right? And like the changes are actually accelerating at this pace. So,
it is going to be very, very different. Um it is like the difference is probably bigger than where we are now compared to 2 So, that is my prediction. I think 2 years from now the way we approach front end in general, approach software engineering in general, and how how we actually design interfaces, how that design flows into your front end code, and how that code actually
gets developed uh delivered to production, all of that is going to change very drastically in 2 years. Um I can't really predict the exact form of how that will look like, but just based on the pace that things are moving right now, right? I think we just need to be prepared for this level of change. In 2 years' time, I'm going to be in my garden planting
uh some vegetables, and uh my personal robot will ping me um with a flimsy of a new design that it's produced on my instructions. I'll glance briefly at it, nod, ship it to production, I'll say, as I continue uh pruning my rose bush. I would say that's a concrete plan. That that that that's what it's going to be like in 2 years time, without a doubt. Uh
we'll we'll just be living in the future. But no, seriously, there're going to be a lot of things that we can already predict will change. LLM costs will be, I imagine, dramatically higher. There's a lot of investment right now, a lot of uh deals that um are, I think, artificially subsidizing the cost of a lot of infra inference. Um equally, a lot of models uh the profits
from them are being plowed back to generate new models. So there's there's a sort of never-ending cycle of retraining and rebuilding. I would be very interested to know if that's going to continue. It doesn't seem to be sustainable. Maybe there'll be some I I think it might be interesting to see if we have more on hardware uh models. Um so we we saw some interesting stuff about
incredibly fast um like if you take a model and you basically produce hardware of that model, you can get much much faster results than if you're even running it on a GPU. Um and you can make it fully local. So maybe everybody will have their own um inference uh engine like locally. That could be a very interesting change and might really change how people build, where you
almost have a second brain that you um So I I think who knows. Read a lot of science fiction. That's that's a a good good Good take. A good a good a good preparation. Preparation. for the future. >> Sounds better. We have a question from the audience, specifically for Daniel or Evan. Talk us how you are actually using AI. If you're using So, to be honest, I
haven't been using it super intensively until like a month or two ago. But, uh I have witnessed firsthand how a lot of people I work with use it. And then, in the last month or so, I have been using AI myself very, very intensively, like hundreds of commits in a week. Um And that is, I think, like just like what There was a very popular thread by
Andrej Karpathy on how he felt things kind of just changed in around the end of last year. And then, for me, it was very, very obvious after Opus 4.6 and Codex 5.3 came out. I think the models just got to a place, and also probably because the uh improvement in the in the agent harnesses, I think it has gotten to a point where like, a year ago,
I was still looking at some of the things AI produces and laughing it off. I'm like, this is just stupid. Uh now, it's getting so scarily yeah, I think it just crossed the threshold where I consider like, how AI is now capable of altering how we general. Um like, there are so many things now, if you know how you can steer it well, you don't really need
to bother with the the details of writing every line of code yourself anymore, right? Um Previously, like, cuz I have been writing code for so many years, right? I am very obsessed with the quality of the code that I put into a code base, right? but now I find that, if you know how to you can actually tune the models to produce the code that you you
like to to the extent like it meets my bar the quality bar that I have for the code that needs to go into my projects, right? So, I think that's um that's scary like to be honest. Um but I think like it's it's pretty recent. It's just like with the latest generation of models, the latest generation of of tooling that we have. And um I think that
trend is going to accelerate for the next 2 years. So, I do predict that I will be using AI very consistently. Um if I were to write my write code, I will probably like there was this controversy where uh Dario, the uh CEO of Anthropic said like to a certain date, 90% of the code will be written by AI, right? People laughed about it. I think he
was he's partially right because what he meant is not that AI is replacing engineers. I still firmly believe that, you know, as an engineer, you need to know your stuff so you can steer the AI well. And in the in the hands of different uh engineers of different capabilities, the same AI will produce drastically different results. That's a fact. Uh but the the code that actually gets
committed, 90% of that being produced by AI but not hand-typed by you, I think that's becoming a reality. Yeah. Uh so, in in the question for me for me, so how do I actually use AI? here are some very practical ways. If Evan has given us the big picture, um here are some practical ways I use it on a day-to-day basis. I have a an app called
Unsight that is is a GitHub app. It indexes issues from GitHub repos. Anyone can install it on their repo, but I use it for Nuxt. Uh it creates embeddings for all of those issues. An embedding is think of it like not a three-dimensional position in space in space, but an n-dimensional uh position in conceptual space. Um like you might have a thousand dimensions, and every issue can
be located there. And then I use matrix uh math to find clusters of issues that are close related. Uh and then that helps me understand what um what what common patterns of behavior exist in Nuxt bugs or features, for example. It's really, really useful. It actually doesn't involve an LLM as such, other than like to generate the embedding like the the actual matrix. Everything after that is
deterministic. Um I also use um uh LLMs to do things like detect if uh reproductions are provided on issues, and automatically ask people for reproductions if not. Uh if people comment on a closed issue saying that the issue has come back, I have an LLM detect that and reopen the issue, so it gets popped back into my notice. If people report a bug uh saying that something
has stopped working but it used to work, I have an LLM put a label on that so that I know that it's a potential uh regression that I might want to investigate. Um that kind of thing I find incredibly useful. Um I also find if you're going a little bit further into the code path, um like first getting LLMs to replace toil, stuff like uh resolving merge
conflicts uh can be an incredibly boring thing to do that you can very easily automate with some of the newer task harnesses. That can be quite useful. Um the kind of things that I absolutely full stop vehemently will not do are things like write social media posts with AI. Um on the what the one place in the world you're looking for genuineness and connection with real people,
get LLMs out of that, please, right? If I actually if I if I'm browsing through, I can tell when people write stuff with LLMs. I guess we all can. Like how how do you feel any sense of connection when you read an LLM written tweet? No, right? It's awful. Like if if anything, you feel further away. Um so I really want to avoid like yes, use use
LLMs for the things they're great at, but please don't get them in between me and you. >> So on the topic of maintaining high quality, if I may mention that have the tools, right tools to make sure the um quality is still maintained, it can produce actually good say products code. Do you have any recommendations for for all of us on the tools or processes that can
be used in in nowadays era to maintain this quality? Yeah, so I would say coding with AI is not just like taking a random LLM and this then just prompt it to do things, right? So as engineers, I still think there are many things you need to take care of, like finding the best harness, finding the best workflow, and setting up the proper context for the for
the agent about your code base, right? What is what are the constraints? What is what are your goals? What are the you know, rules, uh quality criteria, acceptance criteria. Um if you want the agent to be able to do work autonomously, you need to give it the guardrails, and that those guardrails are still need to set up by you, right? It's It's very project specific. It's also,
you know, uh very dependent on your specific taste or requirement of how you think the project should evolve. Um you can't just leave it leave these things up to the LM. That's just too open-ended. Um and continuous steering, like how much you as a human want to be in the loop, I think it's also quite important. Um I'm still like my way of working with AI is
still like I'm constantly in the loop. I let I let it run mostly when it's just like cranking out code, but I spend a lot of time just before letting it write any code, I spend a lot of time just discussing with the agent on what I want to implement, what are the best way to do that, what are the, you know, like there's a brainstorming skill
in Claude code that I like because it sometimes it will like going to branches that you probably never thought about when you started with an idea. And it's I think it's important for you to exhaust the design decisions up front before letting the agent loose and write the code, right? Writing code is now the easy part. The hard part is still deciding what is the right thing
to do, and that process, while the agent can help, still needs to be mainly driven by you, the developer. And I think that's still where we us as engineers or developers still stay valuable is you are still the person deciding what needs to be done, and you need to be steering the AI to do it in the way that you think is the right way. I'm not
sure if that's the That's relevant to the question. What is the question again? >> The question [clears throat] was a bit more general in terms of just maintaining high quality. So, we can also go out of the let's say AI bubble and focus on the just the code. Like maybe CICD or something >> Yeah, like use use OX length, use OX format. Uh you know, set put
just like encode it into a party of workflow. So, the agent like I think the linter is actually not just linter in general, just like automated verification loops. Right? Because uh you want to make sure there are checkpoints where after the agent has written some code, there's going to be some quality assurance. Either be linting or like there's also the cross-agent code review thing where you'll let
Codex review Clawcode's code and then vice versa. it's funny cuz if you tell Clawcode like this is code written by Codex, it'll just like be extra harsh. And I don't know if people saw my tweet the other day cuz I had a big refactor done by Codex. Then I asked Clawcode to review it and Clawcode was like, "This is This is like no issues found. Great Good
to commit." I'm like, "Yeah, but what if I tell you this is done by Codex?" And it just like went extra hard. Yeah. >> I Yeah, I just wanted to complete because I I I totally agree with with what you said that I I really think that there is also there is a new spot now for I mean, you were making a bit fun of it, but
I I am personally convinced that there is a spot for tools which will review what uh the code which is AI generated and probably that's something which evolves. And maybe why not like having different different agents like you know, cross-agents reviews. I I don't know how what it will look look but I'm I think there's something which will be developed at some point. Especially, I think the
the market will need it as well because currently it's a bit harder to to sell to stakeholders that even the fact that we want to do quality code because there is also this idea and that's something that we can think about. More and more stakeholders are asking the question like, do we still need quality code if we are just validating everything, right? So, I think at some
point if we still want to be able to propose some quality code at least to to have the arguments for, we need to be able to say, "Okay, we can do some quality code but maybe with lower cost." And probably that would be a good selling point for developing this kind of tools. So, yeah, that was my my conviction that it doesn't answer to the question which
was on actual tools now, but I think that's something which will which might evolve soon. I think also when you do the agent to agent code reviews, you have to also know which one is right because the agents are going to say, "No, this one is right. This So, you have to be knowledgeable enough to say, "Actually," or question it. Sometimes like, "Are you sure because um
Codex said this or whatever." Or you don't even have to say Codex, but "Are you sure because and then like let the agent basically say to you, "Ah, actually you're right. I made a mistake." Or "No, I'm sure because cause." But talk to the agent. Use the agent like as if you were talking to a another developer and have those conversations because then you'll come back out
with maybe a better um a better idea of what is right. One thing I would add is that we have to change our expectations of what productivity and uh what what KPIs we look for in our developers and developer teams. So, amount of code written, for example, is not a good guide for Like, it's but but but particularly because now it's really easy to create a lot
of code. So, don't judge people based on the amount of code. That's something that they can absolutely game in 1 minute. If you're judging people but based on the amount of code, that is going to lead to that's going to reward the wrong thing. Um also, don't judge people necessarily based on velocity cuz again, it can be easy to 20 things by just having 20 different tabs
open. So, you kind of have to focus like what actual code quality is to reward and incentivize it. I think that is a like a a really important like Then I think I also think the most effective people at doing things well at with LLMs will be people who are LLM skeptics. Um and I think everyone should be an LLM skeptic in the same way as you
should be a skeptic of anything you're asked to review. Um that I mean, to be fair, if Evan opened a PR to Knox, I would basically just be like, "LGTM. It goes in." But I shouldn't be, right? I should be I should be like reviewing that that thing quite carefully. And you should do in any situation, no matter how much you trust the person who's opening the
PR. And that goes much more so for LLMs. Even once you've tuned the harness and you've given the prompt and you you're pretty certain it's all great, you should still be so skeptical when ever you're reviewing anything. Not not Just because you you should you always should be. And that position of doubt will lead you to ask the questions Debbie was saying and will lead you to
get to the point where like Evan, you're making sure that every line of code that's making it into your code base is at your level of code expectations. The one thing you can't afford to be is become lazy. Like a lazy reviewer. "Oh, amazing. There are lots of tests. Good. they're all green. This is great. Just the other day on Blue Sky, Dax uh shared uh the
what he said was the craziest example of testing code he had ever seen, which was basically uh generated and an LLM said, "Read file sync um the source of his CLI, expect that source should contain this line." Uh and that was its test for if um it would print the help test text if the user used it. Totally bonkers, but it will pass, right? Um I once
uh I was I wanted to do a refactor from one form of CSS parsing to another. It was an area I knew quite well, and I wanted to use it as an experiment for testing um agents, and I I said I instructed the agent to migrate to use this form of parsing, and it did it, and the tests were failing, and then I pointed this out to
it, and it carried on, and it finished, and everything was passing, and it was beautiful, and it hadn't changed the tests at all. I thought, "This is great." You know, it hadn't changed the tests, but it changed the library code to detect if process.env.vitest was set, and in that situation, it returned a different result. that's some dark magic there. Like, you have to be so skeptical, and
I think being skeptical is it's it's it's table stakes, right? That's how you'll get the most out of LLMs. >> I think this is extremely on point because, you know, in I I think it's very easy when you uh start using AI extensively, and I have experienced myself in the past is it's so tempting to feel like, "Oh, I can just boost my productivity by like opening
up more sessions and just doing multiple things in parallel." and I quickly realized even with the agents being able to do things in parallel, your attentions is still limited, right? Uh so, when I run like juggle three sessions in parallel, I start to realize the context switching is just like starting to like there's a limit of how how many sessions you can juggle in in parallel, right?
So, whenever I see someone like talk about Twitter like say I have like 20 sessions running in parallel, I'm like this is just slop. Like this is this would only produce slop because as a single person, you won't be able to meaningfully steer and inspect the code cuz like when I when I'm doing the the stuff like frontier models have gotten scaredly good, but there are so
many instances where I'm like just looking at the code it changed, I'm like I just like interrupted and I'm like wait, why why did you do that? And the common response um so, it'll explain it and then like there are so many instances where even with the best models today, the model is like oh, I see like I see the full picture now. Like you're absolutely right,
right? There are so many instances where like uh if I didn't interrupt it and like ask that question. And sometimes it'll it'll be like yes, you are right to push this, right? It models can genuinely make mistakes. It can and if you're not good at context management, when the context still full, it starts, you know, to to get dumber and make hallucinations. So, I think human in
the loop being skeptic is still extremely important and your is also a resource. Like as a human, you also have limited context window. So, juggling multiple sessions will also fill up your context window so fast and you become less effective in steering AI when you have too many parallel sessions open, right? So, I think it's uh And then there's another problem is like you we tend to
get lazy when the agent is working in the area you are not self familiar with, right? So, in a in a area like in a code path that you are very familiar with, in a domain you are very familiar with, you can very easily catch like, oh, wait, why are you doing this? This is wrong, right? And you can steer the AI very effectively. But when the
AI is doing work in the area you maybe is slightly out of your, you know, comfort zone, it's very easy to just like, well, I don't know. You are I trust you're doing the right thing and you just let the AI run wild. And then but in the eyes of another expert who's actually, you know, know the domain well, it's probably not doing the right decision. So,
I think it's still extremely important for you to actually know the domain that you're working even when you're using AI. You need to know the domain well to be able to steer it effectively. And you need to stay a skeptic. You need to manage your own contacts window well. Otherwise, you know, these little mistakes piles up and the slopification will slowly, you know, creep creep up and
you have to keep that under control. When you mentioned abso- you're absolutely right. It reminded me of one story when I was using I think it was Copilot and I asked it to create one thing which I wasn't satisfied with. So, I was prompting more to get more the result that I will be satisfied with. And that the response were was you're absolutely right, but I think
it was the first case for me when I got the response that the AI wasn't satisfied and the response was I'm getting frustrated with this bad quality code. But the thing is that the code was created by AI in the previous step. that's another type of You're absolutely But, uh we have another question from the audience, which is a bit um different from in terms of uh
code quality, because it's about meta frameworks being acquired by enterprise companies. So, we have Vercel, Nuxt, we have Cloudflare and Astro. What are your thoughts on that? Daniel? Well, I mean I would say Nuxt has not been acquired by any company. Nuxt is an independent framework, just to be clear. I'm employed by Vercel, but that is not the same as Nuxt being acquired by a company. And
I think the same is true of Astro. So, I think Astro uh core team members were hired and the Astro technology company was acquired, but that's not the same as the framework being acquired. I think the Having said that, the maybe the question is, is it a good thing for big companies to be backing open source projects? Um and I think it's a great thing for open
source projects to be backed by companies. I celebrate with Astro. Uh I'm sure they celebrate with us. Like, that's great. This is how This is partly how you see open source sustainability. Um and the moment you start seeing this as um open source is its own world, right? We're And it's it's um it's a world that needs investment. It needs investment of time and love from maintainers
and uh contributors. you know, that can't happen on its own. It happens because people are employed elsewhere, because people um have significant others who take on uh things so that their partners can do something they love. Like, there's a lot of people who sacrifice to make open source happen. Um I love seeing companies do it. I even I love it even more when like multiple companies support
the same project cuz I I think that's a better sign for sustainability long term. Like when you when you're looking at the sponsors list and it's not just one company, uh that's that's even better. I'm glad for example on the next core team that we have representatives of at least three different uh companies like uh Julian at Chromatic, uh you know, on it for sale. uh Lucy's
at Prismic. Um And then we have uh Alex at 4.0. Like that's that's really good. I would like to see that kind of thing even more. Um but one thing I definitely would want to avoid is the idea that you can just pick up a meta framework and and say, "Oh, it's now in this company's camp." No, that's not good for the framework. It's not good for
open source either if people start like creating uh needless division, I think. >> Yeah. So, first of all, I very much agree on that open source needs to be funded in some way, right? Uh when you when you see frameworks staying independent, um it's not easy. It's it's very difficult to make independent open source projects sustainable. Uh if we look at the whole landscape, there are actually
very few examples of like independent meta frameworks being financially sustainable. Remix technically got bought by Shopify, right? Um I think the um the only two exceptions that I can think of, like Vue is still independent, right? It's not attached to Vuesax. Vue is financially completely independent and it it is sustainable. But, people use Vue as a very extreme outlier. And I still think Vue is, you know,
a rare example that every time people ask me how to make their projects, open source projects, sustainable, I find it really hard for them to replicate what Vue does, right? And I think But, I I think a recent good example is TanStack. TanStack is actually doing very successful, like, independent, multi-company sponsoring the same project. But, even with that, you know, it's mostly just Tanner. Tanner is the
only person working on it full-time. And everyone else working on TanStack is part-time. And um And that is also part of the reason why I started Vue Zero and raised money is independent open source through sponsorship scalability has a very, very obvious bottleneck. It plateaus at a certain scale. And you won't be able to sustain, say, you know, work that we're putting into OXC plus Rowndown plus
Vue plus Vue Test. Um and all that. But, we're doing the whole toolchain, right? That's bigger scope than meta-frameworks. But, the point to get through is um it takes a lot of full-time effort to maintain high-quality open source software. And doing it independently through only sponsorships is extremely difficult, right? So, in a having companies backing open source that is a good thing, right? On the condition where
the the companies are doing it in good faith. Because uh what we're worried about is not big companies buying frameworks. And I don't like the I also don't like the frame of buying the framework, right? Because um it's more like the companies have decided to support the people working on those projects. Uh what we worried about is the so-called enterprise inch certification, right? So, if the company
who, you know, uh acq- acquire the team decides to do things uh that would hurt the neutrality or hurt the quality of the software, I you know, the community will notice. Community will call it out. So, I think the the lucky part of it is all these companies doing these things, either Versel or Cloudflare, they're fully aware of this fact, right? So, it is really up to
up, you know, up to us, up to the users, up to the communities to hold these companies accountable for what they do to these frameworks. So, um and I think I think the good thing is this is like everybody understands this. So, and these companies are not stupid. When they, you know, acquire the team, they know like they did it in order to, you not to ruin
their own reputation, because if Versel force the Nuxt team to do something that's bad for its users, then everybody gets mad at Versel. Uh and Daniel will probably just leave. So, right? There's a power of balance here, right? I think that the power dynamics ensures that these companies won't do stupid things, and that's really important. And that's, you know, that relies on all the users, all the
community to just like keep their eyes on these and making sure these companies are doing the right thing. Um And I think, you know, I think it things are going, you know, decently well after these acquisitions, like at least in the in the Nuxt case, right? So, everybody's quite worried when it first happened. I got so many questions, but I think it's turning out to be a
good outcome, at least for now. So. Yeah. Sounds good. One thing I would add is I get I get I get this question a lot for obvious reasons. Um and I agree with everything Evan said, by the way. Um and I understand why we approach this from a question of skepticism and worry. Cuz I absolutely would, too. If I were a user of a framework and that
framework suddenly four of the core team were hired by this company, I would absolutely quaking in my boots, right? I would want to know. So, I understand. But at the same time, if we want this kind of thing to continue to happen, we also need to give these companies credit for what they're doing, right? We need to We Yes, we need to be watchful and vigilant and
all of that. We also need We need to applaud, too. And we need to say, "Well done." I I I I think it might be worth saying that as well. More companies should be supporting. Maybe not by just outright buying the the projects, right? But more companies should be supporting these projects. And they should be supporting for good reasons, not just because they want to exert control.
Makes a lot of sense. >> Now I have the question for the skills that you think will matter the most for front-end developers nowadays. I find I find the topic of skills a bit ironic cuz like skill is like all the rage >> uh right now. And I was joking the other day that people writing skills nowadays self-distilling. Like reverse-distilling themselves into the models. Like we're writing
these skills and the to help the models do the job better. Uh in a way, like skills is another form of op- open source, almost, right? Like I think the pref prefgen, like the way we're doing it is like we open source the code, we open source the framework, we open source the library. Now people are essentially open sourcing their expertise by writing agent skills. Uh even
like designers, if you look at like how uh Adam from Tailwind is working on this his new project called ui.sh. It's like open source to design skills that put you put it into your agent. Now your agent magically does better interfaces and front-end code. Yeah, sorry. The the question was uh >> Just keep forgetting. >> It was more about uh you know, soft skills, tech skills, maybe
>> do we need, right? Um Unfortunately, I think um so the importance of a lot of things that can be replicated Uh so the the common bar will just be raised so high by the agents and the the way we are like just sharing these base skills, right? So it gets harder for you to differentiate, right? But I think ultimately the way you differentiate yourself is what
can you provide on top of the the things people already share. It's kind of like open source. I don't It's like nowadays being being able to work on top of an open source framework is kind of a given skill, right? So in the future, being able to know how to best utilize AI to do your job becomes a basic skill. And then you need to further differentiate
yourself on top of that. And what that really entails, I honestly can't really tell right now, but I just know that, you know, being able to use whatever everyone else is using will become a basic requirement. I think also it's not about being more productive anymore because now we know we can be productive, But, how can we create something that's valuable? How can we come up with
the things cuz AI's not going to come up with everything. We have the ideas, the mindset. We got to play around with the tools and then say, "Okay, this is something that we need to create or should be created or something that people will use." And that's the hard part that we need to That's a Well, um I would say that um and also it comes back
to what you were saying previously. Uh that uh right now maybe even more than before like we still need to have like very strong technical skills to be able to differentiate as you said um with agents. And uh especially I really believe that agents will become uh more and more um better and better. And uh our job will will evolve uh to steering agents and also being
able to uh control the output that they produce. And therefore uh yeah, um keeping like um this curiosity uh the willingness of understanding what uh um uh these technical skills are I think it's super important. Also, I think there will probably be less developers on the market at some point. Uh even so maybe through AI we may have more business opportunities and then more jobs. Um but,
I think the trend is uh is so it's moving so fast that developers who are just like write coding, which is something that which will is is possible to anyone, uh will tend to uh have less job opportunity and like yes, possibility less possibility later. So, yeah, to me the most important skill I would say right now is and uh it comes back to what you were
saying is to keep this ability of um understanding things. Like not being lazy. You have to to take back the the term that you were using uh earlier. I think um I'm going to add an uh couple Uh one um emotional intelligence and interpersonal um We can be very focused on tech and our but actually one of the things that will take you much further is to
understand how to work with people on your team because you're still going to be working with them even if your own productivity is being increased by an agent, you're still going to need to be doing doing that. And I think that is one of the things that sets apart truly exceptional engineers as they work well with other people. They form great And that is not changed. That
is absolutely the case was the case before. Two, I would add attention to detail. I think one of the things that has always set good front-end engineers apart is that is their ability to be laser-focused on something that like perfection. They don't want 99, they want 100. They don't want it's nearly right. Those pixels are nearly in the right place. No, they want it is that this
is exactly what it should be. That people they care about alignment. Like you you care about all of this. That doesn't go away when you have an LLM, it becomes even more important because you have to be able to evaluate that code. I would say critical thinking remains absolutely crucial. It always was. Programming is just thinking and then you're expressing that that thought in a particular language.
You still have to have that absolute clear critical thinking skill. And the more more clearly you can think, the more clearly you can do anything. Um whether that is evaluating code, prompting, what whatever it is, critical thinking is part of the answer. Some of the other new things though, holistic thinking, understanding how everything works, maybe cross-domain work, so the ability not just implement a design, but come
up with it. Not just >> to yourself a bit of a product manager and understand the purpose and the point and actually be an advocate for what it is about. Um that's going to absolutely set you apart as a front-end engineer. Um maybe some of the silos that we've been operating in will be less significant. Uh and we'll be able to do much more like across uh
the team. And by the way, all of these things are would be great skills to have with or without uh LLMs. But I I do think those are some very important skills coming forward. Yeah, I want to play resonate here. It's you need to be mindful. Like think about So with AI, it's very tempting to you feel like you can build anything, right? But now it's getting
more important to actually think about like what you should build and what you should not build. and then the other thing is the other important thing is I think uh with AI, the boundary of the the definition of like front-end engineer, I think these lines are going to get blurry over time. Uh because with AI, honestly, like your room to grow is enormous. I don't think you
should we shouldn't, you know, keep sort of framing yourself as I'm only a front-end engineer because honestly, I just like even when I'm working with AI, uh sometimes if I go into a territory that I'm not super familiar with, I just learn on the spot because you have literally the most powerful AI that people human have ever created to sort of teach you like this like whenever
the work you your work touches upon a domain that you're maybe not previously familiar with, it's a perfect opportunity to learn and grow. Right? And you should grow beyond like what your your comfort zone is. Just leverage AI to turn yourself into, you know, some uh you know, someone who are more capable of doing more things. Yeah. Okay, we unfortunately run out of time for this discussion.
Thank you very much for participating. Give a huge round of applause to our amazing panelists.
