AI is a great tech debt assistant. @neetcode1, founder of NeetCode, on how AI reduces the cons in makes moving fast and cleaning up later: “Over the last six months we've been cranking a lot of features out, a lot of code out. Most of it has been written by AI at this point, and before that really wasn't the case. I was actually a really big AI hater for a long time, and people still sometimes think I am. If I'm pro AI, they're like, ‘NeetCode you changed, what happened? Now you're an AI shill’. But it's not that. I just try to be pragmatic about it because I was still using the tools before, but they just weren't as good. Now they've gotten to a point where the work that I'm doing… which is mostly CRUD, usually there's not that much crazy interesting stuff other than the code execution service, that's probably the most interesting one. The first few years when I was writing most of the code - very, very bad code quality - I used TypeScript, but I was not using real TypeScript. I had a lot of `any`s. I had a lot of bad code. I was putting inline CSS. I was just doing all sorts of stupid stuff just to get stuff done as quickly as possible because I knew the entire codebase. I knew certain tech debt, I could just deal with. And so it was a trade-off for me just to move quicker. But with AI now, I've gone back and I realized that trade-off was so worth it because I cleaned all of that up with AI, because that's what it's for. It can clean up a lot of sloppy code, it can refactor a lot of things. And if I really wanted to now, I could probably migrate to other tools very quickly with AI. So, to go back to the trade-offs, I think it's just about thinking you might make the wrong decision, but even if you make the wrong decision, you can go back and then try to correct it just by thinking about it.”

"The best sales pitch in the world". @neetcode1, founder of NeetCode, on how getting a Google offer gave his YouTube channel credibility and made it go exponential: “I was making these tutorial videos. I was like, I'm studying this right now. I got nothing better to do. I might as well help some other people. And I found it very difficult because there weren't really tutorials at the time. There were just a lot of forum posts of these really complex solutions. And I'm sitting there banging my head against the wall trying to understand it. Most people didn't understand the solutions because it is very hard to. I think most people just looked at the algorithm, kind of had a high level understanding of it, didn't quite know why it worked, but it was good enough. Usually if you saw that question in an interview, you could probably pass the interview. This goes back to deep thinking, which I think was a skill that is more of a personality trait for me. But I think it helped me a lot with the LeetCode stuff. I went really deep into things, but at the time felt kind of meaningless where it's like you make this video for 50 people watching and you did a great job, but clearly it's not worth the several hours it takes to do that. But I kept doing it ‘cause I enjoyed it. About a year after I started making the videos consistently, I did get into Google. I was very fortunate to do that, the interview process was pretty easy at that point, thankfully. So I kind of backed off the videos. I was like, this was fun, but I'm at Google now. I made a video telling people like, ‘hey guys, I got into Google, you might not see me as much anymore’. Funny enough, after that, the channel went exponential because I think it added so much credibility. It's like, okay, this guy didn't make these videos after he got into Google, he actually made it before, this is what he did. And then he got in. So it's like the best sales pitch in the world. I proved it. I went from zero to one.”

At Amazon, he learned not to ask questions. Neet(@neetcode1), founder of NeetCode, shares how Google saw this fear as independence and promoted him quickly: “I was kind of in Amazon PTSD mode. That was my first real professional experience. I extrapolated that to be everywhere in big tech or even just professionally in general. So I was like, okay, you're supposed to not ask questions. You're supposed to not talk to people. You're supposed to not even be friendly. You're supposed to just work and just be as intense as possible. At Google, people were very friendly to me, and so I reciprocated that, but I didn't ask questions. I was very scared to, so I worked on my own for the most part. I was given a project from my manager that turned out to be more difficult than it was supposed to be. I was still in the mode where I was like, I just got to get it done. This is my project, I have to do it independently. And so I was very fortunate in that I did have a very supportive manager, a very supportive team. And because I chose to do pretty much all the work by myself, the manager and team saw me as independent, which is what you need to do to get promoted from junior to mid-level. And so I was very lucky to get promoted very quickly because of that. That helped me build my confidence a lot. That made me realize, okay, I can start asking questions now, which is funny, after I got promoted is when I was more comfortable asking questions when you'd expect that from a junior engineer more.”

