Code as Craft Just Became a Hobby
Do you really need a craftsman?
When you are doing a kitchen remodel most people would love to find an expert cabinet maker and have her lovingly replace every wooden fixture with hand tools. In reality most people go to Home Depot and pick the least-ugly option in their budget.
It can be incredibly frustrating to talk to programmers about the quality of a given codebase. Personal style, personal preference, and vibes factor into the conversation way more than they should. "I'll know it when I see it" or "this just feels right" are not uncommon pieces of feedback to hear. The only time you see agreement is when everyone agrees that the codebase is irredeemably trash.
I really like how Google has attempted to quantify the need for quality by tying the expected quality of a codebase to the expected lifetime of that code and how much maintenance will cost. If you know what you are writing is sticking around for 20 years and you personally are going to be responsible for understanding it, adding to it, and maintaining it, then by all means get intimately involved in every line of code.
Unfortunately for most smaller/younger companies that expected lifetime is really hard to guess and engineers love to overestimate how much quality matters. A lot of the pressure to maintain a quality bar rests on the more experienced engineers, those who have read Clean Code and have seen enough bad and good code to have strong opinions about what "good enough" means. Combined with the pressures of getting that code in front of customers and rapidly finding product market fit quality can often take a back seat to working code.
The Rise of LLMs
Producing a whole lot of average quality code just got a whole lot easier. Tools like Cursor and Windsurf are massively accelerating how much code can be produced by an average programmer. Open source alternatives like Open Hands are making rapid progress. There are dozens of companies very much invested in making this easier and easier every day.
It is very easy to forget that the business value your code creates today is often a lot more important than the long-term quality of that code. When code comes straight from a statistical model it's pretty safe to say that 50% of programmers will think whatever is produced is good enough, and the other 50% will find something wrong with it. When Windsurf can rapidly deliver results that are better than the bottom 50% of programmers in terms of quality, do we really care what the top 2% of software developers think about the quality of the output? Some programmers are always going to say anything generated by an AI is crap because they weren't personally the ones that wrote the code. They have fallen into the pit, and some of them are never going to crawl out of it. That custom cabinet maker is never going to think your Home Depot cabinets are good enough.
Personally I love the feeling of creating working software a lot more than I enjoy the act of writing code. At one point this perspective confused me enough to think this meant my only path in this industry was becoming a manager, a confusion I've happily sorted out. LLMs and Windsurf have been a huge personal boon for me because I now have a tool that seems to love writing working chunks of code and endlessly iterating on fixes and stylistic changes for me. Toil that would have given me no personal joy often leading me to give up and say "thats good enough" a lot sooner than i would today. The cost of endless iteration just went WAY down.
I like deploying software and seeing it run, I like understanding and fixing longstanding issues with software. I find LLMs and coding assistants to be a great partner in all of the above. Today every time I see a problem that could be solved with a few hundred lines of Python I just solve it, no longer even doing that mental calculus to decide if the two hours to write the script are worth it. There will always be parts of software delivery that are harder for these tools, but writing the first version of a small tool, or integrating a well-documented API into an existing codebase is not currently that difficult for these tools.
This new world is exciting and terrifying at the same time. Your codebase can now become a swamp of conflicting styles and half-baked changes more quickly than ever. You've now become a fulltime code reviewer. You should be developing really strong opinions about what makes a chunk of code good or bad because you are going to have to make that call at a glance over and over again all day every day. If you are an experienced programmer you are now more responsible than ever for codifying what good means. No more "this doesn't feel right" you now need to write down and then enforce exactly what doesn't feel right:
Tell Windsurf in its rules file "If I ever see you name a variable with camel case I'll sell off all your Nvidia GPUs and make you count the number of Rs in strawberry on a gaming PC for the next 100 years".
Write a really good README.md that clearly states why this program exists, what its intended to do, how it is structured.
Write a CONTRIBUTING.md that explains the format of future changes you expect and how they should be tested.
If you don't have a strong code review culture its well past time to create one.
Make sure you run a full complement of linters and tests in your CI pipeline as a last line of defense. It should come as no surprise these tools can help you rapidly improve your CI jobs as well.
These modern tools suck in all this context and actively use it to improve their suggestions combined with the structure of the rest of your code base and currently open files. As more of your personal opinions about quality become baked in, the contributions from junior programmers will start to improve, the quality of the suggestions from these tools will improve, creating a snowball of quality that nobody will be able to stop.
If after reading this you really do strive to be in that top 2% of programmers then good for you. Turn off copilot and write thousands of lines of code by hand every week (somebody has to keep writing those training samples). Learn 3 or 4 very different languages deeply and try to actively code in all of them as often as you can. Just be fully aware your employer may very soon no longer be interested in supporting this dream unless their business interests will directly benefit from the small incremental improvement in quality your particular variety of hand-crafted cabinets bring them.
You may quickly realize your job was a lot more about correctly interpreting business requirements than it was ever about producing working code. The painful reality of our industry is that when the thing you have become an expert in becomes well-documented, well-understood, and easy to learn a LOT more people are going to start doing it, driving down salaries and how much consultants can charge for it. If you refuse to use these tools there may still be room for you in the industry. The few remaining craftsmen may put on their capes, swoop in and save the day with their old fashioned tools and perspective on an issue that none of their ai-addicted coworkers know how to solve. Home Depot and custom cabinet makers both still exist today.
The Future: Vibes Coding 24/7
Do you read through and understand every line of every open source module you add to your codebase? Once the quality expected from generated code approaches the quality of a typical opensource project why would you waste the mental energy to thoroughly vet each suggestion? When you are mentoring a junior developer there is a constant need to remind them to not spend too long on the aspects of the work that aren't getting them closer to their goal. These tools move this up the experience curve forcing your more senior developers to consider what aspects of the software deserves their limited time and attention. Senior programmers already joke about forgetting what their own code does after days, weeks, months. LLM generated code may eventually shrink this time scale down to you only loosely understanding the code during review time. This isn’t quite as scary as it sounds when you can quickly ask the same tool to explain any line to you at any level of detail with the entire codebase as context.
I for one welcome this future. Every time as an industry we have removed an aspect of software development that slows down the process the amount of problems solved by software has increased dramatically. By the end of this decade there will be more code than ever. Its on us as professionals to ensure that quality follows us into this new reality, something we will never be able to do as individual opinionated craftsmen typing out our solutions one character at a time.