If coding is solved, what's left?

This transcript was generated by AI and may contain mistakes, including in names and technical terms. It has not been manually verified. Please refer to the recording for accuracy.

Source: YouTube automatic transcript. Select a timestamp to watch that moment on YouTube.

1. 0:00

   Why is it looking like that?

2. 0:01

   Okay. All right. Yeah. So, that's more real. Okay. So, uh say say that again.

3. 0:13

   Um can you hear me now? Okay.

4. 0:19

   All right. Um so, I'll try to make some space for Q&A. Um and actually I will try to invite questions as I speak. Uh so few words of my background.

5. 0:31

   So this morning I received this from a friend. So apparently Cotlin is being advertised on the tube

6. 0:40

   which from the business standpoint is a very strange move I would say but it's very uh sort of very nice to see that

7. 0:48

   this is happening. Uh so uh put your hand up if uh the name Cotlin makes any sense to you if you know what it is.

8. 0:55

   Okay. Uh thank you very much. Yeah. So, uh I was uh in charge of uh building cotlin from the ground up. I designed

9. 1:04

   the language, built a compiler, uh gathered the team and led it for 10 years. That was fun. Uh so we went from from like no users and a lot of

10. 1:13

    skepticism in the community to millions of users and a lot of enthusiasm in the community. That was great. Um so my time

11. 1:21

    with codlin was 2010 to 2020. So now I don't run these ads although um I would like to find one in person and take a

12. 1:29

    selfie. Um so if I kept doing that which yeah okay uh the today like if I

13. 1:39

    were to just keep working on cotlin and improving it I would consider myself stuck in the past a little bit uh

14. 1:46

    because you know there are so many more exciting things to do with the new technology on the frontier and I'm I'm not saying like

15. 1:56

    there is no way you can improve an existing program language you absolutely But I think there are a lot more interesting challenges in trying to take

16. 2:05

    programming to the next level with the new technology uh than without. So I'll be talking about sort of my outlook on

17. 2:14

    what our profession will become over time and what's going to change and what's going to be left. Uh for context, how many of you used to write code?

18. 2:27

    Okay. Uh, how many of you still write code by hand on a daily basis?

19. 2:34

    Okay. Yeah. Okay, that's the point.

20. 2:36

    Great. Um, all right. So, we'll be talking exactly about this. Um, to see my slides to be sure that they are

21. 2:43

    actually changing. Um, okay. So, I personally haven't written any code by

22. 2:49

    hand, almost any uh in over a year, well over a year.

23. 2:55

    Uh, do I still feel like I'm a programmer? Well, I have my doubts, but I think I still am. And you know, if you

24. 3:04

    go on the internet and and like just you browse Twitter, you will hear or see a lot of uh excited people talking about

25. 3:13

    the world having changed already. Like nobody writes any code by hand.

26. 3:19

    Everybody is building like software factories and you know um agents review agents in production and stuff like

27. 3:25

    that. um you know and and the mindset across the industry is that build versus

28. 3:32

    buy has shifted dramatically towards build like we don't need to buy anything anymore any software we can build

29. 3:40

    everything ourselves you know and that basically comes from the fact that anyone can vibe code

30. 3:46

    I don't use Twitter very much uh partly because uh the vibe I get is more or less like that

31. 3:55

    and I talk to engineer leaders from the industry more or less on a daily basis

32. 4:03

    and this is not what's happening on their teams.

33. 4:09

    So what's real?

34. 4:13

    You can absolutely build amazing prototypes in hours. This is wonderful as as a new company or a new product.

35. 4:21

    you can build an MVP incredibly quickly and will be a really good MVP compared to what you could have built in the same

36. 4:27

    time previously. Yes. Uh so basically simple things that you know were kind of

37. 4:35

    could get you through the door before are now incredibly easy to do.

38. 4:41

    Uh but if you turn to like production systems that live long and so on so forth, which is probably the reality for most of you, you know what's going on.

39. 4:51

    If you're using agents to generate code consistently and if you're using them a lot, they generate more code than you can possibly read. So you have a

40. 5:00

    trade-off. you either read the code and keep track of things and correct mistakes and and first of all just you

41. 5:07

    you are aware of what's going on in your codebase or you get all this productivity the hype is um offering you

42. 5:15

    right so it's either or like peak productivity versus code review so review is a bottleneck obviously if you

