Hands-On Engineering Podcasts · August 2026
Asked to predict how software engineering changes from here, Hast first rejected the comparison between an LLM and a car-welding robot, on the grounds that one is deterministic and the other is not. The advice to calm down comes from a team that uses Claude daily and had spent the episode explaining why they went back to writing code by hand. He followed it by arguing that token prices are still subsidised and that the economics have to change before the tools do.
Transcript
So, to just summarize the last point that we had is that LLMs in particular are very smart kids, but kids still at this point. And if you did a mistake, this kid will just take it and accelerate your mistake and do it all over again. And if you ask it why, it will just rub it in your face and okay, because you already did that, so how you taught me. Given that we should wrap up our conversation, what predictions do you have moving forward? You choose the scale in terms of how software engineering will change or how working in a team will change.
We're discussing that so much that we kind of bordered it in a way, but it's still important. But it's very important to say again here that we're not negative to clause, we use it all the time, we think it's amazing. But the way that we come to today with writing coders by hand again and using Claude is something that works for us in our domain, in our context right now. When this episode is released someday in fall or something, that may be totally changed, but that doesn't matter. It's just we have to do what fits our code base, our customers, our vendors, our system. But as of the future, I listened to a podcast with the engineering room with Dave Haley and Sam Newman. And he talks about if you're going to use AI, then AI maybe have to both write the code and reuse the code and just have full control. He has an analogy with a factory making cars where the robots just can play around themselves when they're making the cars, and no one can go into the rooms where the robots are. Maybe we have to move in that direction. And when they have so much control over the application, then we can maybe verify the solution on another abstraction and then we can take full usage. But I have no idea, and I don't think it's tomorrow. I know I don't think it's next year either.
The problem with car analogy or the robot analogy is that a robot that welds car parts is a highly scripted thing, it's deterministic, it does the same thing every time, while an LLM by nature does not. So, I think, first of all, I would like to say that everyone should probably take a chill pill, just drop the fovo, because I don't think that anyone will be out of a job anytime soon as software developers. I think the term that coding is solved is absolutely wrong. As I said, it's very dependent on context and what you're working with. I think we're still very much in an AI bubble. So, that I think we need to keep calm and carry on and see if the bubble deflates or if the world economy crashes or whatever happens, and then see both what the actual cost of using an LLM will be after. Because if you're not doing the coding, if you're outsourcing the coding to an LLM, someone wants to be paid for that, and it still looks like the cost of token is subsidized. And it seems also that a lot of the progress with the models now is due to reasoning, i.e., the model prompts itself and then uses more tokens. And you see it very clearly in the pricing of the new models coming out. Like, Opus is really expensive, and Fable, which was available for like five minutes, was double as expensive as Opus. And you're approaching the territory when you can start asking yourself as someone who wants work done if it's just cheaper to have a Developer does it than a mobile. So, if we're going to make progress with AI, then something has to change with the way new models are made, I think.
Thank you. Is there anything else that you would like to add, guys?
Yes, there are two things I like to add. First, it's just the journal where the Synthef published their article is called Journal of Systems and Software, which is a well-respected journal. The other thing I would like to add is that I think we have solved this junior problem in our team. You know, the gap everyone is talking about when you come out of a university and start working and suddenly using agentic coding like Claude, and you don't get to learn how to program as we did when we started working. In our team, we have something called job shadowing. We have a developer from another team coming visiting us for a week. On the first day on Monday morning, they get some cinnamon buns. We just sit and talk for an hour or something about normal stuff. And then, after an hour, we show them the problem or the task that we have for that week. And then we just start working. Since they are developers, and since they know how to write ifs and else, and spring, and all the other stuff that we are using, it's pretty easy to get them productive because we narrow the scope so much. More importantly, since we are doing mob and po pair programming and we're rotating every 10 minutes, then they very quickly get into the tasks. So, for the last year, we had seven different developers coming visiting us for a week, and all of them had code running in production before lunch the first day. They also reported back that they learned a lot this week. And when they came back to their team, they started doing the same practices in their teams. We had organic growth in the way we are working. This doesn't matter if you're a senior or junior or Fernando team or who you are. We get to onboard you very quickly either way. And this will not change, even though we use Claude or Agentic Coding. We will still use the same approach by setting into the same task that we are doing, doing some normal coding, some plot coding, talking about design, writing on the whiteboards, and so forth. And then they get to know the domain pretty quickly and they get productive very quickly. I think if all teams worked in this way, it would never be any problems with people coming out of college and working the way that we do. This approach also leads to two different things: psychological safety is much, much higher because when you start working in the team, you don't have to show that you can deliver or that you are like capable of doing this and these tasks. Like what we see in many other teams is that when someone is starting in a team, they get a task from the board where it should supposed to fit this new developer in the best way. And this developer has to sit down and show that he's capable of doing this task. Instead, the new developers is just set directly into a task with us, and we are delivering the tasks and producing the tasks together, which is a much better way, we think. The other thing, this shows a very good way of doing team mobility. If every team in a company works this way, it would be very easy to switch teams to onboard new team members and off-board new team members, which would be a huge benefit for the company.
I know Europe is really warm, but don't just spend the entire summer bibe coding, do fun stuff, see the sun.