A Once-in-a-Generation Technology Shift 

The bulk materials industry is undergoing a significant technological transformation.  Organizations across the sector are actively migrating, or evaluating the migration, from on-premises legacy systems to cloud-based platforms. User expectations are correspondingly high. The information required to operate these businesses has not diminished; if anything, it has expanded. What has fundamentally changed is the speed at which data is expected to be available and the urgency with which users want to access it. 

This shift is evident across several critical operational decisions. Companies are replacing paper tickets and bills of lading with electronic tickets. They are moving away from traditional mail-based invoicing and check processing toward customer portals that support digital invoices and electronic payments. At the same time, organizations are  rethinking how data moves across their technology ecosystems, transitioning from manual data transfers between systems to seamless, API-driven integrations among best-of-breed vendors. 

Individually, each of these initiatives presents meaningful challenges. Collectively, they can feel overwhelming. Compounding this complexity is the growing number of software vendors claiming to leverage artificial intelligence (AI) to enhance product development,  

customer workflows, and management decision-making. The rapid emergence of large language models (LLMs) such as ChatGPT and Claude has further accelerated interest in  AI, while also increasing uncertainty around what is practical, proven, and valuable versus what is aspirational or marketing driven. 

Larger material producers, waste management companies, recyclers, and organizations in agriculture face an additional layer of decision-making: how to right-size their technology organizations in this new environment. Leaders must determine which capabilities should remain internal, which should be outsourced, and where AI can responsibly augment, not replace, existing teams and processes. 

While this article is written for a general technology audience, it is particularly relevant for professionals in the bulk materials industry who are navigating these changes. Its purpose  is to help separate substance from hype around AI, provide context for current technology  

trends, and offer guidance on how to thoughtfully align technology investments and organizational resources with real operational needs.

Don’t Fear AI or “Vibe Coding.” Learn to Lead It. 

Are you concerned about losing your job because of the impact of AI?  

That question is being asked by young developers just starting out, mid-career engineers and managers, and even for senior CIOs and CTOs responsible for maintaining existing legacy systems while deciding whether, or how aggressively, to invest in the next generation of software platforms. Given the pace of change, that concern is understandable. I feel compelled to offer my counsel. 

I have spent more than 40 years as a software developer, development manager,  entrepreneur, and executive search consultant. I currently own a 10-year-old software company TruckPay (www.truckpay.com & www.mytruckscales.com), and an executive search and management consulting firm, Honig International (www.honigintl.com), which I  have operated for more than three decades. Over that time, I have placed many well known senior technology executives across the financial services industry as well as rock  star individual contributors in electronic and systematic trading.  

A Career Spanning Every “Revolution” 

During my career, I’ve written code and led teams across every major transition in software  development: 

• IBM mainframes and assembly language (BAL/370) running on VM and MV
• Early vector languages like APL 
• Algol languages like Pascal and PL/1 
• More FORTRAN than I care to recall 
• C and C++ for electronic trading systems 
• Java, PHP, TypeScript, SWIFT, React Native, and others,  
• Even owning a company that created a C-like time-series and vector-manipulation language. 

I’ve lived through all of the “religious” debates of functional versus object-oriented  programming and compiled versus interpreted languages. There is endless evolution of  software: 

• The advancements of UI development starting from green screens on IBM 3270X  terminals to sophisticated animations on the web and mobile devices
• The migration from line editors to sophisticated IDEs 
• The advancement of putting print statements in code for debugging to using  sophisticated interactive real-time debuggers. 

Since the creation of computers, programmers have constantly sought easier ways to  develop software. Compilers were created to enable programmers to write code in higher level languages, like C, C++, Pascal, and others, than in low level assembly language.  Interpreters or virtual machine languages like APL, LISP, Java, Python, and RUST, have further pushed this concept by providing even more powerful language semantics and features. These languages allow developers to more concisely express different algorithms.  The difference now is that when you describe a problem in natural language, large language 

models (LLMs), like Chat GPT and Claud, can write the code for you. So, the question remains, should technologists feel threatened by these latest developments? I think not,  provided technologists are willing to rewire and refocus their brains. 

What’s Actually New About LLMs 

While “Vibe Code” seems like a revolutionary advancement in software development,  functionally, this is just a more sophisticated extension of what developers have done for  many years to more easily create software: borrowing open-source code, using online  platforms like Stack Overflow or doing simple Google searches. In fact, code generators  have been around for a long time and UI code generators have been around since the  1980s. I actually used one when I built a trading system on a Vax/785 in 1986. 