43. 5:24

    don't review everything there's comprehension debt you don't know what your system is doing there's like people are looking at what's going on and they can't keep up and it's called cognitive

44. 5:32

    surrender where you're like, "Oh, I'm I'm like I'm never catching up with that." Uh, and complexity builds up uh

45. 5:40

    because nobody's working to simplify things. Does that make sense? Uh, is it familiar?

46. 5:48

    Okay. [laughter] Uh, all right. So, and and you know, and the internet keeps going on about agents reviewing agents reviewing agents and it's agents all the way down.

47. 5:58

    So this is the context uh uh for for what I'll be talking about. So my point here is that obviously some systems can

48. 6:07

    be maintained more or less by agents but those have to be very specific types of systems like crowd applications

49. 6:16

    can absolutely be maintained by cloud with some attention from some people

50. 6:22

    and you know it's never been like it's never made a lot of sense to me that one could build very profitable business off

51. 6:31

    a crowd application no more. So, you know, that's kind of reality catching up to people. But the

52. 6:39

    thing is, not everything is as simple or as sort of as straightforward as a crowd application.

53. 6:47

    So, this is what we're getting from talking with people in the industry and like how things become really bad. you

54. 6:55

    know, you move fast, you get lots of code, you don't have time to review things, and then you're you end up in

55. 7:01

    this vicious cycle of, you know, more slop.

56. 7:07

    No, nobody pushes back, codes get worse, uh, every PR is harder to follow, and this just reinforces itself. This is

57. 7:15

    where we are. Uh and the the outcome of that is that this just somebody went out

58. 7:23

    and asked a few people um a few dozen people actually uh how things are and they say that they push out in

59. 7:31

    production 20% more PRs per author and also they get 23.5% more incidents per PR.

60. 7:43

    How do you like that? The the trick is you have to multiply these numbers obviously. So you get almost 50% more

61. 7:50

    incidents in those companies which means like sleepless nights for on call engineers, lost revenue, obviously

62. 7:59

    a lot of frustration from clients so on so forth. So this is where we are with the current technology. It's absolutely

63. 8:06

    early days of this technology because we're here. We obviously have to fix it and we will. Any questions about this?

64. 8:17

    Okay. [laughter] Okay. So I think

65. 8:25

    [laughter]

66. 8:26

    [gasps]

67. 8:27

    uh yeah so this is what my talk is about.

68. 8:33

    I think there is an important um sort of important mental threshold we have to

69. 8:40

    overcome because right now uh a lot of people are sort of running away with imagination with like these models are

70. 8:48

    so smart they can obviously with time do absolutely everything and as soon as we are just keep trying

71. 8:58

    to delegate everything to them we end up with the mess I was talking about.

72. 9:04

    And this is very profound if you think about it because agents are supposed to do what you tell them

73. 9:12

    to. And if they do something else, this is like a disaster scenario and I'm not not talking about that. But if they are

74. 9:20

    building what you want, it means you need to sort of communicate what you want. And that puts decisions on you.

75. 9:29

    And if you want to build something the next person can't replicate very quickly, you have to make a lot of meaningful decisions and communicate

76. 9:36

    them to the agent. So yeah, the agent makes a lot of things much easier to do, but you still if you want to make money,

77. 9:44

    you still have to make non-trivial decisions and communicate them. So that raises the level of abstraction, but you still have to be in the loop and you

78. 9:53

    have to make a lot of decisions and keep track of what's going on.

79. 9:57

    And you know if you think about anything reasonably complex like paying for coffee on the customer level that's

80. 10:05

    straightforward right but if you want to pay for coffee what actually is happening is a huge chain of

81. 10:11

    interactions like your uh your card and the terminal talk uh directly but then there is like communication to a bunch

82. 10:19

    of banks and payment systems and whatnot and maybe your card and register in a different country and there will be like a long chain of events

83. 10:27

    that if that chain breaks, someone loses money and people have put a lot of effort into

84. 10:35

    making this whole thing works across countries, regulation scenarios like you know business days closing, accountants going on weekends and stuff like that.

85. 10:46

    Uh this is a very complex system. There is no way you just tell an agent like make it work and what you get is

86. 10:54

    relevant to the changing landscape around you. Uh so you know this is the complexity of the world we live in and we need to communicate some of that

87. 11:02

    complexity like not the complexity itself but how we decide to navigate that complexity we have to communicate that to whatever tools we're building

