# rachels-ramblings Published articles for rachels-ramblings. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Maybe We Shouldn't Be Reviewing All This Code DevFeed: [Maybe We Shouldn't Be Reviewing All This Code]() Original publisher: [Read original article]() Author: Rachel Laycock (rlaycock@thoughtworks.com) Published: 2026-09-02T13:32:00Z Content type: opinion Language: en Sources: [Martin Fowler]() Topics: [Code review](), [pull-requests](), [Artificial Intelligence](), [Software Engineering](), [engineering-culture](), [Meta]() Tags: [ai](), [development](), [meta](), [pull-request](), [pull-requests](), [rachels-ramblings](), [review](), [software](), [software-development]() ### AI overview This opinion argues that AI-generated code is increasing the volume of code beyond what humans can realistically review, but that the deeper problem is relying on code review to provide knowledge sharing, mentoring, collective ownership, and architectural understanding. It advocates moving valuable feedback and collaboration earlier in the development process instead of treating pull requests as its center. ### Source excerpt TL;DR Or, perhaps the problem isn't that AI has broken code review, maybe it's that we've been using code review to solve the wrong problems I was on a panel recently with Brian Houck from DX at Code Remix, hosted by Moderne. It was one of the more interesting panels I've done, largely because we disagreed. As my colleague Martin Fowler says, panels are much more interesting when people disagree and both sides have a good argument. Brian and I definitely did. Brian has since written a thoughtful piece called What are code reviews even for? He is clearly passionate about his position, and I am passionate enough about mine that I'm writing this response. To be clear, I think we mostly want the same things. I just don't think code review is the best way to get them. Brian is lovely, by the way, and encouraged me to write this. But I'd be lying if I said I didn't want you to think I'm right by the end :) So what were we disagreeing about? AI is producing more code than humans can realistically review. Brian cites some pretty striking numbers: at Meta, significant lines of code per human-landed diff reportedly increased 106% in a year, while DX's own data shows median pull request size increasing 64%. His concern, which I share, is that simply automating code review away risks losing all the other things we use it for. Code review isn't just about finding bugs. It's how teams share knowledge, teach junior engineers, build collective ownership and spread architectural understanding. My question is: why are we waiting until code review to do all of those things? I've never particularly liked pull requests as the centre of the software development process. Not because engineers shouldn't look at each other's code, but because I've always struggled with the idea that we should build something, finish it, package it up, throw it over to somebody else and then have the important conversation about whether we built the right thing in the right way. And don't even get me started ## Citizens Build, Agents Execute, Experts Govern DevFeed: [Citizens Build, Agents Execute, Experts Govern]() Original publisher: [Read original article]() Author: Rachel Laycock (rlaycock@thoughtworks.com) Published: 2026-08-19T18:30:00Z Content type: opinion Language: en Sources: [Martin Fowler]() Topics: [AI-assisted coding]() Tags: [ai](), [apps](), [enterprise](), [production](), [rachels-ramblings](), [software-engineering]() ### AI overview The article argues that AI makes it easier for more people to build working applications, but this is not equivalent to engineering enterprise software. Once a system becomes business-critical, concerns such as data protection, resilience, maintainability, auditability, and scale become central. ### Source excerpt TL;DR Why building an app over the weekend isn't the same as building enterprise software I've noticed an interesting gap opening up over the last six months. It isn't really a gap in technology. It's a gap in what different people think software engineering actually is. The conversation usually starts the same way. A non-techie, maybe an executive, tells me about something they've built over the weekend. Sometimes it's a chatbot. Sometimes it's an internal workflow. Sometimes it's a surprisingly polished application that solves a real business problem. They're excited, and they should be. Twelve months ago they probably couldn't have built it at all. Then comes the question. "If AI can do this now, why aren't our engineering teams delivering ten times faster?" It's a perfectly reasonable question, after all we've all seen the demos. The first thing that would come to my head is "you don't know what it takes to build enterprise grade software". But then I think about what I mean and how to explain it to a non-technical person without sounding super patronising. And then it hit me, we did this to ourselves. We've spent so many years banging on about how to write good software that everyone has assumed writing software is the same as software engineering. The application someone builds over the weekend is real software. It likely solves a real problem or demonstrates an idea. Sometimes it's genuinely impressive. I don't want to diminish that because I think one of the most exciting things AI has done is dramatically increase the number of people who can turn ideas into working software. That's cool, I totally get it. The first apps and "hello worlds" I ever built excited me enough to choose this as an actual career so the excitement is real and I don't want to temper it too much. But your first hello world, which these days can be an entire app with all kinds of features, is very, very (extra very on purpose) different from introducing software into a production envir ## How AI Is Shifting Software Development Toward Orchestrating Agents DevFeed: [How AI Is Shifting Software Development Toward Orchestrating Agents]() Original publisher: [Read original article]() Author: Rachel Laycock (rlaycock@thoughtworks.com) Published: 2026-07-31T13:48:00Z Content type: opinion Language: en Sources: [Martin Fowler]() Topics: [Development](), [AI Development](), [Software Engineering]() Tags: [agents](), [ai](), [developer](), [development](), [productivity](), [rachels-ramblings](), [software-development]() ### AI overview The article argues that AI is changing software development by making human attention the scarce resource. As agents increasingly write code, developers may spend less time coding directly and more time coordinating agents, evaluating results, and shaping the overall software outcome. ### Source excerpt TL;DR Why I think software development is starting to feel a little more like conducting an orchestra. There's a shift happening in software development that I don't think we're talking about clearly enough. For the last couple of years we've framed AI as a productivity tool. How much faster can it write code? How many more features can we ship? How much cheaper can we build software? I think that's the wrong question, but I understand why. The first thing AI became good at was writing code, so naturally that's where we focused. As AI got better at coding, I expected the bottlenecks to move through the software delivery lifecycle: from coding to design and specification, architecture, then verification. And they have. We spent a lot of time at the most recent FOSE event discussing how we ensure good design, quality and resilience while agents increasingly write the code. That's a topic for another ramble. A few months ago, though, I realised I was looking at the wrong bottleneck. I kept assuming it would simply move to the next phase of software delivery. I was wrong. AI didn't change what great software looks like. It changed what's scarce. Human attention is now the bottleneck. The next bottleneck isn't design. It isn't verification. It's us. More specifically, it's our attention. Developers have always protected long periods of uninterrupted focus because that's where good software gets built. Pair programming. Quiet afternoons. Deep work. We optimized around flow because flow mattered. When we didn't get that time, very little got done. But when I watch developers using AI today, I see something different. The best developers I know aren't spending all day in flow anymore. They're orchestrating agents. Great developers are starting to look less like programmers and more like conductors. I was watching Jacob Collier on YouTube recently because I'm hoping to see him in concert soon. Watching him conduct is fascinating. He's not trying to play every instrument hims ## Why I'm Writing Rachel's Ramblings DevFeed: [Why I'm Writing Rachel's Ramblings]() Original publisher: [Read original article]() Author: Rachel Laycock (rlaycock@thoughtworks.com) Published: 2026-07-28T12:32:00Z Content type: opinion Language: en Sources: [Martin Fowler]() Topics: [rachels-ramblings](), [Software]() Tags: [industry](), [leadership](), [rachels-ramblings](), [software](), [writing]() ### AI overview Rachel's Ramblings introduces a series in which Rachel shares early, imperfect thoughts about patterns and hypotheses she sees across clients, teams, and the software industry. ### Source excerpt TL;DR I have ideas. I haven't been writing them. That's about to change. I promise... myself. I've been thinking a lot about talent. Actually, I've been thinking a lot about thinking. And writing. Or more specifically, not writing. This really hit me earlier this year at the Future of Software conference. I was surrounded by people sharing their latest ideas and I had a slightly uncomfortable realization: I have my own. Not just opinions. Actual patterns. Hypotheses. Things I'm seeing across clients, across teams, across the industry that feel new or at least not well articulated yet in a way that a leader can think about and act upon in some way that can influence how they strategise and plan for the future. Because helping clients and other leaders internal and external to thoughtworks do this is actually a big part of what I do and without letting my northern humbleness get in my own way, I'm actually pretty good at it. If I wasn't I wouldn't be the global CTO of a future thinking tech org, you know the kind that has Martin Fowler as its Chief Scientist. A title I know he loves... Martin, by the way, is one of the people pushing me to do this, which is weird because on paper I'm his boss but I don't believe in the traditional idea of a boss anyway. I'm a strong believer in the servant leadership type but I'll save that for when I write about that. Anyway the point is for all the ideas I have and discussion I have I don't do a good job of writing it down. At best I'll stick it in a presentation deck when I'm forced to communicate with them in some forum or another. I hate decks and love writing so I'm obviously doing something wrong. So why haven't I been writing? It's easy to say I've been too busy. I don't have an easy job. It's a fun one but not easy. I also have two small children, 5 and 8. In case you are interested, I attempt to give as much time as possible to this busy job. And then I try to have a life. I'm also writing an epic world building sci-fi fantasy b