Mindera is a real global company, with offices in 9 countries and people working from multiple other locations.
When my team started organising our AI Open Hours we decided to communicate the time of that meeting in all the locations, to make it easier for everyone to figure out if it would work for them. That meant that our messages were always that much longer and noisier.
Today, as I was preparing another message I decided to find a tool that would allow me to share just a single time in my current timezone and have people easily figuring how it would translate to their location. After a couple of google searches I gave up on that path and decided I'd just use Github Copilot to create a simple tool that would give me what I wanted. And so Time in the Zone came to be.
It's a one page tool built with HTML, Javascript and CSS that shows the current time in Portugal as well as in other Mindera offices' locations and other remote timezones. Besides that it also allows us to see times for a specific time, date and even changing the reference location, all using query parameters.
The configurable parameters are:
• ?time=14:30 - Show specific time (uses today's date)
• ?time=2025-12-25T14:30 - Show specific date and time
• ?timezone=America/New_York - Change reference timezone
• ?office=India - Use office location as reference (Portugal, India, Brazil, etc.)
• ?time=14:30&office=Morocco - Combine time and office parameters
[Time in the Zone screenshot]
Given that this was a tool with a small and clear scope, and which won't have any further dependencies or with any associated risks it was completely vibe coded, using Github Copilot. I provided the ideas and the features definitions and then asked Copilot built it without me paying any attention to the generated code, only to the generated features and functionality, ensuring that it did what I wanted it to do. Or adjusting when it wasn't quite right. This is quite a big difference from when I'm using AI assistants...
Clearly out of my 48 feeds I have some favourites or there are people that write things that resonate more with me.
I will try to start taking notes about what leads me to star articles so that I can bring more value to these posts. But if you do enjoy any of the articles make sure to follow their blogs. As much as it might seem... I haven't starred all of the articles that they published! 😅
This weekend me and the family went back to Cambridge.
It was very good to revisit it and to see how it has, and is evolving. It was great to see that none of our favourite restaurants are still open. It was nice to meet old friends, and their old and new offsprings. It was not enough time to do and see all the things that would have been great to see. It was tiring, because little children have lots of energy and amazing ideas on how to play out of the box, or inside the box, or on the box... It was surely a visit to remember, and above all to know that we want to do more of it.
This weekend was just the first time we traveled abroad with the kids, and it won't be the last for sure.
In October I read ~301 articles from the 44 blogs that I follow on my feed reader. These are the ones that really caught my interested and which I starred:
Over the past few weeks I have been testing a few AI code assistants like Claude Code, OpenAI Codex and Github Copilot. I'm using to vibe engineer some personal projects but also to try out new ways of building software at Mindera.
Using AI to write most of my code makes me think that the role of a developer might evolve to more of an architect. Someone who thinks about what they need/want to build and then orchestrates AI to actually get it built. But as I do this, I am seeing two types of situations that will make a full evolution like this a bit slower than some predict, or even challenge it. Namely:
1. When I'm building something that is not as standard as most of the things I build (ie: something that isn't just CRUD pages and typical interfaces), AI tends to struggle more to deliver working solutions. Or at least takes longer to get it right than more conventional examples. I've seen this described as building things that fall off the distribution curve. The tech stack also has an influence here. AI might push for more standardisation as many of these models are much better trained on stacks like ReactJS. Tech choices will need to consider this.
2. When I'm building something that I've never built before versus something that I have built before. For example, the other day I was building user invitation system for a project, similar to the one I built for Kronflow earlier this year. So I was able to see that Claude Code wasn't building the feature in the right way, and I could intervene and ask it to adjust its approach. This means that when I'm building something that I haven't built before, there is a higher chance that it will be written poorly without me realising.
Point number one might be a bigger issue than point number two, because "poor" might still be acceptable, as long as it's not insecure and bug-ridden. But if AI doesn't build the thing properly, a human will still need to step in.
What this tells me is that to guide AI adoption we...