Not everything has to be end to end GitOps. Rob Erez, principal engineer at Octopus Deploy, on GitOps absolutism: “What we see is a lot of people go to conferences or they read blog posts and they hear that GitOps is what you should do. What I want to point out here is GitOps is potentially not necessary for all locations, all environment teams. There's certainly a bunch of benefits to it, but the reality is there's some things you need to do outside of just GitOps, and so you might use GitOps principles in parts of your process, but some of this absolutism that sometimes exists may not be necessary. There's often a bunch of other processes you do around your actual deployment: maybe you run smoke tests, or maybe you want to send a notification when it's complete, or maybe you want to do a database update. These kinds of steps don't really lend themselves very well to this 'declarative, everything is in Git' process, and so that's why you get things like Argo workflows and rollouts come out to try to GitOps-ify this process, and that works for some people. But the reality is that I think some people get really hung up on this idea that everything is Git, so therefore they've found the tool, and so therefore everything is a nail. I think that's just not the case. So again, that difference between what you hear when you talk at conferences, where everything is Git and everything must be in this particular format, and the realities for most customers: they're just trying to ship software and they don't care what name you give it. If it's GitOps and it works end-to-end and solves everything - good. If they want to use GitOps as part of the process but then have other mechanics that are more imperative - good. It's just the reality that there's tens and tens of thousands of companies out there in the world doing software delivery, and not all of 'em are at conferences and not all of 'em are at the forefront.”

How to get into Progressive Delivery? Rob Erez(@no_erez), principal engineer at Octopus Deploy, on the value of being able to switch a feature back off: #1 - Start with one feature flag “So start with adding one feature. It may be scary at first to kind of go, oh, it's in production, if I toggle this, I'm going to break something in production. It's nice and comfortable to know that you're kind of well to the left of the running systems and if you ship code, everything will be caught by the test. But, if I toggle it, what will happen? But it's kind of like a drug. Once you start doing it, you don't want to stop. And that's why we've got this hygiene problem for things like feature toggles. It's really easy to add them and actually end up with the opposite problem of how do you control yourself? How do you stop? So I'd say just start doing it. Add one and keep an eye on as you roll it out and you look at the results from it. The reality is I've shipped features on feature toggles where I've shipped a bug and it's one thing to ship something and turn on a feature and go, okay, cool, customers have it, it's a very different thing when you do the opposite." #2 - Why you reach for the toggle when things go wrong "If you ship something and there's a problem and you can reach immediately for the toggle and switch it back off. The amount of times kind of in the past, you have this kind of panic of, oh no, I've shipped something, I dunno what's going wrong. And particularly when you're in that state, maybe you've got called up at 2:00 AM because you've got an on-call and you dunno what the next step is to do, and you’ve kind of got a panic mind and should I build a new thing or do I somehow force a redeployment? So having the capability of being able to flick that switch just allows you to then calm right down and go, okay, I've stemmed the bleeding. Now come back and reanalyze it and understand what's wrong. So having that capability once you've sort of experienced that and realize the value that not just rolling things out, but sort of I guess rolling that individual feature back off. Yeah, you'll want to use it for everything."

Ephemeral environments: what are they, and why are they more popular? Rob Erez(@no_erez), principal engineer at Octopus Deploy, explains: "What we're seeing is more the growth of things like ephemeral environments. And so this is the idea that I, as an engineer, am running some sort of feature on a feature branch and I want to kind of evaluate that it's actually doing what we're expecting it to do. So ephemeral environments is this idea that from my branch pre merge, I want to spin up a whole environment essentially from scratch, ideally with whatever dependencies are required to run this particular piece of this component that I've been building. Then I want to basically deploy my app into that as if it was a normal full fledged environment. Once that's available, if it's a web app, for example, maybe it gives me the URL and I can poke around it and hand it around and other people can evaluate. And then the moment I merge that PR, tear it down again [Gergely: Now with AI agents everywhere, that's even better because in the sense that if one of the best ways to validate, we have code reviews and AI agent generates and you look at the code, but isn't it not better to just confirm that this thing works, especially when it has a UI?] That’s right. I think even in that world where you've got AI agents building the code and validating the code, any sort of scenario where you want that AI agent to validate what it's done, you're essentially talking about ephemeral environments, even if it's not exposed to people because it's doing its own testing and poking around.”

