Take a good look at the codebase you're working on. My guess is there's plenty opportunities to clean up after others, or even yourself.
1,766 karma · joined November 14, 2010
http://web.archive.org/web/20130729210111id_/http://itc.conv...
http://web.archive.org/web/20130729231533id_/http://itc.conv...
https://tribalneed.bandcamp.com/album/genetic-modification-o...
A more recent live performance:
"When someone offers you a seat on the rocketship, you do not ask which seat. You just get on. [...] Find a way to say yes."
In my understanding, that's the billionaire class telling you where your place is in their plan for the world. Nobody asks if you even want to leave the planet, figuratively speaking.
The last sentence in particular shows the contempt he has for the students in the audience, and is reminiscent of another (alleged) incident: https://www.msn.com/en-in/news/world/tried-to-convince-me-i-...
The quoted part of the speech can be watched here: https://www.youtube.com/watch?v=5MYggR_PPRg
In his commencement speech that got booed by the audience, Eric Schmidt says, "When someone offers you a seat on the rocketship, you do not ask which seat. You just get on. [...] Find a way to say yes."
That's the billionaire class telling you where your place is in their plan for the world. Nobody asks if you even want to leave the planet, figuratively speaking.
The last sentence in particular shows the contempt he has for the students in the audience, and is reminiscent of another (alleged) incident:
https://www.msn.com/en-in/news/world/tried-to-convince-me-i-...
The part of the speech I quoted is not in the video linked in the article, but you can watch it here:
- Split up the work so that you write the high-level client code, and have AI write the library/framework code.
- Write some parts of your (client) code first.
- Write a first iteration of the library/framework so that your code runs, along with tests and documentation. This gives the AI information on the desired implementation style.
- Spend time designing/defining the interface (API, DSL or some other module boundary). Discuss the design with the AI and iterate until it feels good.
- For each design increment, let AI implement, test and document its part, then adapt your client code. Or, change your code first and have AI change its interface/implementation to make it work.
- Between iterations, study at least the generated tests, and discuss the implementation.
- Keep iterations small and commit completed features before you advance to the next change.
- Keep a TODO list and don't be afraid to dismiss an earlier design if it is no longer consistent with newer decisions. (This is a variation of the one-off program, but as a design tool.)
That way, there is a clear separation of the client code and the libraries/framework layer, and you own the former and the interface to the latter, just not the low-level implementation (which is true for all 3rd party code, or all code you did not write).
Of course this will not work for you if what you prefer is writing low-level code. But in a business context, where you have the detailed domain knowledge and communicate with the product department, it is a sensible division of labour. (And you keep designing the interface to the low-level code.)
At least for me this workflow works, as I like spending time on getting the design and the boundaries right, as it results in readable and intentional (sometimes even beautiful) client code. It also keeps the creative element in the process and does not reduce the engineer to a mere manager of AI coding agents.
I am having long design sessions with Claude Code and let it implement the resulting features and changes in version controlled increments.
But I am the one who writes the example games and simulations in the DSL to get a feel for where its design needs to change to improve the user experience. This way I can work on the fun and creative parts and let Claude do the footwork.
I let Claude simultaneously write code, tests and documentation for each increment, and I read it and suggest changes or ask for clarification. I find it a lot easier to dismiss an earlier design for a better idea than when I would have implemented every detail of the system myself, and I think so far the resulting product has largely benefited from this.
To me, now more than ever it is important to keep the love for programming alive by having a side project as a creative outlet, with no time pressure and my own acceptance criteria (like beautiful code or clever solutions) that would not be acceptable in a commercial environment.
It used to be one time purchase, looks like they turned it into a subscription.
What exactly is your point?
It may look like that, but many of the products with bad code didn't even make it into your vibe statistics because they weren't around for long enough.
>We also have someone who vibecoded without reading any of the code. This is self admitted by this person.
And we have a company whose product should adhere to the highest security standards possible, hiring this guy.