timomeh

I’m currently on a weight loss journey—I’ll tell more about that in a future post. But I just heard a statement once again that confused me for a long time: > When you’re losing weight, you need to be careful that your body doesn’t burn your muscles instead of your fat. This is very misleading and oversimplified. It can sound as though you’ll stay fat while your body consumes only your muscles. It sounds daunting and makes it seem more difficult. In reality, your body does not choose exclusively between burning fat and losing muscle. Weight loss usually consists of body fat together with some fat-free mass (water, glycogen, muscle, etc). A frequently cited rule of thumb is that roughly 75% of weight loss is fat and 25% is this other fat-free mass. This is only a very rough average because the actual proportions vary between people and diets. Another common rule says that saving 7,700 calories means losing roughly 1 kg of body fat. In reality, if you have a deficit of 1,100 calories per day, you’ll not lose exactly 1 kg after a week, and you won’t see this progress happening linear, day to day, on your scale. Weight loss is not linear, and short-term changes in body water can change what you see on your scale. However over many weeks and months, I found this to be a reliable estimate, even if it’s not an exact prediction. It’s very rewarding to see this relation between cause (calorie deficit) and effect (losing weight that closely matches the calorie deficit), so I keep doing it. Over weeks and months, for people with excess body fat, a sustained healthy calorie deficit will cause weight loss largely from body fat. It’s true that there’s also some weight loss from fat-free mass, but it will not cause losing drastically less fat and instead lose too much muscle mass. Whenever I started dieting, I was told that I had to do strength training or else I would lose muscle instead of fat. So I always tried to combine my diet with strength training, but doing both was too much for me. It’s exhausting, was difficult to fit into my daily life, and often caused me to abandon the diet altogether. That rough 75/25 ratio can change slightly depending on what you’re doing. Strength training can have a positive effect, and even just having more protein without strength training can have a positive effect, but both are not required for fat loss. A sustained calorie deficit without strength training will still result in substantial fat loss. [Footnote: Assuming a person with excess body fat. I’m writing this disclaimer because people and bodies are different, so absolute statements are difficult. But with excess body fat and a healthy diet with ~750 calories deficit per day, you will lose fat.] In my current diet, I’m not doing strength training. Instead, I have reduced my overall calorie intake while making protein a larger part of my diet. I do this partly because protein may help me to retain more fat-free mass, but mostly because it helps me feeling full for longer. I also continue walking 8,000-10,000 steps each day. That’s sustainable for me and results in losing 3-4 kg per month, and I’ve lost 18.6 kg so far.

There’s a new bug in the YouTube TV app for Google TV that is so utterly stupid that I need to rant about it. When you play a video and press back on the remote, it should jump back 10 seconds. Well, now it now jumps back 10 seconds… and then immediately skips forwards 10 seconds to where you were before. So pressing back is basically doing nothing anymore, other than glitching a bit. You have to press back multiple times, or pause first and then press back. The same thing also happens when you press forwards: It skips forwards 10 seconds, and then jumps back to where you were before. This is already pretty annoying. But now comes the best part: There’s this “Jump ahead” YouTube Premium feature that entirely skips a commonly skipped segment. You press forwards once, it knows that many people skipped this segment as well, and then jumps ahead to where other people usually jumped to. It basically allows you to skip sponsor segments quickly. So you press forwards once on the remote, it skips to the end of the sponsor segment, and you can immediately continue. That’s a really great feature! The UX is a bit meh but in theory it’s a great idea. But now, with this freaking new bug, it skips the sponsor segment, then glitches back, and then thinks that you didn’t want to skip the whole segment (because it looks like you jumped back), so it removes this skipping point so moving forwards won’t skip the whole segment again. Which means you can’t skip the segment again. So this whole freaking feature is now not working anymore. There are some UX lessons here about these “magic features” that sometimes appear and disappear that I might want to write about in the future, but for now I only care about how the actual fuck it’s possible that the YOUTUBE APP—the official app for THE SECOND MOST VISITED WEBSITE ON THE WORLD—developed by FREAKING GOOGLE is constantly shipping broken crap that’s noticeable within seconds of using a core feature. When did software turn so shit?

The number of times I still see “Loop Engineering” popping up in any of my feeds is truly upsetting. The amount of effort you spend on meta-engineering is an illusion of a return on investment that will allow you to build the product better, faster and with greater ease. It’s the same as building your own framework, or framework-in-a-framework, because you think that all other frameworks out there are slowing down your ability to build the actual product. While you’re building your bespoke framework, you’re not building the product. You’re not using it, you’re not feeling whether the idea you had in your mind is actually working that well. You’re not shipping anything, and you don’t get user feedback. “Question your requirements, delete unnecessary parts of the process, optimize them, automate last.” That’s roughly an Elon Musk quote. I want to emphasize that I despise Elon Musk and I wish it wasn’t his quote. It’s very fitting to software engineering cycles as well. I cannot fathom how we evolved backwards into believing that we should focus on the automation first. You’re building your own illusion of future productivity. But just like building your own framework, it won’t work quite like you imagined it would work (who would’ve thought!), and you continue to tinker with your custom framework instead of building the actual product. You’re adding unnecessary requirements with unnecessary parts and telling yourself it will pay off. You will hit the same inevitable experiences: the features you add to the product don’t feel right, you need to iterate, but iterating takes the same amount of time as before, with the addition that now you’re hitting snags in your own bespoke framework (or automation), so you spend time tinkering with it instead of iterating on the actual feature. It’s a downward spiral and you will feel worse. It will only take a few months and the next “groundbreaking” way to work with AI is shoved down your throat. Anxiety will hit you, you’ll abandon your loops, and jump onto the next hot thing. If tinkering with these things is fun, then tinker with them. But keep in mind that you’re playing around. You’re adding something that you don’t really need, and you’re not building the goddamn product.