88. 11:10

    software with. So what we actually do as engineers and what we have been doing

89. 11:18

    throughout the years and not only in software in any engineering profession what you do is basically this

90. 11:26

    like this is somebody not caring about the future. This is somebody being paid for making sure things actually work.

91. 11:37

    And you know all I do when I work with code is I try

92. 11:44

    to keep track like my code is not this neat never has been there's a trade-off but my code is not this messy

93. 11:52

    because if it is this messy its lifetime is about a week I can produce enough code in a week even manually I can

94. 11:59

    produce enough code in a week to get completely lost and like make the code base unmaintainable.

95. 12:07

    So this is what we do and we need to keep doing this perhaps in a slightly higher level but we still need to keep

96. 12:14

    doing this and this is our job and not the computer's job for a very simple reason. This is happening in your head.

97. 12:23

    This is not happening in your repo. This is happening in your head. You have to have a very navigable picture of what's

98. 12:30

    going on to just not get lost. Does this make sense? Any questions?

99. 12:38

    Uh, have you ever identified with an electrician doing this? Uh, you know, yeah, go ahead.

100. 13:06

     Yeah.

101. 13:10

     Okay. So, uh it's a very good observation. So, this if if this is going on your head, everybody has its own head with its own peculiarities,

102. 13:17

     right? And uh how do we like do it among ourselves? And the thing is as a

103. 13:24

     software engineer you learn so much about how to write good code. Good code

104. 13:31

     is actually not what your senior colleague likes. Good code is something that helps people do this in their heads.

105. 13:41

     This is the only reason why we call that kind of code good.

106. 13:47

     So you know everybody's familiar with this.

107. 13:52

     So so this way you end up with a actually with a picture on the top from the previous slide. You end up here very very quickly because you can produce

108. 14:00

     code fast and also this is a real picture from London.

109. 14:08

     You know this like somebody had a need to pass this across here

110. 14:15

     and you know this is what your agents do every day and this goes unnoticed a lot and it doesn't cause problems when you

111. 14:24

     test the pipe on the other end of the pipe because the pipe is working. You need to be aware of needing to test the

112. 14:32

     door in a very specific way. The door also opens. It's open. It opens to the inside. So everything is like working.

113. 14:41

     Uh yeah. So and you know you're familiar with these terms like technical debt is what happens when you don't do this

114. 14:49

     thing in your head all the time. Uh and the there are trade-offs like this which are very real and were real before right

115. 14:56

     so you know you can add more things but you will accumulate debt. Actually,

116. 15:03

     I recently learned how the term technical debt was invented. Who knows this story?

117. 15:11

     Okay, so it was technical people trying to explain to business people that you can't just accelerate development for

118. 15:19

     free. When you accelerate development, you build something that's akin to debt in the sense that you'll have to pay it later. Business people understand debt.

119. 15:30

     And that was a communication device to explain to whoever pays the money that okay we can speed up but we're

120. 15:38

     accumulating debt and there will be interest in that debt and if you're willing to pay that interest we're accelerating fine and this is what the

121. 15:46

     world has done right now. [snorts] Um you know

122. 15:52

     so this is the reality we live and you know you can can imagine kind of

123. 16:00

     two different worlds. One world is where you know machines will figure it all out. Uh models will be incredibly smart

124. 16:07

     and they will keep track of everything and humans become redundant.

125. 16:13

     The thing is you don't want to end up in this world.

126. 16:19

     If humans become redundant, it means humans are not making decisions anymore

127. 16:26

     and it means that machines have taken over. I don't want to end up in that world.

128. 16:32

     Also, no businesses make any sense in that world and like that that's called a technological singularity. So, I'm not talking about this scenario. It may still happen. It's not under my control.

129. 16:42

     Uh but it's not absolutely inevitable though some people think it is. So I'm thinking about a positive scenario and

130. 16:50

     like there is a spectrum of positive positive scenarios but in all of these scenarios machines have not fully taken over and so humans are still in charge

131. 16:59

     and in that world where humans are still in charge like coding is still solved right so machines know how to write code

132. 17:09

     but what's left to the humans let's try to characterize it a little more than just you know making neat pictures in

133. 17:17

     your hit and I would argue that this has always been the mo more interesting part of our profession although you know

134. 17:24

     there are opinions about that uh so how programming progressed from like I don't have machine codes here but