Product quality comes from doing irrational things. Dax Raad(@thdxr), creator of OpenCode, on how quality is a constant practice, not a decision: “It's easier than ever to rot your product, with these agents and everything. You see it with big companies. Big companies' products are rotting faster than ever. Even startups' products. Now if a product is a year old, it's probably already kind of going to shit. And I think it's because of all these agent workflows. I still believe quality is a huge differentiator. It's not just something you can decide to do. I think it needs to show up in every single aspect of your company. You have to do things that are irrational. Even if you look at our story: when we first launched OpenCode, ClaudeCode was the only other real thing we were going up against and a big initial differentiator was that our terminal experience just felt better. We built our own terminal framework. Building your own framework is the first thing they tell you not to do, right? It's the thing that no engineering team should do. It's irrational, but we looked at it and we're like, we couldn't achieve the experience we wanted."

Kubernetes clusters out at open sea. Rob Erez(@no_erez), principal engineer at Octopus Deploy, shares how on premise ‘on prem’ can get: "When we talk about small computers, some of our customers have Kubernetes clusters basically in their point of sale systems. So they have hundreds and hundreds of stores and they have little Kubernetes clusters that’re essentially running them, and each one's independent. I was talking to one of our customers just the other day at KubeCon, they've got Kubernetes clusters running on research vessels and those research vessels. As in ships on the ocean. I'm not going to pretend to know exactly what they're doing on those ships. We didn't quite get into that detail, but they've got Kubernetes clusters out in the open sea, which is apt given Kubernetes name. The problems they run into though are a little bit different. So for them, those boats might be out at sea, weeks, months, at a time. So when you want to do a deployment, the ship's not available. When that ship comes back into port, it needs to get the update. So they'd be talking through how you'd achieve this and how that process would work."

Don’t do a rollback: instead, roll forward! Rob Erez(@no_erez) - principal engineer and Gergely’s former colleague at Skype - on why 'just roll back' is mostly luck: "Rollbacks. This is always a spicy one. We get a lot of customers who say, why don't you have a rollback button? I want to roll things back. Why can't we roll things back? The reality is for most systems out there, you've probably got some state, state being databases. It could be any sort of information that you can't necessarily just undo because if you roll it back and now you've got your code talking with the schema of the database that's not in sync. So, generally, we've gotten pretty far in trying to advise customers that you want to avoid ever talking about roll back. It's always roll forward. So if there's a bug roll forward, get your change in as soon as possible. And this is where fast feedback loops are important. It's this idea that if I've got a failure in version two, my rollback isn't to go to version one, it's to go to version three and make sure I've got that fix in version three. It's a sort of thing that when we talk to customers and some of 'em go, yeah, we roll back all the time if there's a problem. And then when you ask them what do you do if you've got a schema change? They kind of stop and realise that they've never, it is just sheer luck that they've never run into that."

Does CI/CD pipeline speed matter with AI? Rob Erez(@no_erez), principal engineer at Octopus Deploy, on why thoroughness outweighs speed when agents are babysitting the build: “One of the things you often talk about when there's a human element to the pipeline is speeding up the cycle to get that feedback quicker. If you've got engineers sitting there waiting for their code to run tests, they can get back to it and fix it. The shorter and shorter you can make that feedback loop the better it becomes because they don't need to context switch, et cetera. I think in a world where the majority of your code is being developed by AI, that becomes perhaps less important. If you can kick out your build and test process and it takes 30 minutes versus 20 minutes, does it really matter if the engineer's already long gone, moved on to the next problem and the actual AI agent themselves itself can kind of babysit the process and review the problem that came up and issue a new fix? So I think there'll be a de-emphasis on some of the speed of the pipeline itself and more on increasing or decreasing risk, the risk that comes from having AI agents generate code."