Every few months, software engineering will be over in a few months again. It can’t be, but for reasons you might not expect. When coming back to work in the beginning of 2026, organizations everywhere were going crazy. So many people, including lots of upper management, had used the winter break to build software with AI and felt that software engineering was over. They had experienced it first-hand. Everything had changed, because look at what they built! Why couldn’t work feel the same? Their experiences were real, but they happened in isolation. Building software by yourself is orders of magnitude easier than building it in a team, or across multiple teams. The hard problem at work was never just about writing code. Their experiences didn’t reflect the challenges of the organization they worked in. ## Organizations divide ownership Organizations aren’t challenging simply because their structure is wrong and they need to fix it. Their structure might be wrong, but every structure is wrong for someone. If you were ever part of a reorg, you probably saw that some people thought it solved the problem, while others thought it made everything worse. Still, organizations have to structure themselves somehow. Not everyone can know everything and work on everything. So they divide the work into domains, with a team for each domain. Over time, each team builds deep knowledge around its domain and develops a vision for where it should go. This is good agile software development: people take ownership, plan, build, adjust, and learn from what happens. But those domains are never fully isolated. They overlap or depend on each other, and they keep changing as the product changes. ## The tension in ownership This ownership model that produces great results is also the main reason why organizational structures are so difficult. It’s hard to give teams a lot of autonomy to materialize their own vision, while also making sure that they don’t create issues for other teams and largely follow the grand vision of the company. These are the two values autonomy and alignment. We need both values not simply because they are good values to have, but because each one solves a failure mode that the other one creates: Pure autonomy without alignment results in teams that move fast in incompatible directions. You ship a lot, but it doesn’t add up to anything coherent. Eventually you accumulate so much inconsistency that the organization slows down anyway: integration nightmares, bad user experiences, duplicated work. Pure alignment without autonomy results in an organization that knows exactly where to go but can barely move. Every decision needs sign-off, every team is blocked waiting for consensus. And after waiting for so long before shipping anything, you learn from your users that you shipped the wrong thing. Autonomy and alignment are in tension, but this tension is important, even if it feels frustrating. It feels frustrating because the symptoms look like problems we need to fix: the meeting that should have been a Slack message, the RFC nobody reads, the three different date pickers that all don’t work for what you need. Some people ask for more process, trying to create alignment. Others want to strip process away, trying to restore autonomy. The tension never goes away. It cannot go away. It just moves closer to one of the failure modes. ## Tension needs to be felt It’s tempting to use AI to skip the tension that we feel. Instead of talking to another team, we can describe their boundaries to an agent: what it can touch, what it should avoid, what vision it should work towards, and generally how it should behave around their domain. But when the agent needs a change that crosses these boundaries, it will not negotiate. It doesn’t feel awkward about stepping into someone else’s area. It will work around the boundaries instead. It can easily copy some code from another team, paste it into the area without these boundaries, make the small change there, and move on. For a senior engineer, that would feel wrong. The consequences are immediately obvious: now you have to maintain that new version, the two versions will diverge over time, and bug fixes will eventually be applied to one version but not the other. This feeling is worse than the discomfort of going through the tension with the other team. So you reach out and explain what you need. And somewhere in that conversation, your work shapes their domain, their context shapes your solution, and the organization becomes slightly more aligned than it was before. The human feeling is important. It is what makes you stop before turning tension into a bad decision for the organization. It keeps autonomy and alignment in balance. ## More autonomy means more alignment This matters even more now, because people who couldn’t write code will now want to use AI to contribute more directly. Designers can make adjustments by themselves, Support can replicate bugs and propose fixes. This is a good thing. The organization benefits from it. A lot of work exists because someone understands a problem, writes it down, throws it over a wall, and waits for an engineering team to look at it during a backlog refinement session. We can now lower that wall. As that wall gets lower, more people will cross into domains they do not fully own. It will no longer only be engineers reaching out to you because they want to change something, but now non-engineers will reach out too. Not because they want you to change something, but because they want to change it themselves. They want autonomy, and by reaching out to you, they create alignment. That is good. The surprising outcome is that when you give more people the power to act, you force more of these human conversations to happen. It keeps the tension in balance and prevents it from drifting toward one of the failure modes. They cannot skip the conversation, because if they want autonomy, they need alignment. But your answer also cannot simply be: “you are not allowed to touch this.” ## You will become a better engineer Your job as a software engineer will not disappear, and it will not drastically change because of AI. It will change in the same way that every software engineer’s career changes over time: you will become a better engineer. Being a better engineer never meant writing more complex or smarter code. As a good engineer, you know how to move through other teams’ domains without taking ownership away from them. You explain what you need, but you also listen to what the other team is protecting. You adjust your solution around the context you gather. You create alignment while still letting the other team own the decision. And you bring that same mindset when someone reaches into your domain. You do not just block it, and you do not blindly approve it either. You guide that person through your boundary. You share context about what is safe, what is risky, and why. You listen to their needs and adapt your domain when it reduces future friction or makes contribution easier. And you aren’t nitpicky when a solution works, even if it’s not as elegant as the one you would’ve written. This is where AI can help you, but not replace you. ## Use AI with you in the loop Use AI as a tool inside the boundary you’re in. Let it explain code you do not fully understand yet, or a technology your team is adopting. Draft an architecture and let the AI point out risks, compare it to common design patterns, and surface flaws you haven’t seen yet. Use it to understand how the product is used, find answers in analytics data, recognize patterns in user feedback. This is good use of AI because you’re not asking it to replace your ownership. You are using a tool to become more capable inside your area, so you can make decisions you can stand behind. You hold yourself to that same standard when you’re crossing into someone else’s boundary. AI can help you prepare: turn a vague need into a clear problem statement, help you understand the tradeoffs, and find the right question to ask before sending that ineffective “I have a problem” DM. And yes, use AI to be your coding partner whenever you need it. For me, I like to focus on the architecture and plan it out completely. I write the types and interfaces by hand, and let an agent finish the implementation details that are a chore for me: the repetitive plumbing and the stuff I already know how to write but don’t want to. This is what often works for me. I feel that I’m growing as an engineer by sharpening the skills that matter most to me. This is like the human-in-the-loop pattern, but applied to a whole organization. People use an agent inside their ownership zone, then talk to other people, who use an agent to process that new information inside their ownership zone. The humans are still at the center, they’re just better equipped now. Conversely, don’t use AI to take the humans out of the loop. Don’t use it to work around another team’s approval. Don’t use it to generate arguments you do not fully understand, just to tell another team why they are wrong about a domain they spent a much longer time becoming experts in. I wouldn’t one-shot a system I don’t fully understand. When someone asks me how the thing that I shipped last week works, I need to be able to answer that. Ask yourself: after using AI, am I more prepared to own this decision? If the answer is yes, it helped you become a better engineer. If the answer is no, it probably helped you avoid the part of engineering that matters most. Use AI to become a better software engineer. Just don’t forget why software engineering at work was hard in the first place. ## Back to the beginning of 2026 The people who came back from their winter break, convinced that software engineering was over, had built something real. Their experience was real: creating and contributing code was now easier for them. It is genuinely easier to build the things that you wouldn’t have built before. Their conclusion, though—that software engineering as we know it was over—was wrong. They had discovered a tool that gives them more autonomy. More ability to turn an idea into something working, without waiting for someone else to translate it for them. But autonomy was never the whole job. AI can help us move faster inside the boundaries we own. It can help us understand the boundaries we cross. But it cannot remove the need for humans to feel tension, negotiate, adapt, and shape a vision. It cannot remove the need for software engineers to do the actual work of software engineering: helping people turn ideas into working systems, without letting those systems fall apart. The tools around us will keep changing, as they always have. The boundaries of our domains will keep shifting, as they always have. The tensions in an organization will create discussions, as they always have. What remains is the elegant craft of listening, explaining, discussing, and adjusting so the system holds together a little better than it did yesterday. If that’s what you care about, then software engineering was never going to be over for you anyway.

More than 15 years ago, I had this idea to autogenerate the header image of my website based on the current time of day, season, location, and a simulated weather pattern that naturally progresses. It fascinated me to have a long-running, realistic-feeling, autonomous system that changes itself without my involvement—like its own little world. I liked the idea to open my own site and being surprised by what I see. “Oh, it’s snowing!”, then seeing the snow melt away some time later, or observe the bleakness of misty autumn days. Back then, I tinkered with layering PNGs on top of each other to create “random” scenes, but it looked terrible. I can design websites, but I can’t draw nice pictures. I never ended up doing it because 1) I didn’t miraculously become a good artist, and 2) who cares. Well, I care. I’m older now, and the fascination is definitely weaker, but I still thought about it every year. When my most favorite time of year starts, I get this itch. And this year, I finally scratched it. AI made this much easier to solve. Not just for creating the images, but also for simulating the weather progression based on the time of day, the season, and previous days. Everything is now truly unpredictable, there isn’t a single line of code where I can already guess what will happen next. New scenes get generated four times a day, and I feed the AI with previous days to create a natural progression. I’m storing all the prompts, images and weather simulations (in a Railway Bucket of course).