Despite the hype about AI eliminating the need for tech jobs, Vibe programming is simply  the next step in the evolution of software development languages. And like all changes,  this one has unique challenges. One major difference between LLM generated code and compiler generated code is that compiler generated code is deterministic, whereas LLM  generated code is unpredictable. A good compiler will produce the exact code to be  executed, in the compiler’s target language, to solve the problem at hand. Vibe code,  however, may not necessarily solve the problem because of the imprecise way the problem  was described. In other words, the flexibility that Vibe coding provides, if not properly  scrutinized, may be quite detrimental to developing a robust system. Think about it,  English is not nearly as precise a language, as say Java, for describing a complex algorithm.  

The future for developers, therefore, is not developers writing mountains of code. It is developers: 

• Writing smaller amounts of code and correctly using LLMs to generate the bulk of it  ▪ Correcting, validating, and optimizing LLM generated code and 
• Designing systems that actually solve business problems 

In other words: Vibe coding is simply the next higher-level development abstraction layer,  but it still needs to be guided by skilled developers. 

The Frontend Myth and the Reality 

While AI will greatly impact backend developers, it will potentially have an even more  profound impact on frontend developers. The ability for generative AI to create very  sophisticated and aesthetically appealing user interfaces is quite impressive. AI’s ability to  do this will only get better over time. Having said this, at the present time, AI platforms can  generate overly complicated UI/UX experiences, an outcome that the user community of  the app may find to be undesirable. It is worth noting, great tools do not guarantee great designs. Human judgement remains essential. 

Historically, every improvement in new software development tools inspires the same  myth: “non-technical people will now be able to build enterprise-class systems  themselves.” As tooling improves, user expectations always increase, a modern version of  Parkinson’s Law: All available productivity increases are consumed by rising demand for  more complex software. In other words, all available developer time will be taken over by 

increased user demand, simply because it will be possible to produce software more  quickly.  

History also teaches us, however, that improvements to software development tools, if not  properly used, result in very badly designed systems. The trap people fall into is that they  think that better and faster development tools are a substitute for strong logical thinking,  system design, knowledge of the domain, and a full understanding of user requirements for  whom the system is being built. AI does not eliminate the need for these skills. Stated  quite simply, developers and development managers can expect to be busy for years to  come, provided they have these skills. 

Over the last 25 years it has become fashionable for technology organizations to bifurcate themselves into development teams and product teams, segregating engineers from  product managers and business analysts. This organizational model has led to a  generation of developers being quite competent at building software but having very little understanding of the domain, why the software is being built and how it will be used.  Interestingly enough, the creation of more advanced development tools, the broad  proliferation of third-party libraries, and the availability of powerful Integrated Development  Environment (IDEs), have all led to a generation of developers, many of whom, really don’t  thoroughly understand at a low level, how computers actually work. As a consequence,  and not surprisingly, some people think that if AI can write the code, based on designs that  a non-technical domain expert feeds the LLM, there is less of a need for developers and  engineers. That thought process, however, leads to a dangerous misconception. 

What AI Still Cannot Do 

Even where the system requirements are fully flushed out, AI has its pitfalls. For example,  AI currently cannot: 

• Identify unmet market needs 
• Decide what products to build for a particular business, industry, commercial  market or consumer use.  
• Understand the domain and what is missing or needed in a market place, what type  of software or product would be cool to have or would make us more productive
• Make real judgement calls. This is strictly the province of humans, at least for now
• Create fit for purpose system architecture and data design 
• Guarantee security, scalability and compliance. 

So, what should a developer, development manager or a UI/UX designer do to keep  themselves relevant and indeed, grow in their career with Vibe coding all the rage?  

The Return to Domain-Centric Developers 

Developers and development managers need to return to the old model of being product  managers, domain experts, business analysts, as well as developers. Developers with  technical training and deep domain understanding will: 

• Prompt LLMs more accurately, to create more deterministic code i.e. to produce the  code that is needed for the job. This will be done by developers, system architects,  and data analysts providing the LLM scalable architecture and data design to assist in the generation of the most usable code. In other words, a team vibe coding  effort. 
• Validate, enhance and refine the generated code to make the solution better fit for  purpose.  
• Build systems that match real-world needs and 
• Produce secure, scalable, enterprise class, production quality solutions. 

As a developer, you are already trained to think logically, with great focus on detail.  Traditional product managers, business analysts, even sales people may be able to  describe certain aspects of a system, but frequently, they are not trained to or even have  the mindset to think of all of the minutia that generally turn out to be the most important  determinants of a system being scalable, secure, and commercially viable. This is not to  say that product managers and business analysts do not play important roles in the  software development ecosystem. They do. But not as enterprise class system developers  and development managers.  

