YT YouTube2Text

YouTube2Text → Transcripts → Software Engineers have a once in a lifetime opportunity

Software Engineers have a once in a lifetime opportunity — Transcript

by exit node · 4,083 words · 585 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Hello. The great AI reset is upon us and
0:02many people have decided to go with the
0:05AI dumerism flow and just say that
0:08they're going to get unemployed or
0:09kicked out of a job where there's not
0:10going to be any more space for them to
0:12improve or solve problems in software
0:14engineering where I have found that the
0:16reality is quite the opposite. In fact,
0:19there is a lot more new problems to
0:20solve. A lot of problems that do not
0:22have a Stack Overflow, do not have a
0:24dedicated YouTube page solving that
0:26exact problem. And in fact, there is
0:28just so much opportunity here. And this
0:31is by far the greatest opportunity in
0:34software engineering we have had in the
0:35past 40 years, literally since the punch
0:37cards were invented, man. Okay. And I
0:40really want to convince you that the
0:42reality is so much more brighter than
0:44you might even consider it to be. Let's
0:46start with a quick example from my own
0:48life. I'm a software developer of 15
0:49years. Previously I was director of AI
0:52but before that I was a software
0:54engineer at ARM and I went through many
0:56positions there from junior engineer all
0:59the way through senior manager and the
1:01reality is that over those 12 years at
1:04ARM I felt like I was on top of my game.
1:07I was on top of everybody because my
1:09knowledge was constantly at the tippy
1:11top of my peer groups and hence why my
1:14jump through the different career ladder
1:16loops was so quick, right? I was proving
1:19myself to know more and to be dedicated
1:21to new technology so much more than
1:23anybody else around me. That is up until
1:25I started looking for a new position
1:27after 12 long years of being in one
1:29company. Yes, moving through the ladder
1:30but not really going anywhere, right?
1:33And as soon as I started looking
1:35elsewhere, I started to realize that
1:37first off, technology has moved a lot
1:39farther than you might even consider,
1:41you know. And even if I was the top 10%,
1:43I've always aimed to be the top 1% if
1:45not top one, right? So that has always
1:48been my goal and the reality turned out
1:50to be a lot more grim than I anticipated
1:52it to be. In fact, turned out that most
1:55people had shifted everything to be web
1:57applications. For example, everything
1:59had moved over to the web. JavaScript
2:01has had so many different libraries
2:03released. Different tools and languages
2:06were already obsolete on the outside
2:08world, but internally and in fact in
2:10other big corporations, these tools were
2:13being used non-stop. That was the day
2:15when reality really struck with me and
2:17it said, "Shit, dude, we have fallen
2:19[ __ ] behind." you know, and
2:20especially when you start getting job
2:23requirements that have weird tech on it
2:26that you do not have the slightest idea
2:28what that means and you have to Google
2:30it. That is when you know you're in the
2:31[ __ ] And luckily for myself, I had the
2:34incredible ability to have more than
2:36enough headroom and enough lucky
2:38opportunities to carry me through the
2:40interviewing process and to really
2:42manage to more socialize my way through
2:44interviews rather than conquer them
2:46through technical abilities. But since
2:48that day and since getting my new
2:50position as a director of AI at my last
2:52company, I have said to myself, I am no
2:54longer trying to be the top 10%. I am
2:58never going to be sub 1%. And since
3:00then, I have been on top of the trending
3:02technologies. It was software
3:04engineering for just a tiny tiny little
3:06bit. And honestly, for the past 2 3
3:08years whenever Chad GPT released, I have
3:10been on top of AI myself. And the
3:13opportunities that I saw have been very
3:15interesting. having spoken and
3:17interacted with a lot of engineers from
3:19Anthropic and OpenAI and also a lot of
3:22professional software engineers from the
3:25big software companies in the US as I
3:27was working for the US government. So I
3:29had a lot of people interested in
3:31getting to the US government go through
3:33me. So I got to meet everybody from the
3:36cream of the crop for quite a few years.
3:38And at that point I started to realize
3:40that there is such a large gap between
3:44normal software engineers, open AI
3:46engineers and anthropic engineers and
3:49really people who have been stuck in the
3:51profession of software engineer they got
3:53into it purely for the money right and
3:57I'm sure you know many of these people
3:59perhaps you are one of these people in
4:01which case keep on watching to be honest
4:03with you but a lot of these people that
4:06have gotten into software engineering
4:07for the money are now realizing that,
4:10holy [ __ ] I have to do research to stay
4:12on top of the things. Oh my god. And
4:15yeah, the reality is yes, you absolutely
4:17need to stay on top of things. And not
4:19only do you need to stay on top of
4:20things, but you have to stay on top of
4:22things a lot more than you did
4:23previously because yes, things are
4:25moving very quickly. Not necessarily
4:27because AI is pushing new developments
4:29very quickly. In fact, I think the speed
4:31that AI is developing at is just a
4:34result of the technology being so new
4:37and all the new developments. You might
4:39notice that a lot of them end up being
4:41regressed back like that anthropic blog
4:44post where they say you shouldn't have
4:46any prompt management, context
4:48management, whatever management. You
4:50just have to send one prompt and let the
4:52model do its thing for you. And the
4:55reality is that is just not how things
4:57are done, man. And the sad reality is
4:59that yes, you can give a lot of your
5:02projects to Opus or the latest soul or
5:06whatever and Frontier model you want to
5:08use, but those models are simply not
5:10going to be able to perform at their
5:12best if you give them a huge project.
5:15For example, a client that I'm working
5:17with currently has a project that he
5:20created himself as a solo developer
5:22without any past experience or knowledge
5:25of the technology. The size of his
5:27project is rivaling that of my own
5:29company of over 20 people. And he's
5:31struggling with the fact that it's not
5:33capable of making small changes. And
5:35small changes that previously used to
5:36take a couple of seconds now take hours
5:38and often times end up breaking
5:40something else in the stack. And that is
5:41simply due to the simple facts of
5:44context rot. Models have their own
5:46context limits. And models have their
5:48own context windows. And as soon as
5:50those windows end up overlapping a
5:52certain percentage or a certain quantity
5:55of tokens in it, the models just end up
5:58folding and falling apart. So that is
6:01something that we need to keep in mind
6:03and we need to be very knowledgeable and
6:04careful of. But alongside this, there is
6:07a lot of other factors that we need to
6:09also consider. Like for example, the
6:11facts that when working with large
6:14libraries, more often than not, it is
6:16better that you deploy targeted focus
6:20changes and you give a lot of context to
6:23the model. Not necessarily through a
6:24prompt, but you might give it access to
6:27a knowledge base or something similar
6:28which you should be collecting
6:31information there yourself and should be
6:33harvesting information from meetings and
6:36discoveries that the agents have made in
6:38the past or documented information that
6:40is all collected in this library and
6:42that library should then be fed into the
6:44model itself. Now that you could do
6:46through a simple pipeline. So how I
6:48myself solve this problem is I have an
6:50agent called the scout agent which goes
6:52and looks and makes available all the
6:56information my library of knowledge
6:58again from tickets confluence etc makes
7:01it available to the model itself and
7:03whenever the model needs some additional
7:05context to a query or a request that I'm
7:08making it goes and fetches that
7:09information very efficiently from the
7:11stored library and then it is able to
7:14make informed decisions that is one
7:17factor of
7:18And another factor is the simple
7:20architecture of my repositories. All of
7:24them are split into services that are
7:25individual, fairly small. Some older
7:28ones I've started to convert slowly one
7:30by one. For example, for the Muse
7:32hackathon that I've participated in over
7:35the past week and now I continue and
7:37we're going to wrap up next week with
7:38it. I have specifically from the very
7:41first prompt about that project I have
7:43started building it in a very split
7:46dedicated manner where in fact I've kind
7:49of taken it to the logical extreme which
7:51is the agents themselves that build it
7:54each one has a responsible part of the
7:57codebase and no agents are going to be
8:00touching each other's work and that has
8:03actually been working out quite nicely
8:05because then you don't end up having for
8:07example if you imagine four blocks of
8:09information here, okay? Or four blocks
8:11of code that are not connected but they
8:14are interacting with each other with
8:16very simple contracts. If you have a
8:18change that is breaking for all four of
8:21them, i.e. all four of them need to
8:23account for this change a normal LLM if
8:25I would feed the whole library into them
8:27and not have this agentic structure. The
8:29LLM chances are not zero but also not
8:33100%. It's kind of who knows because
8:36LLMs themselves are gambling machines at
8:39their core. So, you know, take this
8:40example with a grain of salt. But the
8:42fact that it can happen means that it
8:44will happen, meaning that you've
8:46probably suffered from this without
8:47realizing it. But getting back to the
8:48example, you have four pieces of code
8:50and you want to deploy a breaking change
8:52to all four of them. A normal LLM might
8:55end up doing the most disgusting change,
8:57which would be put something right in
8:59the middle, break all of the individual
9:01for your services that you've nicely
9:03organized and separated yourself, and
9:05it's just going to go with the simplest
9:06solution that is able to make work. It's
9:09going to write tests for it, and it's
9:11going to just hope that it produces
9:13something good on the end. And in the
9:15LLM's eyes, producing something good
9:17literally means, hey, it passes the
9:20tests. That's good enough for me.
9:22[laughter] So, if you end up doing
9:23something like this, especially with a
9:25very simple and small tight prompt, it's
9:27absolutely going to flop on its belly
9:29and you're not going to be very
9:30satisfied. And you're just going to come
9:32back and say, "Oh my god, they nerfed
9:33Opus or they nerfed Soul." And it's
9:35like, well, no, that's not actually what
9:37happened. You are just giving these
9:39models a lot more responsibilities than
9:41they are capable of handling. Now, these
9:43are things that you can go and test
9:45yourself. Of course, everything that I
9:47say is absolutely testable. Another
9:50element that I have in my day-to-day
9:52coding is for example the fact that I
9:54have stopped largely reading code. So
9:57yes, I know this is kind of a oh no,
9:58what are you doing kind of point that
10:00I'm making, but hear me out. I have
10:02built out my tools and pipelines so much
10:05over the past couple months that I have
10:07collected so much confidence and faith
10:09in everything that they are doing that I
10:11don't really feel the need to go and
10:13really read the code anymore. I just
10:15trust the outputs and I trust the tests
10:18and really the vibes checks that I get
10:20from the other end because I use
10:21everything that I end up building and
10:23that has been mostly my testing that I'm
10:25doing. You know, for example, one of the
10:27big projects I'm working on at the
10:28moment is a large epic with UI changes.
10:32Like it's just a lot of new
10:34functionality that the UX team cooked
10:36up. I fed all of this into the LLM. I
10:39gave it a specific pipeline that I
10:41created just for this ticket and I asked
10:43it to go and for example test everything
10:46in a Chrome browser, verify all the
10:48changes, kick back any errors and just
10:50fix it by itself and essentially just
10:52keep iterating onto its own work up
10:55until we're actually ready to ship. And
10:57then finally, I have been running it now
10:59for a couple of days and it has been
11:01producing incredible results, incredible
11:02PRs and just the quality of output is
11:06very very good. And I've tested the
11:08first couple instance. Then I'm like,
11:09well, I saw what it did for three out of
11:12three. Everything was basically perfect.
11:15Why would I test the rest? You know, so
11:17that is basically what I've been doing
11:18with this example. I really want to
11:20drive the point of confidence home with
11:23you. Okay, AI and LLMs and the future of
11:25software engineering really seems to be
11:28all about confidence building. I didn't
11:30start like this from day one. In fact,
11:32how I started was writing emails with
11:35the lamps and then slowly I started
11:37writing individual functions then in
11:40whole code files. Since then it has
11:43grown, you know, and LLMs have also
11:45improved with their capacity and
11:46abilities over the years. But for
11:49somebody starting off nowadays, I would
11:51ask them, hey, just first off, make sure
11:53that you know how to program, right?
11:55Make sure that you understand the
11:56fundamentals of software engineering.
11:58Make sure that you always have a plan
11:59for the big picture project that you're
12:01trying to build. And as soon as you
12:02start going out of bounds of this
12:04project, you either need to start a new
12:07project or go back to the design and
12:10make sure whatever you're building fits
12:12onto the existing model itself. It has
12:15to be bolted on rather than squished in
12:17there somewhere, right? You cannot be
12:19doing that. So that is another thing
12:21that I would do. Go fix the blocks. From
12:23there, I would try to understand how the
12:25[ __ ] LLM actually work, right? I would
12:27understand prompts, contexts, skills,
12:29tools and MCP servers etc. And only once
12:34I have the understanding and knowledge
12:36of the latest cutting edge technology in
12:40terms of LLMs, I am going to feel
12:42confident enough to start building out
12:44tools for myself and I will be checking
12:47obviously the output of everything
12:48probably reading all the code for quite
12:50a while up until I am sure that my LLMs
12:53and my instructions are always concrete
12:54enough and work well enough for the
12:56specific targeted space that I'm working
12:59in. For example, for myself, it's the
13:01micros service in the energy sector, you
13:04know. So, I've had to build a lot of my
13:06tools specifically targeting
13:08microservices,
13:10electricity sector, and also a couple of
13:13other things that we do at work that I
13:15don't want to mention out loud. But
13:16basically, for every single thing, I
13:19have a knowledge base entry. I have a
13:21lot of conversations and meetings, you
13:23know, from onboarding meetings that I've
13:24had with the team and also a lot of
13:27findings that I have collected over the
13:29years with the LLM. And once I have this
13:32understanding, I will jump in, write
13:34some code, but then I will slowly start
13:36to incorporate each one of these
13:38individual factors in my workflows and
13:41do some targeted personal projects that
13:43revolve around these individual tools.
13:46And the whole point here is that you
13:48slowly compress all of the new
13:50understanding that you need to have. Of
13:52course, I'm assuming that I'm talking to
13:54somebody that has barely any
13:56understanding of code and LLMs or you
13:59might just be getting into the
14:00technology. You might still be using
14:01clot code. And I have not mentioned this
14:04yet in this video, but if you're still
14:06using clot code, almost certainly you
14:08should move over to something else. plot
14:09code is fantastic out of the box tool
14:13that you could use, but it's very much
14:14so like the old Visual Studio, not
14:17Visual Studio Code that most people
14:19know. I'm talking about the old compiler
14:21from Windows for C that basically
14:24everybody had to end up using,
14:25especially if they wanted to write C. It
14:28is just a proprietary capture trap that
14:31a lot of people that I interact with in
14:33the comments are convinced that it is
14:34the best tool out there. And the fact is
14:36that it's just not. And you can use
14:38Entropic Motors in other harnesses like
14:40OM without getting [ __ ] banned. Okay,
14:43please understand this. Please use it if
14:45you're not yet. Just start using open-
14:48source tooling like it's 2015. Okay,
14:50just go back in time and understand and
14:53appreciate the fact that there is so
14:55much strength in open-source tooling
14:57especially nowadays because you can just
14:59go and play around with all the tech
15:00man. The fact is that for OM I have a
15:03couple of local hacks that I've deployed
15:05that I reapply every single patch that
15:07they push from top stream to bottom
15:10stream and I patch it myself because I
15:12really want to have loading bars in all
15:14of my different sessions for example and
15:16that is not available out of the box. I
15:18don't know I've requested as a feature
15:19I'm still waiting to what what's
15:21happening here you know [laughter]
15:22Ken where's my patch? So anyway, the
15:24point is that using open- source tooling
15:27gives you the ability to be in full
15:29control over your work. Now, another
15:32thing that you need to please understand
15:34and appreciate is that in your company
15:36and your environment, you might be the
15:39top dog of the LLMs. You might be
15:42getting everything about the LLMs right
15:44and kicking everybody's ass and being
15:46like, "Oh, you're still doing tickets
15:48one by one. Well, check this out." You
15:50know, you can definitely do that. Or,
15:51you know, it might be even worse and be
15:53like, you're still writing emails by
15:55hand. Have you heard of cloud code? You
15:58know, if you have colleagues like this
15:59where you need to have these
16:00conversations with them, just please
16:02don't think that you're at the cutting
16:04edge of technology. You might very well
16:06be in your company, but you need to
16:08understand that globally and really the
16:10marketplace that you are competing in
16:12unless you're working for a local
16:14market. What software engineer works for
16:16a local market? You know what I mean?
16:17Like we are competing for the job market
16:19at the global level. So we need to think
16:21globally here. And the fact is that
16:24there are a lot of opportunities for us
16:26that are available out there that
16:29there's some giant bats over here, man.
16:32Holy [ __ ]
16:36So yeah, we spoke about the greatest
16:38opportunity in 40 years and hopefully
16:40now you understand why I keep framing it
16:42as such. The fact that context rot is
16:45still unsolved. The fact that skills
16:47agents and similar other tooling are
16:50also slowly becoming more mainstream.
16:53Having more tools and other libraries
16:55built around them should give you more
16:57than enough confidence with your future
17:00learning materials. And my honest advice
17:02to you is to just keep on learning and
17:04keep on practicing. Right? All of this
17:06depends on our ability to stay
17:09maintained and to keep on maintaining
17:12our skills and experiences. And more
17:13important than not and more important
17:15than anything else is the ability to
17:18produce personal benchmarks and to start
17:20evaluating results of our tools against
17:24the results that we are looking for and
17:25not the results that slowly or
17:28artificial analysis or whoever else is
17:31out there producing for us because they
17:32are generic. And the work that LLMs are
17:34capable of producing for us is so much
17:37more personal and so much more freeing
17:40than anything we've ever worked with
17:42before. And until we get to a point
17:44where either the models are smart enough
17:46to do all of these things by themselves,
17:49I don't personally see where that future
17:51is. Honestly, there was a future like
17:54that coming up. We honestly wouldn't be
17:56getting stuff like the dots and similar
17:58coming out, but instead we'll have a
18:01couple of more focused pushes on to
18:03further LLM production like brand new
18:06models with far more focused workflows
18:09designed in them. But my personal
18:10feeling is that models are now becoming
18:13so bloated and so big that they can only
18:15be centralized and generic in function
18:19rather than being able to become
18:22specialized and fine-tuned because the
18:24markets are now starting to get so
18:26splintered that one big company can
18:28realistically not manage each individual
18:31company's individual needs. Right?
18:32That's why Shopify is pushing for
18:34fine-tuned models and other big brands
18:36are also starting to shift in this
18:38direction where they've have specific
18:41agentic workflows available to them and
18:43they have had them for a little while in
18:44production and now they're starting to
18:46look for opportunities to fine-tune and
18:48modify and adjust all of them to start
18:51saving money, start executing better on
18:53their specific concrete use cases.
18:55There's so much there. This is just one
18:57of so many slices that different people
18:59have started to head into. And our job
19:03as software engineers is to just keep
19:05looking at our opportunities right in
19:07front of us. If you're employed, if
19:08you're looking to become self-employed,
19:11start looking at alternative options in
19:13front of you. Start talking to family.
19:15Start talking to friends. And just pitch
19:18them something for free. And as time
19:20goes on, I promise you, you're going to
19:21end up seeing fantastic results. As have
19:24I. pitching to my dad, to friends,
19:27family. I already have multiple clients
19:29signed up from the YouTube channel, just
19:32people reaching out to me without me
19:33advertising anything. And also, I found
19:36a ton of people in real life. And I am
19:38getting slowly to the point where I can
19:40become self-sufficient purely off of AI.
19:44So, the fact that some people seem to
19:46think there's no bread in AI are
19:49brothers, please, is absolutely not the
19:51case. Very few people even understand
19:54what skills are, what harnesses do, what
19:57agents are, and how they can be
19:59programmed. Barely anybody has started
20:02looking at open source solutions for
20:04tooling yet. There is so much there. And
20:07the first founder benefits always apply.
20:11And this technology is no different than
20:13opportunities we've had in the past.
20:14Think about pre-DevOps years, right?
20:16When DevOps was just becoming to be a
20:18term, but nobody really knew what it was
20:20going to be. Docker was just a sapling
20:23of a project compared to the Titan that
20:25it is now. And just think about Docker
20:27containers have maintained their first
20:29founder prestige ever since they came
20:33out. Even though there's other
20:34containers out there, Docker still
20:37maintains the number one position simply
20:39because people were just bought into the
20:41idea of Docker. The idea of containers
20:42are linked to Docker. And this could be
20:45you as well. This doesn't mean that you
20:47need to create a personal brand or
20:49anything like that. Not at all. Actually
20:50what I'm suggesting is instead just
20:52building out the skills documenting your
20:54knowledge sharing it with others within
20:57your company or personal friend circle
20:58or whatever is slowly going to not only
21:01improve your confidence with the
21:03technology but also is going to convince
21:05others near you that you are the person
21:09to reach out for LLM questions and
21:11answers and you can become somebody
21:13else's stack overflow and at that point
21:15the world's your oyster man and that is
21:17the opportunity I am advertising for
21:19there. With that said, I hope this video
21:21was helpful to you. If you would like to
21:23hear me yap more about the different
21:25opportunities present in front of us,
21:27you can have a look at this video over
21:29here. And if not, thank you for watching
21:31anyway, and I wish you a great day.
21:32Goodbye.

About this transcript

This page contains the full transcript of Software Engineers have a once in a lifetime opportunity by exit node, generated from the public captions YouTube serves with the video. The transcript has 4,083 words across 585 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.