Speaker A
I just returned from a short business trip where our two teams got together to get to know each other. And, in principle, other than some pleasant memories, there wouldn't be much to talk about if not for an interesting
An IT professional reflects on how AI is revolutionizing software development, making manual coding obsolete and reshaping career roles.
Key Takeaways
- AI is transforming software development by making manual coding obsolete and accelerating delivery.
- Developers now focus on writing clear specifications and orchestrating AI agents rather than coding.
- Human roles are shifting from creators to coordinators and validators in AI-driven workflows.
- Spec Driven Development is emerging as a new paradigm where AI generates code from specs.
- The IT profession is undergoing a profound paradigm shift requiring adaptation to new skills and roles.
What the video covers
- The speaker attended a business trip where a management meeting triggered a major realization about career and work transformation in IT.
- Traditional two-week sprint cycles are now too slow due to AI advancements enabling unprecedented speed and quality in development.
- Manual coding is becoming obsolete; generating code with AI is now necessary and faster, with humans acting mainly as coordinators.
- AI agents handle subtasks, code generation, and testing, reducing the human role to specification writing and process orchestration.
- The concept of Spec Driven Development (SDD) means developers write only specifications, while AI generates and tests code.
- Humans contribute mainly empirical knowledge and final approvals, but their role is shrinking as AI capabilities grow.
- The transition challenges traditional programming learning and practices, making manual coding a hobby rather than a necessity.
- The future involves managing teams of AI agents, distributing tasks, and optimizing workflows rather than hands-on coding.
- The speaker reflects on personal career evolution, no longer identifying as a programmer but as a coordinator and language expert.
- There is a broader paradigm shift in IT, with concerns about understanding complex AI-driven systems and the pace of change.
Chapters
- 00:00Introduction and Business Trip Overview
- 01:14AI and the End of Traditional Sprints
- 02:22The Obsolescence of Manual Coding
- 03:34AI Agents and Code Review Automation
- 04:32Humans as Coordinators in AI-Driven Development
- 07:08Spec Driven Development Explained
- 08:22The Shrinking Role of Humans in IT
- 09:33Personal Career Reflections and Future Outlook
- 10:42The Paradigm Shift and Its Implications
- 12:18Closing Thoughts on AI and IT Transformation
Full Transcript — Download SRT & Markdown
Speaker A
meeting we had with our management, which triggered a chain of other conversations that, well, without exaggeration, probably changed my outlook on my career and my life in general—a "before" and "after" moment. Some realizations I have now—perhaps it's too late, perhaps some of
Speaker A
you had them earlier, but I just arrived at them literally a few days ago. They were somewhere in the background of my consciousness, but now they have crystallized into a very clear, concrete, and understandable picture that simply changes everything
Speaker A
about how I understand my work and my career. I’m an IT professional, and many know that IT people are currently transforming the most rapidly. But I didn’t realize just how enormous this transformation really is. So, the essence of the meeting and the
Speaker A
conversation was that sprints, those two-week development cycles, are just too slow. Thanks to the use of artificial intelligence, we are now so almighty—yes, we are now superhumans, we can do things we never even dreamed of. Now, there are no blockers for us.
Speaker A
We now know, have the skills, and can do everything with extremely high quality and at incredible speed. Models have now reached such a level of development that few programmers can do what a model can do. Especially if you
Speaker A
deploy a bunch of agents, each working on its own subtask, and at such speed.
Speaker A
And, of course, for many years we spent time polishing and refining code, learning practical things, best practices, having those holy wars about whether to use tabs or spaces, or something else. Now, all of that is far in the past. We were lucky to have that
Speaker A
experience of manually writing every single line of code. Now we are going through such a transition that it's not just that you shouldn't do it—it's not even a case of being ashamed to say "I generated this," but rather, it is
Speaker A
now necessary. It is now a bad thing if you write something by hand. In reality, the paradigm is shifting—maybe not in every company yet, but at least in ours, and I think in many leading companies, writing code manually is
Speaker A
already considered bad. That is, if you try to write by hand, you are slowing down progress. Now you have to do everything you did before five to ten times faster. And this very human link—I recently recorded a video about
Speaker A
this, by the way—is that I am the slow link in using artificial intelligence. And in fact, this is a well-known thing. And even reviewing what artificial intelligence gives you, yes, this work it has done, even just reading a regular pull request, opening
Speaker A
and reading someone's work, right, when 50 different files are being changed simultaneously in different places. And cognitively processing all of that.
Speaker A
This is what slows down progress. And that is why for pull requests, you just click, like, yes, okay, I confirm this.
Speaker A
Or you submit it, feed it to another agent so it looks at it for you, and then you still click confirm, maybe with some small edits. Essentially, a human in this race can no longer keep up, and they shouldn't have to. The
Speaker A
whole idea is that these scrums, these two-week planning sessions, have lost all meaning. They are too slow. Pull requests are no longer needed by anyone because a human won't find the problems that another artificial intelligence, another agent, another model might find
Speaker A
when you've done one thing and another one checks it. That is the only way it can be. And a human in this process is just, as my colleague said, a "meat layer." Meaning we are a "meat" layer between agents that just coordinates
Speaker A
operations a little bit, passing things from point A to point B. So, instead of this classic development, a completely different task now emerges. Now, instead of writing code, you need to write a work plan program for the artificial intelligence, describe it,
Speaker A
iterate on it, review the plan, approve it, improve it, and do it over and over again. So, there is a concept called SDD, Spec Driven Development. This means the developer now writes only the specification, and only the specification, and never touches the
Speaker A
code at all. Don't touch the code with your hands at all, because you'll only mess everything up. Now only agents will create code according to the specification you feed them. And in principle, the agents themselves will write this specification for the most
Speaker A
part. Yes, a human will simply confirm if it is good enough and if everything is covered. Yes, because there are still some moments that, well, the agent doesn't always know yet, right?
Speaker A
So, even if it is currently possible to access general organizational data and all sorts of information, and make decisions based on business logic or a domain, a human still has to attend separate meetings, agree on things, and, for now, control all these processes
Speaker A
at the final stage—writing out specifications, breaking them down into design solutions and tasks, and ensuring these tasks are executed one by one in the correct order, while also verifying the quality of the work through another agent that, for
Speaker A
instance, has the authority to write and run tests. That is, separate these agents: one agent will be responsible only for creating and implementing a task, while another will only write the tests, so that the first one cannot rewrite the tests just to make them
Speaker A
pass. And, in essence, this is how the entire organization functions and will function—it already operates in such a way that all the key practical work is performed by artificial intelligence. A human is simply an orchestrator, a coordinator of all these processes
Speaker A
between them. And yeah, for many, this realization was, well, it was already there, sort of. But for many people on our team—not all, as many are already deep into this—at least for me, this realization finally became clearly formulated. Because I still had this
Speaker A
thought that, well no, this is just a process that is still ongoing, right? That there is still some transition, that a human is still needed, that they can still do something by hand somewhere. In reality, a human can now
Speaker A
only contribute some kind of empirical knowledge, right? Like, I know a client asked me something verbally, and if it's already described in electronic form somewhere, then the human is no longer needed here. Meaning, I made an agreement somewhere, or there are some
Speaker A
historical unwritten truths that only I, as a human, know, and I can share them with the agent. And by and large, that’s it. I generally think that this transition will continue and the human role, in principle, will keep
Speaker A
shrinking over time. And even for those people who currently feel that their work is transforming and will continue to do so, I think that over time it will become clear that fewer and fewer people are needed to get this work done.
Speaker A
Back when I was an intern, while I was studying at KPI, I did an internship at Kyivenergo. And I had, well, a department head who used to say that essentially he earns money just for knowing the Ukrainian language,
Speaker A
because he simply writes up some documents, some specifications, writes some reports, and that's it. Everything else is done for him. And I remembered that phrase for some reason. Probably because my own career has reached the stage where, essentially, I am now paid
Speaker A
just for knowing the English language. Well, and I know, of course, I have some experience, some practical knowledge of things that I can apply at my work. But I am no longer a programmer, that's it. I no longer
Speaker A
develop code. I no longer have to learn anything. There is no point in learning any programming language, except as a hobby. Of course, theoretical knowledge is useful. Why is this database better than that one? Just to understand why
Speaker A
such decisions are made. Why, for example, do we need, I don't know, many requests to go into a
Speaker A
don't know, some syntax, how to write it, or any of those things we used to do by hand, you now just need to know as much as possible about the work itself, right, about the project itself , what it does, why it does it. Why
Speaker A
exactly are the mechanisms set up in this way? But you don't need to know these details at all. And tell me, maybe I'm wrong, but learning a new programming language is now an absolute waste of time. It's just for the sake
Speaker A
of entertaining yourself. There is simply no point in it anymore. Now it turns out that, yes, there was always theory and practice. Well, now essentially only theory remains.
Speaker A
Theoretical knowledge is enough; the practical side has already been moved to other mechanisms. And essentially, perhaps a time will come soon when theoretical knowledge will also be completely absorbed by artificial intelligence, and it will be used, and the human share in this will be very
Speaker A
small. And it is interesting that it seems that because now this is all, well, how all processes in IT, yes, have always been made to make life easier for people. Yes, all processes, Scrum, Kanban, and the work of the team
Speaker A
as a whole. All those high-level programming languages, you know, everything started with machine code, then assembly, then C, and now we’ve reached, I don't know, maybe Rust, which is more convenient. Everything is designed so that humans don't have to
Speaker A
think about problems that machines face , like cleaning. Memory, like memory overflows, memory leaks, cache clearing , parallelization of processes, and so on. All these high-level abstractions were built so that it would be easier for a person to think globally about a
Speaker A
problem, rather than diving into those details and implementing them. And it turns out that everything that was previously aimed at humans is no longer relevant. Now everything is changing, I mean, it's all disappearing. It seems to me that time will pass, and
Speaker A
essentially, the development of new programming languages—or these high-level programming languages we have now—will no longer be needed.
Speaker A
Yes, because a human will no longer be looking at the code. And now everything will probably return to some faster instructions, lower-level ones, which will be easily written by artificial intelligence. Perhaps, of course, because artificial intelligence was trained on these high-level languages,
Speaker A
it won't be that fast, since it knows all these instructions because it went through many snippets taken from Stack Overflow or somewhere else. And there is little machine code relative to that right now. But considering how complex all these compilers are, like
Speaker A
just-in-time compilers, the Java compiler, and other things, and how difficult their maintenance is, it is likely that speed and low-level accessibility will win out. Most likely , it will lead to the development of modern programming languages at least
Speaker A
slowing down significantly, stopping, or becoming completely unnecessary. The same applies to all processes and even teamwork. Essentially, the very phenomenon of a team and the interactivity of people with each other is no longer needed. Most likely, people will work alone. Yes, you are
Speaker A
alone, you have a team of agents, and your task is to effectively distribute tasks among them, assign them roles, and use tokens efficiently. And this, too, seems to me a temporary task for humans. This is a transitional period
Speaker A
for this role, where a person still has some sense in doing something. Over time, I think that if the complex task of solving programming logic is already being solved automatically, then this task of optimizing such parallel agent work will also be solved automatically.
Speaker A
And frankly speaking, it is such an exciting, very thrilling period, you know, it is such a realization for me at least, that I just, well, I don't know, I just realized now that there was a before and an after, that I have
Speaker A
turned a whole chapter of my career, that's it. Now something will be different. It will never be as it was before. And it will be so different that even after all my conversations, and what I’ve said, I still hadn't
Speaker A
realized how profound this change is. And I am confused. I think that if this has happened, why can't the next step happen? And the next step and uh this is an interesting time, as I have already said. It's cool that we lived
Speaker A
in those times when we still did all this by hand. It's like, I don't know, maybe some old folks telling the youth how they used to manually repair a car, how you could still take a soldering iron and fix something, whereas now
Speaker A
there's microelectronics, and you can't fix anything yourself anymore. How everything used to be more accessible to people. And IT has gone down that same path. Now it has become distant from people, incomprehensible. And the fact that you don't understand, just
Speaker A
don't understand the code that was written, is no longer a shame. Yes, it is no longer embarrassing or shameful to admit it. This is the norm, and fewer developers will understand what is being written. Yes, and it will
Speaker A
increasingly come to the point that no one will essentially understand how the system is built. Which actually reminds me of that movie Idiocracy, right, when very cool systems and very cool solutions work around us, which are created very quickly, but we have no
Speaker A
idea how exactly they are built. And no one will accuse or blame anyone for this. It’s like, I didn't figure out why. So all this negligence, this lack of understanding, is no longer a problem, right? On the contrary, it’s
Speaker A
how you accelerate, you don't delve into the essence, you accelerate development because all companies are afraid of being left behind. They need to move quickly, and everyone is afraid of losing this competition, this race.
Speaker A
And even with the fact that many companies use some solutions, right, temporary ones, for example, like we use Bedrock and we have a contract that allows us to use tokens via subscription. Eventually, this will all come to an end. No one wants to think
Speaker A
about what will happen if this all suddenly skyrockets in value. Or if you think about it too much, you'll be left behind. So, yeah, such a huge, huge paradigm shift, a great change in everything is happening, friends. And I
Speaker A
don't even know, uh what comes next, how it's going for you, friends, what's happening in your companies, how you see all this, please share. I'm interested to hear from you. That's all for now. Until next time.
Topics:artificial intelligencesoftware developmentspec driven developmentAI programmingcareer transformationIT industryautomationAI agentscoding futuresoftware engineering
![[Warhammer40k] The last church; Graham McNeill. Stream-reading. — Transcript](https://i.ytimg.com/vi/x7YsEuT2B4k/maxresdefault.jpg)
