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 s...
For further actions, you may consider blocking this person and/or reporting abuse
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.
On this line i got some motivation that it's not bad that i just didn't choose any library or game engine to make my game but with my own vanilla js game engine to impliment my game.
As a fan of UNIX SYSTEM Feeling kinda proud of struglling after reading this for doing hard things by myself that could be so much easier if i had used any js library or any game engine.
Maybe i'm wrong of not choosing a game engine but while reading this Quote feeling just good of doing it that way.
I don't think you're wrong at all! 😄
If building your own vanilla JS game engine is what made you understand the problem more deeply and taught you things you wouldn't have learned by using an existing engine, then that struggle has real value.
Could you have made the game faster with a library or engine? Probably. But that's not always the point. Sometimes you deliberately take the harder road because you want to know what’s actually underneath it.
And as a fellow UNIX fan, I think you'd appreciate the irony here: sometimes the limitation is the feature. 😂
Glad the article made you feel proud of the way you chose to build it. That's exactly what I hoped someone would take away from it.
Limitation forcing better design lands for agent work too. The build I trusted most was the one where I capped the tools and context an agent could touch, and the constraint produced cleaner design instead of a sprawl of half-used capabilities. Did the Cursor talk get into where a constraint stops sharpening you and starts just blocking you?
No, I didn't get that far into the talk. The audience was a mix of non-technical and technical founders, along with fellow engineers, so I kept the topic broader and more accessible — basically, how AI is changing the way we build software.
I did have some deeper technical conversations with a few people afterward, but interestingly, we never really got into constraints. Everyone was so focused on how many tools are now available and how much the barrier to building software has been lowered.
The idea that constraints might actually make us better, including with agents, only came to me afterward when the guy I mentioned in the post asked me that question.
So honestly, I hadn't even made that connection until he brought it up.
Really enjoyed this. I think the biggest shift with AI is that we’re losing the friction that used to force decisions. When trying another architecture, library, or approach becomes almost free, the hard part becomes knowing when to stop exploring. Maybe the next great engineering skill isn’t doing more with less—it’s deliberately choosing less when you could have everything.
Preach!
ngl the part about limitations actually making the code better hits home. usually i just throw more libraries at the problem lol
I remember when I first started programming, ignorance truly was bliss. 😂 I didn't even know libraries existed, I genuinely thought we were supposed to write everything ourselves. Which, obviously, I failed at, but I didn't walk away empty-handed either lmao.
That first line
was awesome alone.
I was half tempted to delete it. 😂 Glad I kept it in.
Beautiful and it can be extended also in other sections of life how too much can actually hurt you and were limitations are actually a hidden bliss
Maybe I'm just being nostalgic or whatever, but everything was so full of life and joy back when going outside to play was the only thing we did.