llms are fast and competent. instead of taking days, weeks or even months, prototypes, proof of concepts, side projects we didn’t have time to build are generated within minutes and it works.
speed of execution is mostly solved, but at a cost: understanding. its fine for throwaway projects, but what about projects which requires maintenance / continuity?
it is tempting go fast and adopt the mindset of “it just works why bother understanding” or “if anything breaks, we can ask the llm to fix it”.
but what happens when something breaks in production at 3am or a critical bug occurs and we cannot answer because “ai did it for me”? the lack of understanding prevents us from figuring out the problem, a way to debug it or even ask the llm to do it for us.
this creates a clash between engineers who goes for speed, while others who pride themselves in writing code manually, building services from scratch, setting up boilerplates, figuring out the language syntax and so on. this is their identity. so with ai here, they’re reluctant to adapt because it’s robbing them of their “skillset”.
“when did we define an engineer as someone who pride themselves in how fast they can type? or how much is being handwritten?”. we had to write code manually because we had to, there’s no other way.
i have always viewed code as a medium to bring what a stakeholder wants to life. i.e. creating websites, servers or a saas platform that can serve millions of users. the value of an engineer lies in their ability to communicate with stakeholders, figure out what they want (intention), aligning both parties on the desired outcome and coming up with an appropriate solution.
thus, balance is key and we must see each process for what it is.
llm quick outputs comes at a lack of understanding cost (its akin to copy pasting code from stackoverflow, it works but we don’t understand why). However, in light of an llm, while we have a complete picture of everything and understand what we painstakingly typed character by character. it is way too slow.
llms are great for amplifying, being a thinking partner and doing away the mundane code. when we think, ugh i have something similar written out in the codebase, instead of typing it out, an llm can replicate it quickly. or when we have certain ideas of how an architecture should be, we ask the llm to poke some holes and provide different angles to it and so on.
the middle ground is for us to understand what we want and use the llm as a tool to bridge the execution. this way we are clear and do not get confused or lead on by what it suggests.
this is where writing code by hand comes to play. while slow, it forces to deliberate and think: “why is this written in this manner”, “there’s got to be a better way to do this”. this friction, allows me to form a mental map on what i’m about to implement and learn the inner workings of a certain api, language or concepts.
by being disciplined and managing the temptation to let it rip has helped me get the best of both worlds. producing richer outcomes while learning along the way. the llm is a great partner to bounce ideas, explore different angles to a solution and visualise the abstract idea in our heads and make it concrete.
links i find relavent