Definitely do not tell that friend to head to https://en.m.wikipedia.org/wiki/Z-Library and use one of the URLs listed there to go to that website and find and download a DRM-free backup copy of all the books they have bought and paid for in the past.
I'm going to give you a video to watch. It's not mine, and I don't know much about this particular youtuber, but it really transformed how I think about writing and structuring the prompts I use, which solved problems similar to what you're describing here.
I may be the only one, but I was under the impression this whole time that all EV tax credits were for consumers who buy EVs, not companies who sell them.
They are, but typically what automakers will do is assume the tax credit on your behalf and just give you $7,500 off the price of your car up front. They will then collect $7,500 come tax day.
That's a win-win all around, the consumer saves $7,500 off the list price up front, they have to finance less etc, and Tesla gets a tax credit.
There were vehicle sourcing credits in the Inflation Reduction Act, which are granted per kWh of battery with sufficient domestic mineral content. Was $4,000/vehicle if I recall.
lol! No no, this America!
Automakers are actually buying and selling EV credits to eachother. Tesla often would have been in a loss position and possibly bankrupt if the big 3 auto makers weren’t buying credits from Tesla so they could get their fleet averages down and keep making trucks and SUVs.
Definitely not, no. Credits on profits incentivize short term profit taking, while credits in products incentivize number of units shipped. The second is much better for society. Think about it from the perspective of a company deciding between selling low margin cheap EVs in the short term before process efficiencies kick in, or selling expensive EVs now.
It isn't a tax credit for making profits. It's a tax credit for making EVs. The reason there are credits for both consumers and manufacturers is that the manufacturer credits provide an incentive to build EV factories in the US, even if some of the cars are for export.
But we don't care about more profits, we care about more EVs. If you want to create an incentive to make EVs that are exported then you can make one, for example by subsidizing production equipment or by providing a per-unit sold refundable tax credit.
you're just circling back to the GP's last comment, without refuting that comment.
>Credits on profits incentivize short term profit taking, while credits in products incentivize number of units shipped. The second is much better for society.
They are, by definition, credits on profits made from selling EVs, and not from selling EVs. If Tesla made EVs without making a profit they wouldn't have received a penny.
They're credits against taxes. Since corporate income taxes are on profits, that implies that there would have to be some profits in order for there to be taxes to take the credit against, but that doesn't make them credits on profits. If they had made more profits without making more EVs, they wouldn't have gotten more credits. If they had made more profits but offset the taxes with some other credits then they might not have been able to use these, not because they didn't make enough profits but because they didn't pay enough taxes.
And this works the same for the consumer EV credits; you can't get them unless you were paying that much in taxes.
If your point is that non-refundable credits are stupid, yes. All credits should be refundable. But that doesn't have anything to do with whether they're credits for the manufacturer or the consumer.
Making the consumer credits non-refundable is actually worse, especially for the credits on used EVs. Because then you can't get the credit if you're unemployed or a student or otherwise don't make enough money to be paying the value of the EV credit in taxes, so it becomes a tax credit for the affluent that the poor aren't eligible for.
The idea is to stimulate both supply and demand. Credits for consumer only stimulate demand which may not be enough to compel literally hundreds of billions of dollars worth of CapEx, not to mention opportunity cost.
Consumer credits stimulate demand by increasing the cost consumers are willing to pay for a vehicle, shifting the demand curve, and greatly increasing the profitability in selling cars, provided it is done at scale. It can most definitely compell hundreds of billions of dollars of CapEx, and in many ways it's more effective than a tax break, because it will reduce losses if the venture never ends up being profitable (unlike a tax break which will only be worth it if the venture is eventually profitable, so there is less risk), and if it provides future market share through investments in the low end, especially in international competition, it can end up spurning more CapEx as it makes the more capital-intensive strategy more viable.
Those are different credits. There are (if they didn't expire yet, don't remember) federal tax credits for buyers, but separate system is for manufacturers where if you make cars, you need to make some of them EV, or buy credits from somebody who does (e.g. Tesla).
Aider, with o1 or R1 as the architect and Claude 3.5 as the implementer, is so much better than anything you can accomplish with a single model. It's pretty amazing. Aider is at least one order of magnitude more effective for me than using the chat interface in Cursor. (I still use Cursor for quick edits and tab completions, to be clear).
Aider now has experimental support for using two models to complete each coding task:
- An Architect model is asked to describe how to solve the coding problem.
- An Editor model is given the Architect’s solution and asked to produce specific code editing instructions to apply those changes to existing source files.
Splitting up “code reasoning” and “code editing” in this manner has produced SOTA results on aider’s code editing benchmark. Using o1-preview as the Architect with either DeepSeek or o1-mini as the Editor produced the SOTA score of 85%. Using the Architect/Editor approach also significantly improved the benchmark scores of many models, compared to their previous “solo” baseline scores (striped bars).
Probably gonna show a lot of ignorance here, but isn’t that a big part of the difference between our brains and AI? That instead of one system, we are many systems that are kind of sewn together? I secretly think AGI will just be a bunch of different specialized AIs working together.
Efficient and effective organizations work this way, too: a CEO to plan in broad strokes, employees to implement that vision in specific ways, and managers to make sure their results match expectations.
Then you'll be in "architect" mode, which first prompts o1 to design the solution, then you can accept it and allow sonnet to actually create the diffs.
Most of the time your way works well—I use sonnet alone 90% of the time, but the architect mode is really great at getting it unstuck when it can't seem to implement what I want correctly, or keeps fixing its mistakes by making things worse.
I really want to see how apps created this way scale to large codebases. I’m very skeptical they don’t turn into spaghetti messes.
Coding is basically just about the most precise way to encapsulate a problem as a solution possible. Taking a loose English description and expanding it into piles of code is always going to be pretty leaky no matter how much these models spit out working code.
In my experience you have to pay a lot of attention to every single line these things write because they’ll often change stuff or more often make wrong assumptions that you didn’t articulate. And in my experience they never ask you questions unless you specifically prompt them to (and keep reminding them to), which means they are doing a hell of a lot of design and implementation that unless carefully looked over will ultimately be wrong.
It really reminds me a bit of when Ruby on Rails came out and the blogosphere was full of gushing “I’ve never been more productive in my life” posts. And then you find out they were basically writing a TODO app and their previous development experience was doing enterprise Java for some massive non-tech company. Of course RoR will be a breath of fresh air for those people.
Don’t get me wrong I use cursor as my daily driver but I am starting to find the limits for what these things can do. And the idea of having two of these LLM’s taking some paragraph long feature description and somehow chatting with each other to create a scalable bit of code that fits into a large or growing codebase… well I find that kind of impossible. Sure the code compiles and conforms to whatever best practices are out there but there will be absolutely no constancy across the app—especially at the UX level. These things simply cannot hold that kind of complexity in their head and even if they could part of a developers job is to translate loose English into code. And there is much, much, much, much more to that than simply writing code.
I see what you’re saying and I think that terming this “architect” mode has an implication that it’s more capable than it really is, but ultimately this two model pairing is mostly about combining disparate abilities to separate the “thinking” from the diff generation. It’s very effective in producing better results for a single prompt, but it’s not especially helpful for “architecting” a large scale app.
That said, in the hands of someone who is competent at assembling a large app, I think these tools can be incredibly powerful. I have a business helping companies figure out how/if to leverage AI and have built a bunch of different production LLM-backed applications using LLMs to write the code over the past year, and my impression is that there is very much something there. Taking it step by step, file by file, like you might if you wrote the code yourself, describing your concept of the abstractions, having a few files describing the overall architecture that you can add to the chat as needed—little details make a big difference in the results.
I use Cursor and Composer in agent mode on a daily basis, and this is basically exactly what happened to me.
After about 3 weeks, things were looking great - but lots of spagetti code was put together, and it never told me what I didn't know. The data & state management architecture I had written was simply just not maintainable (tons of prop drilling, etc). Over time, I basically learned common practices/etc and I'm finding that I have to deal with these problems myself. (how it used to be!)
We're getting close - the best thing I've done is create documentation files with lots of descriptions about the architecture/file structure/state management/packages/etc, but it only goes so far.
We're getting closer, but for right now - we're not there and you have to be really careful with looking over all the changes.
The worst thing you can do with aider is let it autocommit to git. As long as you review each set of changes you can stop it going nuts.
I have a codebase maybe 3-500k lines which is in good shape because of this.
I also normally just add the specific files I need to the chat and give it 1-2 sentences for what to do. It normally does the right thing (sonnet obviously).
I have been coming around to the idea that we should ban all* algorithmic content surfacing.
It's taken a while, but the longer we go down this path, the more clear it seems that it is impossible to design a content algorithm that does not have significant negative cultural side effects. This is not to say that content algorithms don't have benefits; they do. It's just that they can't be useful (i.e., designed to optimize for some profitable metric) without causing harm.
I think something like asbestos is a good metaphor: Extremely useful, but the long-term risks outweigh any possible gains.
> It's just that they can't be useful (i.e., designed to optimize for some profitable metric) without causing harm.
That's not the pattern I've seen, as close as you are to it.
I've seen lots of platforms be wildly useful. Digg was good for a while; StumpleUpon, Pinterest, Instagram, TikTok, Twitter, Reddit and even Facebook all had periods at the start where they added real value to people's lives.
At some point they start to "optimize for some profitable metric" - and quickly become heinous.
The problem isn't the algorithm; it's that it gets twisted toward profit. And that's basically a tautology - once you start trying to suck money out of the equation for yourself, that juice has to come from somewhere.
I can envision a platform that isn't based on profit being far more useful than harmful - if it can only ward off the manipulations of the yacht class.
Reddit is still extremely valuable if you curate it heavily. My entire feed is my narrow interests and passions (though I still use old.reddit, which helps. The minute that's gone, I probably am too)
> if it can only ward off the manipulations of the yacht class.
The inevitable enshittification of goods and services once they reach a certain level of maturity (i.e., profitability) basically guarantees that the yachted-classes will be involved.
Given this de-facto inevitability, the original premise (that algorithmic content is eventually a bad thing) makes more sense
Emails, torrents, Mastodon, VLC, Blender, Linux - They're all either solid, or even getting better over time.
Why? Because the capital class were explicitly denied, by design or by principle.
Like with healthcare, transport, post services, housing, and much else, there's simply areas where the public good is too important to give the profit motive too strong a foothold. I believe social media is one of those areas.
