Throughout history, the technology industry has thrived because it solves problems. That's the exchange. You build something that provides value, and that value is what makes the industry lucrative. And because of how much value technology provides people, it's been very, very lucrative. And I'm not just talking about apps or websites. I mean every layer of the stack. From the hardware, to the protocols, to the frameworks, to the interfaces people actually touch.
There's a bad part to every single job. Sometimes that bad part could be the good part. It depends on how you look at it and what you're trying to get out of the job. A lot of people look at a profession and enjoy the craft of it. Some people look at the profession and see how it can change their bottom line, make them money. Both are fine. Both feed something that someone wants.
When it comes down to it, the technology industry's entire purpose is to progress the stack. We raise the bar that each layer reaches and replace the layers that can be done more efficiently. We look at the long-term use cases and adapt the technology around them to holistically save us time and effort. And anyone who stagnates in one layer of the stack will eventually work themselves out of a job. A lot of people hear that and think it means they no longer have a place in the industry. It really comes down to the type of contributor you are.
If you understand that your entire purpose is to work yourself out of a job, then you're naturally going to move on to the next thing you need to work yourself out of a job for. Engineering isn't so much a profession as it is a mindset. You think about problems and you solve them. You figure out the nuances you need to cater to, what to change, automate, and architect, in order to solve those problems the way they need to be solved, for the people that need them solved.
The Browser Deprecated the Desktop Application
Back when we had to develop using C++ or Visual Basic to create desktop applications, there were people who really enjoyed that craft specifically. Then the dot-com boom happened, and you had HTML and CSS come out. Really quickly, people realized this could be a huge productivity boom for organizations and individuals. Why would you make a desktop application that you have to install, maintain, and distribute when you could have one source of distribution that happens every time the user needs it, when they go online? And that tool can run on their desktop because it runs through a desktop application: the browser.
Really think about it. The browser is what deprecated the act of developing desktop applications. We started only building them for specific performance or native needs, where the browser just couldn't fulfill. Yet. The browser's job was to consistently iterate on working the desktop application out of a job.
As the browser matured, we were able to make games in it. We no longer needed to create a desktop application for many games. Then Slack came along and essentially worked email out of a huge portion of its jobs. Email's function, to send and receive messages throughout an organization, had a large portion of its use-case market share consumed by Slack as that layer of the stack progressed. That was no longer a use case for email, for the most part. Can you still do it? Could you still enjoy emailing someone? Yeah, you can. You can still do it.
The Craft Never Goes Away
Some may think that by reading this blog post, I don't actually understand the craft that is coding. You're wrong. I've been developing things since I was five years old. This was a hobby far before it was a profession for me. I got started getting paid to do this in 2010. I got my first real actual tech job in the industry in 2016. I was building things since I was five.
And I loved the craft of the code. To be able to make those small decisions that added up to such a satisfying fluid process of events. It gave me a sense of importance, a sense of control.
Though, again, this is the nature of the stack. Everyone working at each layer is trying to work itself out of a job.
The craft won't go away.
Think about game development. Developers used to have to modify in-game memory in order to make games work appropriately. It was a set of hacks that got certain games on PlayStation or Super Nintendo to be the amazing experiences that they are. Later, when we could have far more RAM in a game system, the person who had to figure all of that out didn't need to anymore, because we had enough space to do what we needed to do. Albeit still finite. Maybe there are newer tricks, which there are. There are new programming languages that help with certain areas of garbage collection and efficiency gains based on the type of applications that are going to be written. That craft is never going to go away. There is always going to be room for jumping down to the atomic level and really figuring things out so that later you can, again, work yourself out of a job. Solve that problem. Make it no longer a problem.
And yes, it is very therapeutic to be able to make those low-level decisions. There's a certain level of satisfaction that you get from that control.
Detaching from the Code
When I first started working with AI to write code, I struggled. I was trying to figure out how to get it to write code the way I write code, to have it make decisions and write code with me, versus it just taking the steering wheel while I put in the directions. I was confused. Conflicted. I enjoyed writing code.
It took me a bit to completely detach myself from the code. To be able to ship features faster than I've ever shipped anything. That took me a moment. Because I had to understand that it wasn't about choosing the different logic. It was about: how can I make the AI understand what is good code and what is bad code? How do I instill my skill and bar of quality into it? How do I make it an extension of my hands, not my mind?
Once I was able to do that, a lot changed. I could develop something, look at the code, and recognize a lot of the patterns, because there are patterns I would generally use for certain reasons, and it was using them for those same reasons. So I was able to review the code that much faster. And as I kept reviewing, I realized I wasn't disapproving of any of it. The only time I'd make a change was when the product didn't work exactly the way I wanted. And that was usually because I didn't explain it right, or I realized that what I explained wasn't actually what I wanted. I didn't like the outcome, and I understood that I needed to change course. I needed to pivot.
Those types of decisions used to take a very long time to surface through the development process. Now they can happen in minutes. I can make a choice between five different websites in the styles I like and want to try out, in the course of ten minutes or less.
Theo featured this on one of his latest streams (the video may not be posted yet). He had a great prompt for it:
1Once initialized, I want you to create FIVE different designs. Each design should be creative and unique from all the others that you create. They should be hosted on /1, /2, /3, /4 and /5 respectively.Why are you iterating one by one when you can iterate five by five? Ten by ten? It's a different way of thinking.
Primeagen has a tool in Neovim called 99 (video) that allows you to add comments to your code and the AI will fill in the code for you. So he can explain exactly what to write for that function, and it can do the bulk of the writing. So he's prompting, but he's not vibe coding, as people call it. He's not developing whole features or applications from prompts alone.
The Method Only Matters to the Master
The method only matters to the master. The outcome is what matters to the consumer. How you achieve that outcome? That's the craft.
Think about it. The quality you'd output when you were coding completely by hand had varying levels that you would iterate on and improve. Some people, maybe your colleagues, peers, people you've seen online, different companies, iterated slower, and you kind of looked at it like their craft wasn't as good as yours because you were able to create something more efficiently, at a much higher bar of quality. The same counts for now.
It's the difference between what you enjoy and how quickly you can give an outcome to the consumer. It's different if someone can beat you to it and it's lower quality versus if someone can beat you to it and it's higher quality. You'd want to learn from that second person. Wouldn't you? They produced the quality you enjoy and got there first.
A team I think of when it comes to balancing craft and quality is the Anomaly team, the ones working on OpenCode. I feel that they understand both sides of it and want to find a balance. They're crafting software that they and their consumers love, and enjoying the process as they build and work together. It's beautiful. I would absolutely love to hang out with and learn from anyone on that team. Maybe our paths will cross that way one day.
Quality Is the Competition
You're always going to have people who generate slop. Bad code, bad applications, things with bugs, things that don't work well, things that don't look good, things that aren't satisfying. It's always going to happen. There was a huge uptick of it after the dot-com boom when the browser became far more prevalent and websites became a thing. You saw all these tools pop up that everyone had gripes about. They hated how Microsoft Word worked. They hated Outlook. It was boring. It sucked. It didn't have good features. And then they saw new applications come out, things like Slack, much later, that actually solved those frustrations. Though, even those will be worked out of their job eventually. It's all technology.
There's always going to be the competition of quality. Brand trust. That's what becomes more important because it's about the outcome the customer needs and can trust at the end of the day. Remember, there are customers at every single level of the stack. Now even AI can also be a customer.
Your Craft, Your Choice
What I'm really saying is this: however you want to craft your setup, that is your choice to make. Those are the decisions you get to make. There are even more ways to develop applications now, and we're headed toward a world where AI can produce pretty high quality at very low input. Though, the choices you make upon what to produce will still be your choices to make.
The building blocks AI needs from us will constantly change in shape and scope. The ways of doing things are going to constantly change. And for AI to keep up, we have to keep producing the building blocks it can use. The capabilities it can grab a hold of and pull the strings for its consumer. How we develop those things is up to us. The level of quality that we want to satisfy. That bar is up to us.
The consumer is always going to have a choice in what they want to do. And if we want to be on that list of choices, we still have to maintain a certain level of quality. Whether that's via how you run your craft, or it's vibe coding, because that is your craft, either one can win if you can produce the best for the consumer. And if the consumer is you, then it's completely up to you.
Focus on outcomes, and I think you'll find yourself possibly more satisfied. Not just the outcome for the user, but the outcome for you as well. Where can you find what makes you happy while producing work that makes your consumer happy? That could be a craft in itself.
There are machines that can make blankets now. And people still crochet. People still knit. There is still satisfaction to be had about the journey.
Been fun for me. I appreciate you reading this. I hope I've provoked some thought into how you think about coding with AI. Leave a comment below with any questions or thoughts. Thanks.