• I have started to use Co Pilot quite frequently for both coding and working out how to do things like implementing security in my code such as OAuth 2.0 etc. Looking back at my life as a developer from the days I was a student studying Computing at A-level to now, it struck me how much I don’t know now as I did all those years ago. Let me take you all back:

    Pre-Internet

    In the days before fast internet, we developers had to memorize syntax, and rely on our text based sources to understand programming frameworks and work out how to use certain commands in any programming language, and have a detailed understanding of the parameters that a command would need. I would say that we would commit near enough 90% of syntax to our own human memory that included us having to know which programming libraries you needed to use certain commands. In those days every compiler or database you would buy would come packed with large text books – it actually felt good when you opened up the discs containing the software – much like the Youtube videos you see of people unpacking their new mobile phones. The debugging process when facing problems in those days meant you developed an intimate understanding of your code and commands. Yes – things did take longer but at least you understood nearly 100% of what you were doing. Also, in those days it would be fair to say that not everything had been invented in terms of targeted software libraries that fulfill some targeted function, for instance back then many of us would implement our own sorting and searching routines rather than use one that comes within a framework – not because we thought it was fun, but more so because sometimes such routines were not available in the standard libraries.

    The Internet Years

    The advent of high-speed internet would bring about new habits for developers and that generation. Gone were the days of large textbooks, you would often have access to an online library (think MSDN as an example) for commands to use and written examples. Everything was available online or provided digitally with the installation (although documents being part of the installation were also available back in the previous era). Compilers were also becoming smarter, with built-in intelliSence to help you construct a statement in the code editor in real-time, and suggestions to improve code. At the same time the frameworks provided for developers were getting much larger and numerous so committing command to memory was becoming impossible on a human level.

    With all these improvements, you still had to think for yourself on how to do x, y, and z – and it felt like we had reached that point where a developer was actually focused on tackling the problem rather battling with their memory recall on how to write the code. But at the same time the various language vendors were peddling out new libraries and functions faster than before, and the popularity of the web meant that developers had to move away from the traditional desktop development and focus on the internet, which bought new challenges. What also made the development faster was the availability of web sites that tackled issues with code such as StackOverflow. Now if your code produced any errors during development/testing you could just copy and paste the error message into your browser and it would take you to a page where others had similar issues (or exactly the same issue) and you were presented with answers that resolved the issue. This certainly took the stress out of bug-fixing BUT something was lost. When we used to try and resolve a bug ourselves without the aid of such sites – we developers would pick up more knowledge along the way beyond just fixing the issue at hand.

    The internet years also bought some needed standardization to security and web development that was missing in its early stages, but also the emergence of many low-code platforms, collaboration and CRM systems that meant that you did not have to start from scratch. You had specialists now on specific platforms and a whole new industry emerged.

    The AI age and ‘Vibe Coding’

    So fast forward to now and I see a world where developers are hooking to AI libraries that offer various models to integrate into the software. I see the use of AI engines like Co Pilot, Chat GPT, and Claude being used to provide the code that needs to be written to perform the specific function you want. In most cases there is no need to truly ‘understand’ what each line is doing, just getting that ‘vibe’ that it does what you asked it to do, like seeing a finished dish without knowing the ingredients. I have used Co Pilot successfully to build workflows but have suffered pain along the way where it provided me the wrong information despite sounding so ‘sure’ of itself, only to later apologize that it had given me the wrong answer after I told it ‘you cannot do that’ !!!

    The title of this post suggests that AI will make developers ‘dumb’ – but just to be clear – what I fear most is that software problems will only be looked at through the lens of some AI engine and not through the experience of a human being. I worry that at some stage this will spawn up a new generation of architectural zealots that will only allow their software divisions to produce software and systems that are backed by an AI engine at every step of the development process. Personally I think we will be limiting ourselves, but also because when you ‘deep it’ ( to coin a phrase ) – all you are doing in using AI to do this ‘vibe’ level coding is actually being a more sophisticated ‘hacker’ to produce code.

    We are living in this age of AI, and rapid change, software development is also changing because of this, already we are seeing people developing workflow based systems through AI models that are best suited to the workflow problem and not through the logical steps as was done previously. There is phrase (actually idiom) : “keeping up with the Joneses” that we use, but for us developers I guess we can coin a new idiom which goes like “keeping up with the AI Models”.

  • Well how amazing – my first post on this blog was bringing to attention the faults of the modern day touch-screen dashboards that were becoming the mainstay of all the new cars in the last 3 years. But in the last few days – there have been numerous articles citing Mercedes-Benz and their change of approach based on data they have collected. It appears that in Europe we prefer to have buttons than the all singing and dancing modern day touch-screens.

    Apparently its the demographics – but I cannot help but wonder if this is to do with road-safety/car-safety authorities in each European nation considering the multi-functional touch screens to be a hazard in terms of distracting drivers. It would make sense, but less sense that the data collected also suggests that in Asia – the touch screen dashboards are preferred.

    Mercedes-Benz intend to ship the new cars for 2026 with more buttons, lets wait and see !!! – hopefully the other car manufacturers will follow in the same direction.

    For more detailed information on this please check out these articles:

    Mercedes-Benz is Bringing Back Buttons

    Mercedes-Benz to Bring back Cabin Buttons

    Mercedes: Oops Our Bad – We’re Bringing back Buttons

  • As I look around for a new car – I find myself laughing at these new dashboards that some cars offer, just look at the one below:

    Mercedes Dashboard
    Exhibit 1: Modern Mercedes-Benz dashboard

    It’s like someone has just stuck some flattened tablet – to many this is technological advancement, but for me it actually looks cheap and unsafe. I feel like anyone could just grab it and pull it out of the car with ease making the car completely useless. Manufacturers like to state that you can adjust the context (switch the displays etc..) – but do we really want that ? – imagine you are driving at 70 mph and you need to change something that used to be done through buttons but now you have to swipe the touch screen to get to your desired function. Surely the regulators should stop car manufacturers from creating these so called ‘innovations’ as it takes the drivers attention off the road. The argument that you would take your eye off the road to adjust a button control is a false narrative as most people have a feel and idea of where the controls are for specific functions of the car and have been doing so for decades.

    Personally I blame Tesla for all this:

    Exhibit 2: The Tesla Dashboard version 1.0

    Look at the above, they have not even bothered with any traditional driver features in the dashboard, it really looks like they have just dumped some tablet into the car as its main control feature. In many ways they have done a Steve Jobs type iPhone introduction to Cars just as he did to the mobile phone by taking away physical buttons and replacing it with on-screen buttons when you need it. But mobile phones don’t travel at 70 mph by their own do they ?

    For me the ideal dashboards should always be embedded inside some casing so that you know that it is hooked up to the mechanical/electronic parts of the car, not something that looks like you can just pull out. Also, is there not a worry about having a single control panel handling all aspects of the car – what if the touch-screen stops working ? does that mean the car becomes useless ?

    Cars are becoming more expensive and manufacturers love to include all these new electronic features and even charge extra due to these new dashboards. But are we being tricked into this ? – I think its actually cheaper for them to just stick a tablet on rather than create a fixed dashboard within a casing like they used to do (that’s not to say many still do and will continue to do so).

    I would love to know your thoughts on this, for me my search continues…

  • Yes – this is my first post, so if you don’t know, every software developer always starts with a Hello World program when they first learn a programming language, so I thought I would make my first post a Hello World post.

    Currently my technology stack consists of developing applications using the Microsoft Stack and at the moment I am deep into producing PowerApps applications (mostly Model Driven Apps). So don’t be surprised if you see a lot of posts dedicated to the PowerApps platform. I have also been doing C# for the last 20 years so when I have to delve into that area from time to time – I will share those experiences.