135. 17:32

     I have assembly so we had assembly uh which is super low level you had very fine control of everything you could

136. 17:39

     control individual machine instructions then we kind of got tired of this because it was too tedious and We built

137. 17:47

     things like C uh which is still pretty low level by modern standards but was created as a highlevel programming

138. 17:54

     language uh and then we went to things like Java that were a little more high level. So, we took some concerns away because C got

139. 18:04

     too tedious to write and also didn't scale very well because if you're writing C or C++, you can't assemble,

140. 18:12

     you know, a team of a hundred not super well-trained engineers and make them build a thing that works. It will just

141. 18:20

     fall apart. In Java, you can. And this is how like a lot of places built up their industries like started up uh

142. 18:27

     exactly like that. And then you know there were improvements over Java even like Cotlin and you know this pyramid is

143. 18:36

     basically raising the level of abstraction because the previous level got too tedious got too boring. So what we did in cotlin

144. 18:45

     to you know improve over java uh and java-like languages we basically took this code looked at it and it's like

145. 18:53

     okay this is incredibly tedious fine can we like simplify a little bit went down to this like okay that's better but

146. 19:01

     still very tedious can we go down to this yes maybe a little more can we yeah

147. 19:09

     so this is what we actually meant and this is what codlin Uh and the point of doing that is like this is called raising the level of

148. 19:17

     abstraction. But the point of doing that was basically saying like all this in the initial code sample is boring.

149. 19:27

     Let's get rid of it because it's too straightforward for a human to waste time on looking at these lines.

150. 19:34

     And so the previous levels became so standardized that they got boring like memory management uh going from C to

151. 19:42

     Java got boring. People got rid of it and this is where we are. So these days

152. 19:49

     writing code in these languages is becoming boring and we have cloud code on top with quite a few more people

153. 19:58

     being able to do that. Uh incidentally when you raise levels of abstraction the tool be becomes more accessible. It's

154. 20:06

     easier to deal with higher levels usually if you're not building something like Haskell.

155. 20:14

     Okay. So throughout this transformation some things has all have always remained.

156. 20:24

     What do you think they are? I flashed the slide but maybe you don't read as fast. Um any ideas what remained throughout this evolution? Say that again.

157. 20:34

     Formal way of doing things.

158. 20:36

     Formal way of doing things. Yeah. So all these languages are can can be called formal in like a very definable sense.

159. 20:44

     True. What else?

160. 20:47

     Testing. Testing remained relevant throughout this entire evolution. True. What else?

161. 20:54

     Say again. The outcome uh yeah the the outcomes kind of grew in scale but yeah the outcomes are still programs. That's

162. 21:03

     true. More questions? Uh sorry not more questions more um more versions.

163. 21:10

     Uh yeah. So the business problem remained relevant throughout the whole thing. True. So a few other things that

164. 21:18

     remained were the an the questions that engineers had to answer more or less regularly like how long will it take to do something?

165. 21:28

     Will something break if we try this? Why is this happening?

166. 21:34

     Uh often comes in the form uh of why are we losing money on this and can we make something more reliable please?

167. 21:45

     Have you been answering these questions throughout your careers? Show of hands.

168. 21:50

     I have. Yeah. And so, so this is what we as engineers what we are actually in charge of like being able to answer

169. 21:58

     these questions is what actually matters. Like if we can't answer these questions reasonably well and and you know like how long will it take to do X?

170. 22:09

     No engineer ever answered that correctly. But you need to be in sort of a ballpark.

171. 22:16

     And you know there there are different reasons why things go off schedule.

172. 22:22

     But the thing is if you have absolutely if your answer is no idea probably a few days to any question of this shape

173. 22:30

     something's going wrong because oftentimes it will take like months not days. And this just means that you you

174. 22:38

     don't know what's going on and all the rest. If you're not aware of what's going on in your system, this is what breaks down.

175. 22:47

     So what's engineer is all about my take is predictability, reliability and accountability and control. So control

176. 22:54

     is what you actually need to more or less provide all these. And this is what we're losing when we are relying on agent too mindlessly. Agents are great.

177. 23:05

     we need just need to use them in the right way. Uh so you know uh back to the question that has been asked earlier

178. 23:14

     like we accumulated knowledge in this industry knowledge about how to put things in in neat uh you know cable

179. 23:23

     organization patterns in our heads and the answers has have always been like do solid, do dry,

