星期六 03 下午 四月 19o 2025
What to study in the age of vibe coding?
The question I keep getting is what’s the best thing to study right now, what knowledge has the longest shelf life in the world of vibe coding.
I’ve been thinking about this a lot.
I want to spend my life creating and building.
But at the same time, I don’t want to become one of these old forgotten craftsmen, an incredible woodworker whose work no one needs anymore.
But how do I do that?
First, I don’t think focusing on specific technologies, languages or frameworks is worth it anymore.
A few years ago I made new year’s resolutions like “this year I will finally learn Rust” or “I’ll build something with Svelte” so I can get a feel for a new technology.
But if non-technical people can build half-baked web apps with Cursor, then with the fundamental programming knowledge I’ve acquired, I’m sure I can build anything.
And here we come to the important part - the fundamental knowledge.
That’s the thing.
The complaint I keep hearing from people doing too much vibe coding is that they reach a state where they can’t continue adding new functionality anymore.
Their projects become a mess.
But why?
You still need good engineering principles
You need to split complex logic into small parts you can reason about, you need to model the solution.
Imagine you’re building a pipeline that’s reading files, processing them and outputting the results.
If you give this problem to cursor, it will blast out a specific solution to your problem that will most likely work with some minor tweaks.
But whether you get one large function, a few smaller ones, a class to handle it - you have no control over that, you’re just relying on the temperature of the model and how creative of a result it gives you.
You’ll get a specific solution with no greater idea behind it.
You can do something different, though.
You can model the solution in your head, you can figure out you need importers (functions that read different sources), you need processors (functions that take an object and manipulate it) and exporters (that can export the data in various formats).
Think of the APIs of the functions, create a shared object model that they’ll all be working with to represent the files and their data.
You can give this information to Cursor and you will get an extensible application that you can continue adapting and working on.
So what’s the difference between the two implementations?
The act of modeling a solution, picking which design patterns to use (and which not to use), deciding how you organize a codebase, how to handle errors, what APIs your functions need.
That’s a skill we’ve largely neglected because we’ve been too busy writing code in the last decade.
And that’s the very long explanation of what I think you should study - software design, managing complexity, and domain modeling.
Build a taste for what good code and good software look like.
You’re no longer a typist but a creator.
Not a writer but an editor.
Copyright © 2025 Code Philosophy, All rights reserved.
You are receiving this email because you opted in via our website.
Our mailing address is:
Code Philosophy
7000 Ruse
Ruse 7000
Bulgaria
Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.
͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏
The question I keep getting is what’s the best thing to study right now, what knowledge has the longest shelf life in the world of vibe coding.
I’ve been thinking about this a lot.
I want to spend my life creating and building.
But at the same time, I don’t want to become one of these old forgotten craftsmen, an incredible woodworker whose work no one needs anymore.
But how do I do that?
First, I don’t think focusing on specific technologies, languages or frameworks is worth it anymore.
A few years ago I made new year’s resolutions like “this year I will finally learn Rust” or “I’ll build something with Svelte” so I can get a feel for a new technology.
But if non-technical people can build half-baked web apps with Cursor, then with the fundamental programming knowledge I’ve acquired, I’m sure I can build anything.
And here we come to the important part - the fundamental knowledge.
That’s the thing.
The complaint I keep hearing from people doing too much vibe coding is that they reach a state where they can’t continue adding new functionality anymore.
Their projects become a mess.
But why?
You still need good engineering principles
You need to split complex logic into small parts you can reason about, you need to model the solution.
Imagine you’re building a pipeline that’s reading files, processing them and outputting the results.
If you give this problem to cursor, it will blast out a specific solution to your problem that will most likely work with some minor tweaks.
But whether you get one large function, a few smaller ones, a class to handle it - you have no control over that, you’re just relying on the temperature of the model and how creative of a result it gives you.
You’ll get a specific solution with no greater idea behind it.
You can do something different, though.
You can model the solution in your head, you can figure out you need importers (functions that read different sources), you need processors (functions that take an object and manipulate it) and exporters (that can export the data in various formats).
Think of the APIs of the functions, create a shared object model that they’ll all be working with to represent the files and their data.
You can give this information to Cursor and you will get an extensible application that you can continue adapting and working on.
So what’s the difference between the two implementations?
The act of modeling a solution, picking which design patterns to use (and which not to use), deciding how you organize a codebase, how to handle errors, what APIs your functions need.
That’s a skill we’ve largely neglected because we’ve been too busy writing code in the last decade.
And that’s the very long explanation of what I think you should study - software design, managing complexity, and domain modeling.
Build a taste for what good code and good software look like.
You’re no longer a typist but a creator.
Not a writer but an editor.
Copyright © 2025 Code Philosophy, All rights reserved.
You are receiving this email because you opted in via our website.
Our mailing address is:
Code Philosophy
7000 Ruse
Ruse 7000
Bulgaria
Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.
͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏
发布者