Can't believe I spent 2 weeks writing this.
Last week, I gave a talk at a Cursor community event about AI and how it's changing the way we build software. The event went great, and after the talk, quite a few people came up to me for 1:1 conversations.
One particular guy caught my attention. He wasn't a technical person, but he asked me something interesting:
"With so many tools and technologies available today, how do you even navigate all of this and pick the right ones?"
He thought it must be overwhelming. Then he smiled and said that with so many options available, he hopes many great things be built.
I thought about it for a second and smiled too, and before I could answer, he had to leave... but his question stuck with mi.
A few days later, sitting in a library looking for something to read, I ran into an answer: UNIX Network Programming by W. Richard Stevens. (Great book btw, give it a read!)
90s tech, limited memory, limited processing power, limited bandwidth and limited tooling... etc.
Yet somehow, we got things like UNIX, TCP/IP, early operating systems, incredible mathematical breakthroughs, massive engineering projects, and some of the most elegant pieces of technology ever built.
It made me wonder:
What if the things that limited us were also the things that forced us to become better?
What if greatness isn't always created by having more, but by being forced to do more with less?
The guy assumed more tools meant a better shot at greatness, but the book in my hands was proof of the opposite.
The Paradox of Limitation
I believe there's a reason having less can sometimes make us better.
We usually think of limitations as something to overcome: less money, less time, fewer resources, less knowledge. All of it standing between us and what we want to achieve.
But there's another side to limitation we don't talk about enough.
A limitation doesn't just take something away. It also takes away what could have been.
And maybe that's exactly what we need. Because when everything is available, when every direction is possible, every tool is at hand, every approach is open to us, it sounds like freedom.
But freedom without boundaries can be surprisingly hard to live inside.
You give someone unlimited resources and they can spend a lifetime deciding what to do with them. Give them nothing and the question suddenly gets simple:
How much can I achieve with what I have?
That question changes how you think. You stop searching for the perfect tool, because it doesn't exist, and start building with what's in front of you. You notice details that would otherwise stay invisible, not because you're more observant by nature, but because you no longer have the luxury of not noticing.
Maybe that's the real gift of limitation. Narrowing down your options but also sharpening your attention.
Perhaps that's the paradox: the fewer doors we have, the more clearly we see the one we're standing in front of.
And btw, this isn't a new idea.
Constraints Force Creativity
The book
Let's take a look at Stevens' book for a moment. The book is essentially a walkthrough of the sockets API: socket(), bind(), listen(), accept(), connect(), read(), write(), and close().
That's the whole vocabulary for making two machines on opposite sides of the planet talk to each other reliably.
But Stevens didn't invent those calls. The Berkeley sockets came out of UC Berkeley's CSRG in 4.2BSD, around 1983. Stevens wrote the book that taught a generation of programmers how they actually worked.
He wasn't designing for a world of infinite compute. He was documenting an API built in an era of expensive memory, slow CPUs, and unreliable, low-bandwidth links and there was no room for mistakes, sprawling do-everything interfaces, or generic, accept-all contracts.
Every function had to earn its place.
And with those constraints forced upon the people who designed it, the result is an API so minimal and well-composed that, four decades later, in a world where none of those original constraints exist anymore, it's still the interface nearly every programming language wraps for networking.
Take Python's socket module, Node's net module, or Go's net package, they all trace their shape back to those same eight or so primitives.
The paradox in miniature: by not having the luxury of building something bloated, they had no choice but to build something timeless instead. BSD built it under scarcity. Stevens documented why it was that tight.
And of course, this is also what surprised mi when I decided to pick up a book from the 90s. I expected it to feel dated but instead, I ended up learning a great deal from it, much of which I can still apply to the software I'm building today.
C
The language that started it all, laying the foundation for everything we have today.
C is a good example here, a language so elegant yet it gives you remarkably little. no GC, no elaborate standard abstractions, no safety net between you and memory. want something? you often have to understand what's happening underneath.
By today's standards, we'd call it unsafe or labeling it a weakness but that limitation also forces a certain kind of thinking, you have to pay more attention to details, you become more conscious of memory, data layout, ownership and what the machine's actually doing.
The language doesn't give you many options or answers but it makes you ask better questions and make better, timeless decisions.
Go
Let's come back to the future, let's look at Go. Go takes a different direction, Its constraints weren't imposed by hardware, they were largely chosen by its designers.
With all the things available by its time, the language was designed with its featured kept deliberately minimal & simple. syntax wise, type system wise, fewer ways to express the same idea.
When a language gives you fewer ways to solve a problem, you spend less time debating which clever abstraction to use and more time solving the problem itself.
Go's restraint is the feature, What it leaves out is just as intentional as what it includes.
Music
I play the piano, so this one isn't theoretical.
Today you can put a DAW, a thousand plugins, and an AI vocal fixer on a laptop and make a record anywhere. In the 70s and 80s, a lot of that work was physical. Cut the wrong stretch of tape and it was gone. Limited tracks, limited studio time, expensive gear. The band had to know the part. Screw up a take and sometimes everyone started over.
When recording time costs real money, you don't spend six hours on a snare. When you have eight tracks, you decide what deserves one. You can hear that in the records: the performances, the imperfections, the decisions.
I'm not arguing we go back to splicing tape. I'm saying the constraint did work that infinite undo doesn't.
The Problem With Having Everything
Abundance can create complacency, endless choices... which creates the temptation to solve every problem by simply throwing more at it.
Let's come back to our topic regarding AI. Like a modern DAW, I believe AI is a wonderful partner in our work. But next to that, it is also removing a great deal of constraints faster than almost anything we've seen before.
Just a few years ago, a requested feature would take around 1-2 months. Trying a different architecture meant actually building it. Rewriting a block of code took time, and if it wasn't mine, I had to understand the context first.
Now I can ask AI to do all of that in seconds. The thing that used to stop you was effort. When that cost drops, it's easy to stop asking whether you should do it at all. You generate five versions instead of picking one. You add another library because the model already knows it. You rewrite working code because the new draft looks cleaner.
The shift isn't "can I build this?" anymore. it's "Should I?"
When you have nothing, the limits are imposed on you. When you have everything, you have to impose some on yourself.
So What Do You Do With That
I never got to answer that guy at the event. If I could now, I wouldn't give him a list of tools.
I'd tell him more options don't guarantee better work and they just make it easier to never decide. The 90s didn't produce UNIX because people had more. They produced it because they had less, and less forced the work to get honest.
That doesn't mean throw AI away, or go back to cutting tape, or write everything in C. It means the environment won't hand you a limit for free anymore. If you want the sharpening, you have to pick one. Ship one use case. Let the model generate the boring parts and keep the core decision yours. Give yourself a deadline ugly enough that you can't keep adding.
Cap the stack this week.
Top comments (42)
Exactly! I once read about a psychology study where people were given different numbers of yogurt brands to choose from. When they had only three options, they chose quickly and were happy with their decision. When they had 50 - which should theoretically be better - they took much longer to choose and ended up less satisfied with their choice 😄 I guess technology isn't that different!
Hahaha, and I see that “mi” has found its place 😂
Haha, sounds like a great study! Having so little can give us so much bliss. Give us more, and somehow, we end up with more sorrow. After publishing this, I’ve started wondering about the overlap with the saying "ignorance is bliss." This idea and my article have a pretty interesting distinction, but enough of that for now—that can come later haha.
anyway, yeah, I told you I was gonna sneak a “mi” in here somewhere 😆
A little bit of a tangent here...
The M.O. of great minds is definitely doing more with less. I constantly remind myself that. Doing more with less exposes how one limited individual or business can supersede more privileged peers. Not just in coding, but life in general... a fact I hold at my core to keep me sane. Overcoming difficulties, that's true power. Difficulties give us an appreciation of when everything is easy.
It is better to work with people that have faced real struggles, whether nasty bugs, or a difficult life situation, these struggles make us intelligent. This kind of intelligence that would be lost if we didn't have these experiences. If life wants to offer all the privileges, who would really say no to extra help? But I accept the reality and struggle just the same, if not more. The pride and learning that comes out the other side of struggle is real and valuable. That is real learning.
I absolutely appreciate this topic.
Not too far off course! I completely agree, and I think many others do too. There’s a particular euphoria that comes from solving a genuinely difficult problem yourself that very few other things can give you.
Even if someone uses AI constantly to help them solve problems, figuring out one of those hard problems themselves can still give them a huge boost of confidence and satisfaction. You know you got through it.
And regarding working with people who have faced real struggles, whether in life or through nasty bugs — I don’t think enough people appreciate what those experiences bring. Those people can teach you how to handle the chaos behind the chaos. They’ve seen problems you haven’t even thought of yet.
You think your tests cover everything? They’ll say, “Nope,” and point you toward the edge case you completely missed. 😂 They can almost contaminate your way of thinking in the best possible way because suddenly, you start seeing the hidden edges everywhere.
Paranoid about something you built? Anxious about what might go wrong? They’ve probably been there before, and they know exactly what to tell you.
And thanks for reading! Really appreciate it!!
I think there is a weird transition in thinking when we move from regular life to coding. All those little "doesnt really matter" things/thinking do not translate well to coding it would seem.
So for example, someone in the kitchen forgot to close a drawer. No big deal (although annoying). Now, if someone accidentally leaves a line of code. That is a monumental problem. You have to be absolutely insane to be a programmer. Thats why I love it here. I love it when I find an edge case. 😂 honestly, its why I dont "ship" anything. I keep it all to myself. Because I am paranoid that I am not pristine. I dont want to become the next exploit. I recently shared my webserver(ai microserver), knowing that if someone tries to steal my personal information, they will be inheriting 6-digit financial debt. Sure bro. Take a load off of me. 😂🤔🦄🤷♀️😶🌫️ im tired of being paranoid. This is exhausting. How do you handle it? 😂
Ohhhh definitely! 😂
But I also think that transition, and maybe even a bit of the paranoia has made me more careful outside of programming too.
Take motorcycle trips, for example. I do a lot of long rides across Cambodia, and before I leave, I treat the preparation almost like a production deployment: check the tires, brakes, lights, fuel, route, weather, and anything else that could turn into a problem later.
There’s a surprising overlap when it comes to thinking about tolerance, resilience, and failure modes.
The difference is that if something goes wrong in production, we can usually roll back, patch it, or restore from a backup. 😂
If my bike decides to break down in the middle of nowhere, there’s no
git revertand no hotfix coming. 😭Or when I see someone put their drink to close to the edge of the table... panic! 😂🤷♀️
Great read! So many of the questions you raise are ones I find myself asking too — and one strikes me as absolutely essential: what can I accomplish with what I already have? That's exactly why I never build anything without first thinking through resource optimization and architecture — squeezing the maximum out of the minimum. Because limitations have a way of creeping back in, one way or another — just look at the current RAM shortage.
This probably comes from my own background — I got into programming in the early 80s on the Thomson TO7 and MO5, France's equivalent to the Sinclair ZX Spectrum or Commodore 64 in terms of raw resources. We optimized out of sheer necessity back then, and I've always hated the sloppy "we have the resources anyway" approach to development.
I'm not advocating for absolute minimalism or some kind of ascetic dogma, but I certainly don't see the point in wasting finite resources either.
Thank you for reading, Pascal!
Haha, I think your background makes this comment hit differently. You actually came from an era where squeezing the maximum out of the minimum wasn’t some philosophy, it was just how you programmed. 😂
And now we’re living in almost the complete opposite world.
That's what made me wonder whether having so many resources at our disposal is making us forget what we can actually do without them.
Ha! You nailed it — and honestly, I think the pendulum is starting to swing back. With the current RAM shortage and the push for edge computing / IoT constraints, a lot of developers are rediscovering that old muscle. The ones who never learned to optimize are hitting a wall right now.
Maybe the real skill isn't optimizing because we have to, but keeping that mindset even when we don't. That's the hard part.
Exactly. I think that's the interesting part, when optimization stops being a necessity and becomes a deliberate mindset.
You don't need to squeeze every last byte out of a machine anymore, but knowing how to do it still changes how you think about software.
And yeah, maybe constraints are starting to sneak back in whether we like it or not, haha
Beautiful, and thoughtful article that has raised many thoughts. This is definitely on the minds of innovators - to create something constrained or not. Both have tremendous success stories. Your examples for the programming languages or sockets etc are very foundational where constraints are driven by a certain mindset. As you go towards more consumer focused products constraints are more pronounced and driven by business mindset. For example Apple is a great example of applying constraints that keep the user in their ecosystem. Now this has worked for Apple well but sometimes it didn’t work. Anyway, you are spot on - constraints can certainly impact “what it could have been” and one may also provide examples of where a thoughtful constraint has “shaped a thinking early on”. It’s just not a one rule for all, some are time tested, some are revenue tested, some are adoption tested
The question will remain on the minds of builders and innovators. AI has enabled us to build various options and do A/B testing which was a lot harder earlier.
Thanks again for this thoughtful article
Thank you! I really like the distinction between engineering constraints and business/product constraints. I think that's an important nuance, constraints aren't inherently good or bad; it really depends on what they're shaping.
And AI makes this even more interesting. If exploring different options becomes almost effortless, what makes us stop exploring and actually commit to one? 😆
Thanks for the thoughtful comment!
Absolutely. Too many options often comes as what makes us hard to decide.. If anything, moderate limitaions are preffered, IMO. And yes. When there are many options, I am easily distracted choosing the options even when I need to focus on what I should make 😂
Exactly 😂 Sometimes the hardest part isn't building the thing, it's deciding which of the hundred ways to build it.
Moderate limitations can actually give you enough room to be creative without drowning you in choices. Too many options and suddenly you're spending more time choosing the tools than making the thing. 😆
Enjoyed this one and the comments are half the fun. Your "Should I?" pivot is the mirror image of something happening on the model side too . RLHF narrows a model's own range without it choosing to, same way abundance narrows human discipline unless you choose it yourself. Same problem, opposite directions.
Haha, yeah, same problem, opposite directions.
We deliberately constrain ourselves to preserve discipline, while models are constrained through training to shape their behavior.
The interesting question is whether both need some kind of constraint to become useful rather than just capable. 😂
This is a strong reminder that ai, programming, webdev, career need an observable contract. The happy path is rarely the expensive part; it is the boundary behavior, stale state, and partial failure path that decide whether the design holds up in production.
We simply don't explore the what's existing enough to know the full extent and potential of it!
Yes. Limits are also a way to make the existing system legible: they force us to ask what is already available, what actually matters, and which capability is missing rather than adding complexity by reflex.
What an icon: "UNIX Network Programming: Networking APIs: Sockets and XTI; Volume 1".
I devoured it!
But not quite, there is one detail, a distinct peculiarity, pun intended: I read just half of the book, and that, in retrospect, was a good decision.
Or is there anyone using XTI today?
Hahaha, this is probably the most literal example of “you don't need everything” I've seen in these comments. 😂
You read half the book, got what you needed, and left XTI behind for history to deal with.
Honestly, that might be the most Unix thing possible.
I also play guitar and used to make music with a DAW, so for me, the music analogy was actually the easiest way to understand what you were saying in this article 😄
Thank you for sharing such a great article! I really enjoyed reading it.
I'm glad you find the music analogy helpful! I also play the guitar by the way but I'm left handed haha so everytime I play, I always have to reverse all of the strings haha
one of the reasons why no one will let me play their guitar lmao
That’s hilarious 🤣
I’m right-handed, so yeah, having to restring the guitar every time just so you can play it sounds like a lot of work haha.
But honestly, I think that’s pretty cool — kind of like Jimi Hendrix! 😄
The strongest point here is that AI has changed the cost of experimentation, but it hasn't changed the cost of making a good architectural decision.
I've seen this in practice: when implementation becomes cheap, teams don't necessarily move faster. They often create more branches, more abstractions, more dependencies, and more prototypes because nothing forces a decision anymore.
The constraint now has to be intentional. A fixed stack, a small interface, a hard latency budget, or simply refusing to add another dependency can create more engineering clarity than another AI-generated implementation.
The interesting skill in the AI era may not be knowing how to use more tools, but knowing when to stop using them.
Exactly. AI makes experimentation cheap, but architectural decisions are still expensive.
And that's where I think intentional constraints become interesting. If AI makes it so easy to try another abstraction, another dependency, another approach... what actually forces us to stop?
Maybe the real skill in the AI era isn't knowing how to use more tools, but knowing when not to.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.