This return to domain-centric development will not only require developers to learn how to  be strong vibe developers but will also require that developers and managers thoroughly  understand the domains in which they’re operating and how users will interact with their  software. Becoming a strong vibe developer or vibe manager is no different now than it was  in the past. Developers and managers have learned to move from using punch cards in  assembly language to using FORTRAN, then PL/1, and then Java and C/C++. Then as now,  developers and managers must rewire their brains to have a different paradigm of software  development. This is no different than when we had to evolve from writing code to move  data back and forth from memory to registers, to structuring code in subroutines and  functions, to writing object oriented code, or to manipulating arrays and lists with single  commands. 

Developing code through prompts and refining the code that is produced by them, will still  require the same level of precise logical thinking as traditional programming has. You still  have to know what the hell you want to build. But now, the way you express those ideas is  more linguistically natural. Amusingly, when I was a young developer, we used to joke that  it would be great to have a “Do as I say” or “Do what I mean” command. With Vibe coding,  you now have those commands at your fingertips. You just need to really know what you  mean. 

Security Risks 

Recent online articles have pointed out that Vibe coding, done by non-technical  individuals, frequently results in code that isn’t secure. In today’s world, with many bad  actors trying to hack systems, the potential risk of deploying unprotected code is  disastrous and should be avoided under all circumstances.  

A Personal Perspective on Domain Mastery 

Let me speak from personal experience. When I started developing software back in 1980,  (and yes, for you smart-ass young people reading this, there were computers back then)  developers had to know the domain in which they were developing. In my case, I was  building software for forecasting the sales of IBM mainframes, so that IBM planners could 

determine how many machines to build over the next several years. In order to build these  models, I had to thoroughly understand both the models and how my users would be using  the software. In other words, I was both a developer and a domain expert.  

When I worked in the financial services industry, I built, at the time, one of only three real time, 24 by 7, global FX trading platforms. It was written in FORTRAN on a VAX/785, running  optimization simulations on an IBM 3083 mainframe, running VM/370. I later rebuilt this  system in C, running on SUN/OS, with Unix. I became such an expert from building these  systems that I eventually became an Adjunct Professor at New York University, lecturing on  systematic FX and commodity trading. 

When I worked at Morgan Stanley, in the 1990s, I managed a team building a real-time FX  options trading platform. From this experience, I developed a deep knowledge of options,  so much so, that I can today, still perform delta and gamma hedging calculations. I also  eventually owned my own systematic trading firm and became and still am, a licensed CTA  and CPO, although I haven’t traded in many years. 

In the early 1990s, I also used, what would be called today, machine learning, specifically,  kernel regression or nearest neighbor algorithms, written in FORTRAN and PL/1, running  again on an IBM mid-range mainframe, running VM/370 to forecast commodity price  movements. I had to learn this material so thoroughly that when I interview candidates  today for jobs in ML or AI, they ask me if I’m the hiring manager, as opposed to the search  consultant. Ironically enough, it depends on which hat I’m wearing, the Honig International  hat or the TruckPay one.  

Subsequent to my initial career in development, I’ve either built, managed, or served as a  management consultant in the development of object oriented FX trading systems, low  latency electronic trading, and large-scale market and credit risk systems. In my relatively  new domain of bulk material logistics, for which I have been awarded 7 patents, I have  designed and managed the development of mobile and cloud-based systems to digitize  industries that are drowning in paperwork. Because of my focus on learning my new  domains, I can speak, at any level of depth, on the production of ready-mix, the workflows  in the aggregates industry, how transfer stations, landfills, material recovery facilities (MRFs) and scrap yards operate, and in agriculture, what data is required when delivering  and transporting grains. In each case, I have thoroughly learned each domain, so that I  understand the needs of the users for whom I am building the software platform.  

Final Advice 

In conclusion, my advice for technologists that want to thrive in the age of Vibe coding: Don’t Fear the Future. Shape It! 

The traits that made technologists successful for decades still matter most: 

• Intellectual curiosity, learn as much as you can  
• Deep domain expertise 
• Logical reasoning 
• Pride in craft 
• Adding real value

AI will remove some of the drudgery of coding, freeing you to become a better thinker and  system designer. Learning different domains will make your job more interesting and  exciting. Senior technology managers, be careful about outsourcing development in the  hope that lower cost non-technical Vibe developers can build your systems more cheaply.  Ultimately, it may be more costly. History shows that long term success depends on having  technically strong, domain-savvy professionals inside the organization.  

As an old boss once told me, “You are your own product, so improve your product every day!”