blog

In the previous post, we looked at the want side regarding Steve’s projection and the forces they trigger. We took off the rose-colored glasses and tried to have an unembellished look at these forces even if the things we saw, were a bit more gloomy and controversial than we would have liked it.

In the previous post, we looked at Steve Yegge’s post where he made a projection from the vibe coding of today to controlling AI agent fleets in the near future that take over all coding reliably. Pondering this projection as a possible future, we realized that this future is not what we need as our actual problems in software development do not lie in a lack of developer productivity (or to be more precise: developer efficiency) but…

This blog series will be a bit different. It might leave you with more questions than answers and I apologize for that upfront. It is also more controversial than most other posts, I have written before. In this post, I will discuss the current developments regarding AI in software development more from a CTO’s perspective. This means, I cannot simply reason about the pros and cons of a topic but I also need to take the market forces into account.

In the previous post, we started to discuss a specific type of coupling, the coupling between processes in a distributed system. We discussed the fallacy that loose technical coupling, i.e., using a message-based communication style is sufficient to ensure loose coupling between processes. We learnt that instead we need to implement loose coupling at a technical and a functional level to actually become loosely coupled.

Coupling is a big issue in software design. With software landscapes becoming more and more complex, coupling painfully steps on our toes whenever we attempt to change things. Hence, we want to reduce coupling. On the other hand, without any coupling systems and their parts would not be able to interact. Hence, we need coupling – feels a bit like being stuck between a rock and a hard place.