Engineering video
1:30 · 15 August 2025
Developers should slowly transition to full-stack roles because AI finds it extremely hard to work with ambiguity, large distributed systems, and constantly changing real-world environments.
Hear it at 0:00 →Humans act as the drivers who design systems, handle competing goals across multiple platforms and teams, and tackle the true bottleneck of software engineering: defining and understanding the problem rather than just writing code.
Hear it at 0:17 →UI right now in the front end. Make sure you slowly start moving towards the full stack. It is extremely hard for AI to work with ambiguity or to work on systems that are very big or very distributed. almost impossible for you to keep some coherence. Because again, you cannot get it think across all those different possibilities. Hey, you can leverage AI, but you are designing the system. You are the driver of the changes.
So you have all these moving pieces in terms of what the code base looks like, what the infrastructure looks like, what the delivery, kind of the pipeline looks like, what is the current backlog? And then there's the the other layer of what other people around me working on, what are the other teams doing, what are the complementary products that we integrate all the time. And you have all these different platforms.
You you can ship to the browser, but then you have the back end, you have the databases. And so humans are really good at dealing with these incomplete situations and be able to kind of paralyze these competing goals. And I think that's something where yes, if you would fed all the context in the world uh to the AI, it might be able to come up with a decent solution. But again, we live in the real world where everything changes very fast.
You need to improvise. And I think a lot of people are making this one-to-one comparison between the AI writing some some code and then what the software engineer does. And what every experienced software engineer knows is that the code was never the bottleneck. It's rather about understanding the problem, defining the problem, prioritizing, estimating, and then finally, you get to write some code.
