Highlights of the Week
The Middle Loop
http://annievella.com/posts/the-middle-loop/
It occurred to me that we often refer to “loops” in software development - the inner loop and the outer loop: • The inner loop is where the craft lives: write code, build, run, test, debug. Tight, fast, local. This is what TDD and better IDEs optimised. • The outer loop is the broader cycle: commit, code review, CI, deploy, monitor, feedback. This is what DevOps and CI/CD optimised. What if supervisory engineering work lives in a new loop between these two loops? AI is increasingly automating the inner loop - the code generation, the build-test cycle, the debugging. But someone still has to direct that work, evaluate the output, and correct what’s wrong. That feels like a new loop, the middle loop, a layer where engineers supervise AI doing what they used to do by hand.
I’m not convinced about this but it is a different way of thinking about it. Nobody knows though as evident in the next one.
Finding Comfort in the Uncertainty
https://annievella.com/posts/finding-comfort-in-the-uncertainty/
I walked into that room expecting to learn from people who were further ahead. People who’d cracked the code on how to adopt AI at scale, how to restructure teams around it, how to make it work. Some of the sharpest minds in the software industry were sitting around those tables. And nobody has it all figured out. There is more uncertainty than certainty. About how to use AI well, what it’s really doing to productivity, how roles are shifting, what the impact will be, how things will evolve. Everyone is working it out as they go.
Across security, governance, and adoption discussions, platforms kept emerging as the thing that makes everything else possible. The pattern: create safe defaults (the ‘pit of success’), embed guardrails, and give teams a fast but safe path. The argument isn’t for more controls. It’s for better defaults - so that speed and safety aren’t in tension. One group observed that the things that make agents effective (clear standards, good documentation, well-structured code) are the same things that made developers effective. We spent years advocating for Developer Experience and often struggled to get investment. Now organisations are keen to invest in the same things - but for agents. Is ‘Agent Experience’ the new DevEx? And if so, might humans quietly benefit too?
Nobody knows which is bad in that there’s no one path to follow of those that have figured it out, but interesting in that we’re all near the forefront of this and real change can be made to happen.
Nobody Is Coming to Save Your Career
https://alifeengineered.substack.com/p/nobody-is-coming-to-save-your-career
Every big opportunity, every promotion I ever got, including the one to Principal Engineer, happened because I drove it. I started the conversations, and the good managers supported me. Most people assume someone will tap them on the shoulder when it’s time. In my experience, that assumption is the single biggest reason high performers get stuck.
For most managers, career development conversations happen only when a direct report brings it up, or during the performance review cycle when the system forces it. The rest of the time, they’re putting out fires and trying to hit their own goals.
What to do: If you’ve never told your manager you want to grow your career, this is the week you do it. It doesn’t need to be a big formal conversation. In your next 1:1, try something like “I just wanted to let you know that getting to the next level is a goal of mine. I’d like to talk about what needs to be true for that to happen on this team.” That’s it. Just one sentence to open the door. You’re not demanding a promotion or putting your manager on the spot. You’re simply letting them know where you stand so they can start factoring it into how they think about your work, your projects, and your development.
Even just reminding yourself of this every now and again is a real positive
Thoughts on Slowing the Fuck Down
https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/
The problem with agents is that they make errors. Which is fine, humans also make errors. Maybe they are just correctness errors. Easy to identify and fix. Add a regression test on top for bonus points. Or maybe it’s a code smell your linter doesn’t catch. A useless method here, a type that doesn’t make sense, duplicated code over there. On their own, these are harmless. A human will also do such booboos. But clankers aren’t humans. A human makes the same error a few times. Eventually they learn not to make it again. Either because someone starts screaming at them or because they’re on a genuine learning path. An agent has no such learning ability. At least not out of the box. It will continue making the same errors over and over again. Depending on the training data it might also come up with glorious new interpolations of different errors.
Another in the theme of “nobody knows anything” so slow down and figure out what is going on. It will help you but also everyone else
Eight Years of Wanting, Three Months of Building With AI
https://lalitm.com/post/building-syntaqlite-ai/
More importantly, I completely changed my role in the project. I took ownership of all decisions16 and used it more as “autocomplete on steroids” inside a much tighter process: opinionated design upfront, reviewing every change thoroughly, fixing problems eagerly as I spotted them, and investing in scaffolding (like linting, validation, and non-trivial testing17) to check AI output automatically.
AI turned out to be better than me at the act of writing code itself, assuming that code is obvious. If I can break a problem down to “write a function with this behaviour and parameters” or “write a class matching this interface,” AI will build it faster than I would and, crucially, in a style that might well be more intuitive to a future reader. It documents things I’d skip, lays out code consistently with the rest of the project, and sticks to what you might call the “standard dialect” of whatever language you’re working in19.
I found that AI made me procrastinate on key design decisions34. Because refactoring was cheap, I could always say “I’ll deal with this later.” And because AI could refactor at the same industrial scale it generated code, the cost of deferring felt low. But it wasn’t: deferring decisions corroded my ability to think clearly because the codebase stayed confusing in the meantime. The vibe-coding month was the most extreme version of this. Yes, I understood the problem, but if I had been more disciplined about making hard design calls earlier, I could have converged on the right architecture much faster.
Tests created a similar false comfort35. Having 500+ tests felt reassuring, and AI made it easy to generate more. But neither humans nor AI are creative enough to foresee every edge case you’ll hit in the future; there are several times in the vibe-coding phase where I’d come up with a test case and realise the design of some component was completely wrong and needed to be totally reworked. This was a significant contributor to my lack of trust and the decision to scrap everything and start from scratch.
The takeaway for me is simple: AI is an incredible force multiplier for implementation, but it’s a dangerous substitute for design. It’s brilliant at giving you the right answer to a specific technical question, but it has no sense of history, taste, or how a human will actually feel using your API. If you rely on it for the “soul” of your software, you’ll just end up hitting a wall faster than you ever have before.
Really good article on doing real software engineering with AI. We all need to go through stages like this to see what can be done and then roll back to a better medium.