180. 23:32

     do kiss. These are heristics that really help and this is what we need to retain. So

181. 23:40

     how do you do solid with claude and it's you don't ask claude to do solid because

182. 23:47

     you're not reading the code. You need to do to give Claude a solid input that you responsible for.

183. 23:58

     So you know and the thing is in the future models can get much smarter or may not but probably they will get somewhat smarter.

184. 24:07

     One thing I know about the future though although I don't know this like whether they do or do not get smarter. I know

185. 24:15

     something else. I know that humans will be the same and humans will still need solid dry

186. 24:22

     kiss and other things like that to pack things in their heads. And that's the trick. So whenever humans meet

187. 24:30

     complexity, we need engineering. And this is what remains of our profession. Engineering is what stays.

188. 24:37

     So you know in case you don't like managing complexity, this future may not be very bright for you. You'll need to adapt. Sorry.

189. 24:48

     How we doing on time?

190. 24:51

     We're over time. Okay. So this is actually a good place to stop. So this is my answer to what's going to happen

191. 24:59

     to our profession. It will distill into engineering pure. We'll keep organizing things in our heads and what's left of

192. 25:08

     my talk is talking a little bit about the technical solution which I will skip over and uh we'll direct you to somewhere here.

193. 25:18

     So uh you can absolutely visit codep.dev. uh you can join the wait list and see what we have to offer for the solution.

194. 25:27

     Uh it's not out yet, so you'll have to wait a little bit. But basically what we're trying to do is we're trying to create a way to communicate to Claude

195. 25:37

     not in just you know prompts that you throw away but in something you can apply solid dry and kiss and other things too.

196. 25:44

     Does that make sense? Okay. Uh can I take one question?

197. 25:49

     Yeah, sure. Okay. Okay. Questions. Go ahead.

198. 25:54

     You mentioned this in your talk that we used to use solid um design patterns to sort of communicate with each other about good code and and when

199. 26:02

     maintainable systems and with agents [clears throat] everything's different and I'm I'm just curious what is the new paradigm do you think are like new level of abstraction that's emerging?

200. 26:11

     Great question. So the the the question is what is this new level of abstraction like uh what is it that we are applying this all these principles to again.

201. 26:22

     So the like very very honest answer is nobody knows fully yet but we know a few things.

202. 26:31

     We definitely know that uh this new level of abstraction includes the idea of interfaces between components because

203. 26:38

     this is how we organize things. So there have have to be components and interfaces between them like you know

204. 26:46

     APIs or something. Uh each component has to provide some guarantees about what's inside of it and has to encapsulate its

205. 26:55

     contents. So you can imagine like the easiest way to imagine the shape of the solution is you take your big program

206. 27:03

     you take its API surface and that's part of the solution. Instead of the implementation,

207. 27:10

     you write down requirements and guarantees like this API does this and guarantees that. And the pair of API

208. 27:18

     definition plus guarantees is enough to characterize the system.

209. 27:24

     That's like a very very high level sketch and we'll show things as we work on them. But that's the overall idea.

210. 27:33

     The details will be tricky because some things you want to keep formal, some things you have to keep informal because you know the power of LLMs comes from

211. 27:41

     the informal side. So you have to somehow blend formal and informal and make a robust combination of that. This is what we're working on.

212. 27:52

     Okay, I think I think we got your question.

213. 27:54

     Yeah. So how do we use uh the power of models to help us build a next level abstraction? So the trick with models is

214. 28:02

     that they bring one super important thing. Models understand human words roughly the same way as humans do. Which

215. 28:11

     means you don't have to explain every bit down to the metal. It's already out there. You can think about an LLM as if

216. 28:20

     it were a huge library of code. So it's not your colleague or, you know, not an intern you delegate things to. It's a

217. 28:28

     library. is like a giant npm on steroids.

218. 28:33

     It contains all the code in the world or almost all the code in the world, but you need to ask it in the right way to retrieve that code. And this is the

219. 28:42

     power. You don't have to describe every bit of the detail that's obvious to all people but not obvious to a computer

220. 28:50

     without an artificial intelligence. You don't have to describe that. You can just rely on the model more or less understanding a lot of things. It doesn't understand everything perfectly

221. 28:59

     but there is a big subset of things it understands. Well, this is what gives us the raise level abstraction. Thank you very much for your attention.

222. 29:07

     Right. Thank you so much.