A Java Geek weekly 161

Digital Twins, are digital replicas of physical assets, processes, or systems used to simulate, monitor, and optimize their real-world counterparts. Through real-time data exchange and advanced analytics, digital twins provide a virtual environment for testing scenarios, predicting outcomes, and enhancing decision-making. This concept, first introduced by Michael Grieves in 2002, has rapidly evolved and now plays a crucial role in various sectors, including manufacturing, healthcare, smart cities, supply chains, and more.

They serve as the foundation for emerging tools like the Digital Product Passport, which aims to enhance transparency, traceability, and circularity in product lifecycles.

Digital Twins are the entry point and keystone transitioning to Industry 4.0. In the context of Industry 5.0, they align with goals such as human-centric innovation, sustainability, and resilience.

With agents making the choices technical and developer marketing disciplines are going to be fundamentally reworked. We’ll certainly see attempts, many successful, to game the system – GitHub stars for the agent era. SEO for software agents (GEO). The zone will be flooded with vendor slop.

All that said, I remain cautiously optimistic. Trust and authenticity and clarity perhaps have more value than ever – the need to understand and synthesise the choices and thoughts of smart engineers to get better work done. Models need good signal and inputs to have good outputs. Agents are the new new kingmakers, but humans are still very very good at systems thinking, architecture, and creative thinking. I plan to recommit to writing more to help stake my claim, and help others navigate, this new frontier.

Large Language Models enable small teams to produce software and documentation of staggering scope and complexity in a remarkably short time. Five years ago, writing a distributed SQL database of this scope might have taken hundreds of person-years.15 With LLM assistance, a handful of engineers at Orkes were able to produce a highly sophisticated database system.

However, our work on ParticleDB (and other databases) suggests there are serious tradeoffs to relying on LLMs. Quality suffered: ParticleDB was a fractal of correctness errors. LLM tooling repeatedly claimed that bugs had been fixed when, in fact, they had not. ParticleDB also seemed more difficult to understand than typical databases. As with most Jepsen analyses, Orkes engineers offered detailed explanations of the causes and resolutions of the bugs we found in Conductor. However, Orkes seemed unable to explain the causes or resolutions of nearly every issue we found in ParticleDB. New builds simply materialized, sans changelogs, each hopefully containing a slew of improvements.