Alexander Knapp

Cloud vendor lock-in was yesterday’s problem.
The next big risk? AI vendor lock-in.
Pricing, data, dependencies – are you ready? 🔒🤖 #AI #SoftwareEngineering

AI is reshaping software engineering – for better or worse.
It brings new challenges:
👉 AI vendor lock-in
👉 Data security concerns
👉 Dependency on pricing and providers
How are you preparing? 💡 #AI #TechChallenges

David Heinemeier Hansson nailed it:
Current AI tools like ChatGPT are like “superb junior developers.”
How long until they reach the level of a “superb senior developer”? 🤖💻 #AI #SoftwareEngineering

OpenAI Pro costs $200. Devin Pro is $500.
Are these tools worth it? Or are we just paying for “superb junior developers”? 🧑‍💻 #AI #DevTools

Agentic AI Software Engineering: A trap or the future?
Is 2025 the year we move away from traditional software engineering toward AI-first approaches? I'm skeptical. 🤔 #AI #SoftwareEngineering

So would you say that streams are over-engineering and that I should use loops instead? I'm asking for a friend... who uses streams all the time ;)

Sora is not available in the EU at launch. A testament to a lack of European innovation or proof of responsible network policy? I'm not sure.

Developing software is not building a house. There is a misconception that it's the same, but it is not. In Software, I can change the foundation. I can tear open windows. If I can't, I have a bad architecture. In contrast to building a house, good software architecture allows me to make changes.

Have you ever tried: “This meeting could have been an email. Since I can't contribute anyway, I'll just leave.” The reactions are priceless ;)

Estimates are always wrong. When it comes to software engineering, we should consider not doing it at all. If only it weren't for customers who want to get a cost estimate.
Anchoring is interesting. If the same teams keep estimating, they will always come up with the same value. #noestimates

Agree. The best software architecture is the one you can easily change when change is needed.

Could it be that these 'symptoms' are caused by developers being squeezed into processes and buried in waste, rather than delivering the things they should and want to?

Why we can't focus. YouTube video by Jared Henderson

Jared Henderson talks about "amusing to death". In a way, I think this also applies to modern software engineering. Not in terms of entertainment, but there is just so much going on. Follow every trend, learn every new tech. We can't just focus on delivering business value with software anymore.

Let's categorise individual software development into three sizes: small, medium, large. How we implement these sizes is different. Small project: just start coding, get frequent, quick feedback, done! The other end -> large: first think about business model and its future, don't start with coding.

Bluesky, help me out: What are the best resources for building RAG systems? Books, blogs, videos...? #RAG #ai #machineLearning #SoftwareEngineering

I guess this will be the same strategy that we have seen in many other areas. Now they hook us with low prices and later, when we are dependent, the prices are raised and revenue is generated. Few providers will survive.

So, finally, there is also concentrated software engineering expertise on Bluesky. Life as a software engineer makes sense again. @davefarley77.bsky.social @kentbeck.bsky.social and many more to come.

Releasing very often is not only "agile" in my opinion. It should be the standard. Period. I can't think of a case, with very few exceptions, where parking software somewhere is useful in any way.

I love that headline. I will use it from now on when developers ask me how often they should release. I would add: and make sure users test ridiculously often, too.

Measuring developer productivity: There are many frameworks out there. I recently stumbled across DX Core 4, where the number of PRs/MRs is one of the metrics under the category "speed". What exactly does it measure? A high performing, agile, trunk-based dev team would have a value of zero.

Why is estimation still used in software engineering? Estimates are wrong. When it comes to giving cost estimates to clients, can you measure the effort? You can't? Then make it smaller. Make it even smaller! Focus on small functional deliveries that you can measure. That is agile. #noestimates

That's a great point. I agree - Scrum is excellent for getting started. But over time, as teams internalize agile principles, the need for strict adherence to a framework diminishes, allowing teams to adapt. In think mastery of agility is less about the framework and more about the mindset.

Scrum is the paint-by-numbers approach to agile working. Not that I want to downplay it, but anyone who has understood agility in software development and in a business context no longer needs a framework. On the first step towards mastery, it provides a reasonable canvas. #agile #scrum #software