51–60 of 109 posts
Most likely you are creating boilerplate at 20x/50x, as opposed to genuinely new concepts, mechanisms, etc. To be fair, most web/mobile frameworks expect you to do that. Ideally, codebases would grow by adding data (e.g. a json describing endpoints, UIs, etc), not repetitive code.
So, it would take roughly two months to complete a project at the scale of SQLite or TeX.
Most likely you are creating boilerplate at 20x/50x, as opposed to genuinely new concepts, mechanisms, etc. To be fair, most web/mobile frameworks expect you to do that. Ideally, codebases would grow by adding data (e.g. a json describing endpoints, UIs, etc), not repetitive code.
> Ideally, codebases would grow by adding data (e.g. a json describing endpoints, UIs, etc), not repetitive code. The problem with this configuration based approach is that now the actual code that executes has to be able to change its functionality arbitrarily in response to new configuration, and the code (and configuration format) needs to be extremely abstracted and incomprehensible. In the real world, someone fi…
I try to think of what this would look like at my company and I can't even really conceive of what this dream scenario is supposed to be. We have maybe 6-10 legitimately revenue-earning products with a meaningful user base and it took about a decade to get there. There is no reasonable world in which you say we could have done that in 10 weeks instead, which would be roughly 1/50th the time. It takes at least that long typically just to get a contract completed once a prospective customer decides they even want to make a purchase. Writing code faster won't speed that process up. Can we push features 50x faster? No, we can't, because they come as a response to feature requests from users, which means we need to wait to have users who make such requests, and you can't just compress 10 years of that happening into 10 weeks. That's to say nothing of the fact that what we work on now is a response to market and ecosystem conditions now, not conditions as they were 10 years ago. If we'd pushed what we were doing now to having done it then instead, we'd have just been working on the wrong things.
Think about what it would mean to produce cars 50x faster than using current processes. What good would that even do? The current processes already produce all the cars the world needs. Making them 50x faster wouldn't give you a larger customer base. You'd just be making things no one needs and then throwing them away. The only sensible version of this is doing the same thing at roughly the same speed but at 1/50th the cost. I don't doubt that faster code generation can cut cost but not to 1/50th. Too much of the cost in creating and running a company has nothing at all to do with output.
Show us the financial statements from your company you started in 2019 and your company today. I would be absolutely thrilled to see somebody concretely show they earn the same revenue for 1/50the the cost, or 50x revenue for the same cost. The fact that you push 50x the number of commits or lines of code to Github means nothing to me.
That said... I jumped to a few random moments in your video and had an "oh my god" reaction because you really were not kidding when you said that you were pasting code.
I'm pretty much begging you to install and use Cursor. Whatever boost you're getting from your current workflow, you will see triple through use of their Agent/Plan/Debug modes, especially when using Opus 4.5. I promise you: it's a before electricity vs after electricity scenario. I'm actually excited for you.
A lot of folks will tell you to use Claude Code. I personally find that it doesn't make sense for the sorts of projects I work on; I would 100% start with Cursor either way.
I curious how you paste diffs into the Ai. And wouldnt a coding assistant in the IDE be a much more convenient solution?
Earlier quoted context omitted.
> Ideally, codebases would grow by adding data (e.g. a json describing endpoints, UIs, etc), not repetitive code. The problem with this configuration based approach is that now the actual code that executes has to be able to change its functionality arbitrarily in response to new configuration, and the code (and configuration format) needs to be extremely abstracted and incomprehensible. In the real world, someone fi…
Working on a system like this (mostly configured with complex yaml, but extended with a little DSL/rule engine to handle more complex situations) a long while ago, I introduced a bug that cost the company quite a bit of money by using `True` instead of `true`—something that would have been readily caught in a proper language with real tooling.
We badly need to set some sort of standards on what constitutes a product for the purposes of "productivity." It's well-defined economically, revenue earned by a firm per labor hour. Are you earning 50x the revenue per hour of work or have you just pushed 50x lines of code into a repo with an automated build pipeline? Do you have 50x the users? Any users at all? I try to think of what this would look like at my compa…
Most likely you are creating boilerplate at 20x/50x, as opposed to genuinely new concepts, mechanisms, etc. To be fair, most web/mobile frameworks expect you to do that. Ideally, codebases would grow by adding data (e.g. a json describing endpoints, UIs, etc), not repetitive code.
> Ideally, codebases would grow by adding data (e.g. a json describing endpoints, UIs, etc), not repetitive code. The problem with this configuration based approach is that now the actual code that executes has to be able to change its functionality arbitrarily in response to new configuration, and the code (and configuration format) needs to be extremely abstracted and incomprehensible. In the real world, someone fi…
Both worlds can be cleanly composed. For instance, for backend development, it's common to define an array (data) of middleware (code).
At a smaller scale, this is already a reality in the Clojure ecosystem - most sql is data (honeysql library), and most html is data (Hiccup library).