I came across this the other day and it's come close to helping me make the switch to emacs.
I've been de-IDEing myself lately for a variety of reasons. I've been trying to figure out if my future is tmux + neovim or emacs.
I got setup most of the way with vanilla neovim and customizing to my liking pretty easy.
I like the ideas of emacs and there are things that are compelling, but oh man it feels imprenetable, especially with how easy I was able to get up and running with neovim.
FWIW I'm using Yosis for my Ice40 Lattice FPGA purely because their Linux support is bad.
Getting a free hobby license requires emailing them with MAC addresses (which means I have to do that for my desktop, laptop, and again for any future machine I may get). Then getting the tools to actually run on Linux seemed to be impossible that I just gave up.
It's not clear that I have the Yosys and open source options for my Xilinx based fpgas.
> Thinking more deeply about your words, is it that you enjoy figuring out the instructions to use to solve a problem? In other words, figuring out the algorithm and writing the code out to create something? Would you feel if you just tell the LLM what you want to create and it does it, you've lost the enjoyment?
So there's a lot of nuance to the "is it that you enjoy figuring out the instructions to use to solve a problem".
At the surface I don't enjoy typing, I don't enjoy fighting syntax checkers, rust's borrow checker, or manual memory management in my personal C projects, typing out the HDL for nand2tetris problems, etc...
However, there have been studies done decades before this LLM boom about the psychological concept called the Generation Effect. While everyone is different and it's not completely black and white, the studies have found that people learn more by actual practice (the act of doing) than just by reading material. That's 100% the case for me.
I can read blogs and resources till the cows come home and I'll have a very surface understanding of a concept. Then I'll go to write the code to implement it and it rarely works right away because there are demonstrable gaps in my understanding. I'll debug it and iterate on it until it works, and that is what actually solidifies the mental model of what I was trying to learn in my mind. Not only can I say for sure that I remember it better, that seems to form connections in my brain that allows me to apply it in other use cases, or build fascinating technical tangents.
I not only get my high from that initial "Aha!" moment when I really feel like I understand a concept enough to actually apply it in other scenarios, but I also get my high from tangents that spawn off of that concept.
In many cases, I can map a direct line of my personal projects to a set of root projects that spawned them off because of ideas I came up with while actually implementing the projects. Since I tried real hard to optimize a C# game engine for an embedded platform, I realized where limitations were and it solidified my knowledge of how old game consoles worked.
This led me down to the interest of creating a GPU out of embedded device that I can pair with I/O constrained embedded devices. This taught me soooo much about the embedded space, and while I heavily improved my C writing abilities it also made me wish I could write C# on embedded.
Since I had learned C for the embedded project (and I knew MSIL from previous deep dives), I realized I can just translate MSIL into C and that would allow me to run C# anywhere (got C# working on an SNES, the linux kernel, and on an ESP32S3).
By implementing that by hand and coming face to face with many small decisions I had to make, that solidified a bunch of concepts in my head around intermediate representations and why they are a massive benefit. Those aha moments (among others) then led me down the path to implementing a just-in-time compilation engine for NES games and the C64 OS into the .net runtime.
The learnings from that have already spawned some other ideas in my mind, which is why I'm now learning Verilog and FPGA development.
None of these projects solved any useful problem (as in nothing was created that I or anyone else would use). The satisfaction and the high I got from them was having the curiosities of a problem, ideas of a solution, and persevering (partially due to being stubborn) through it and actually accomplishing it. The satisfaction that I actually understand the concepts at a foundational level, which actually ends up breeding excitement for a whole other tangent/problem.
These learnings have indirectly helped me in my day job as well. While I'm not working on anything that sophisticated or cool, all of these actual implementations I've learned have given me direct learnings I have been able to successfully use to create better software in other domains.
So it's not the actual typing I enjoy, but the whole picture of what comes out of the end through that typing. LLMs take most of that away. It lets me ideate on a vague solution and then it goes ahead and implements it for me. Even if I'm specific on the details of the algorithm it uses, it subtly fills in the blanks and the missing pieces that I haven't cemented in my brain yet thus making me miss out of the opportunity to do so.
And it steals the accomplishment of the final thing existing. I don't feel an accomplishment by typing in google "I need a C# to C transpiler" and just downloading it. That's what LLMs feel like, even if I'm trying to steer them at a lower architectural level. I don't have the aha moments, I don't have the learnings, and I'm disconnected from the code.
Thus it feels like it's stealing all the intrinsic rewards from me, only leaving the extrinsic ones. And those are not rewards I am particularly motivated by.
We are all motivated by different things and being extrinsically motivated isn't a bad thing at all.
But being more interested in the problems rather than the solutions (and not wanting to "productize the solutions") is why LLMs are demotivating for me.
I have done a lot of introspection on this and realized that I'm very much driven by intrinsic rewards moreso than extrinsic.
I got into coding over a decade before it was my career because of the exploration, learning, and puzzle/challenge aspect.
Every time I have tried to be extrinsically driven (career or OSS wise) it's never worked out anyway. I could have done more to make it successful but I never cared about getting validation or getting users for my stuff (and the stress that brings).
I've been lucky that up until this point, the intrinsic rewards I have gotten from my job have aligned with company goals.
LLMs take all the intrinsic wins and leaves only the extrinsic ones. That makes me sad, but it is what it is I guess.
I have been thinking about a tool for months but didn't have the time. I finally gave in and built it at work in a week with LLM tokens. It worked fantastically. But I felt no accomplishment. It felt just the same as if I downloaded the tool from someone else's repo (and who had an overly eager maintainer that would implement my GitHub issue requests).
The hard part for me is ignoring LLMs in my free time to try and keep some of the intrinsic rewards to myself, without being annoyed that I could do it faster if I just "gave in".
Afaict the company doesn't own any of what was written by an LLM. In theory that means all the companies are opening themselves up to code being reused by third party and a lack of legal protection.
In reality I fear it's going to cause less copyright protections even for small developers.
When you write code by hand, you are the author. As part of your contract with your employer you grant copyright and authorship to your employer by default (as stated in the contract).
The LLM is not employed by you or your employer, because you can't enter contracts with non human or non human organizations.
When you license a non-LLM code generation service (like a page that creates a website for you), that company owns the copyright of the generated website because their deterministic system generated code by defined rules and mechanisms that were defined by the code generation system. Assuming no LLM as part of that, there is no code that is generated by the system outside of the rules that they defined (it's not filling in the blanks that you or the code generation system didn't explicitly define).
Since they own the copyright of the website, they can then assign the copyright and authorship to you because of your license agreement to them.
Since the LLM is filling in the blanks on its own in undefined ways, it is the author and not Anthropic/OpenAI/ETC. That means that even though you have a license agreement with Anthropic/OpenAI/etc.. to transfer copyright, they didn't have copyright/authorship, the LLM did. And since the LLM can't legally own copyright/authorship (since it isn't a human) then it can't grant it to you and you can't then grant it to your employer.
The employees and contractors are the authors, and because of the contract they sign they assign copyright to the corporation. Corporations, as a collection of humans are allowed to have authorship.
LLMs are not companies and they are not humans in any way shape or form, and thus cannot get copyright nor grant copyright to a third party.
I don't think case law totally supports the idea that working on a line by line basis means you have "no problem claiming copyright".
There problem is the LLM is still making assumptions on that line of code and thus it's still the main author (based on existing case law and the copyright office's opinion currently).
The markdown case is definitely more like the case I cited where the supreme court decided that specficiations and back and forth do not mean it's a deritive work and thus the actual implementor is the author, not the spec writer.
It's in fact the opposite from what I've read. In one of the supreme court cases cited by the copyright office itself in its opinion of AI works (https://en.wikipedia.org/wiki/Community_for_Creative_Non-Vio...) it is deemed that just you advising something to do the work for you, giving criticisms and revisions, isn't enough for authorship or co-authorship.
Do you think that human directing the agent owns copyright for any legal reason?
The case Community for Creative Non Violence Vs Reid (https://en.wikipedia.org/wiki/Community_for_Creative_Non-Vio...) solidifies a supreme court opinion that someone contracting a work and directing an author does not grant authorship to the commissioner of the work, it grants authorship to the person actually doing the work.
The author can grant authorship and copyright to the commissioner with a contract, but the monkey picture (and others) have solidified that only humans can be granted copyright. Since LLMs aren't human they can't hold copyright, and if the LLM doesn't have legal copyright then they don't have legal rights to assign copyright to you.
The problem I have with this analysis is it's missing the multi-dimensional aspect of "is this profitable".
It's fair to say that if all these operators are competing for tokens, that the OpenRouter token operator (not sure the exact phrase but the people running the models) are accounting for some level of margin.
However, how many of these are running their own data centers and GPUs?
If they are running their own infrastructure, then it's not a simple equation of if each specific token set is profitable, since it needs to account for the cost of running the data center. It could be that they believe that it is profitable in the long term by utilizing the long tail of asset depreciation, but that isn't guaranteed.
IF they aren't running their own infrastructure, then it's much easier to claim that it's profitable and has a margin (outside of running their servers to manage the rented infrastructure).
HOWEVER, a lot of data centers have some pretty crazy low prices for GPUs that may be vying for user base and revenue over profitability. In these cases, if data center growth starts slowing due to slower buildout then it's very likely GPU prices go up and inference stops becoming profitable for the open router owners.
So long term it's not clear how profitable even these open models are.
OpenAI and Anthropic definitely fall into the latter category too. Their infrastructure requirements are much higher than the open models, and they are being given huge discounts so Microsoft/Amazon/Google can all claim revenue (since they have profitability coming from other parts). It's not clear if OpenAI and Anthropic models would be profitable at inference if they were paying rates that cloud hosts would make a profit from.
There's just way too many dimensions to this scenario to flat out state that open router proves inference is profitable at scale.
There is case law surrounding the fact that just because you commission a work to another entity doesn't give you co-authorship, the entity doing the work and making creative decisions is the entity that gets copyright.
In order for you to have co-authorship of the commissioned work you have to be involved and pretty much giving instruction level detail to the real author. The opinion shows many cases that its not the case with how LLM prompts work.
The monkey selfie case is relevant also because since it also solidifies that non-persons cannot claim copyright, that means the LLM cannot claim copyright, and therefore it does not have copyright that can be passed onto the LLM operator.
This study came up on my feed but I'm not seeing much chatter on it. I'm interested in some perspectives from people who are better at reading if studies are quality or not.
> Abstract
>
> AI assistants, like GitHub Copilot and Cursor, are transforming software engineering. While several studies highlight productivity improvements, their impact on maintainability requires further investigation. [Objective] This study investigates whether co-development with AI assistants affects software maintainability, specifically how easily other developers can evolve the resulting source code. [Method] We conducted a two-phase controlled experiment involving 151 participants, 95% of whom were professional developers. In Phase 1, participants added a new feature to a Java web application, with or without AI assistance. In Phase 2, a randomized controlled trial, new participants evolved these solutions without AI assistance. [Results] Phase 2 revealed no significant differences in subsequent evolution with respect to completion time or code quality. Bayesian analysis suggests that any speed or quality improvements from AI use were at most small and highly uncertain. Observational results from Phase 1 corroborate prior research: using an AI assistant yielded a 30.7% median reduction in completion time, and habitual AI users showed an estimated 55.9% speedup. [Conclusions] Overall, we did not detect systematic maintainability advantages or disadvantages when other developers evolved code co-developed with AI assistants. Within the scope of our tasks and measures, we observed no consistent warning signs of degraded code-level maintainability. Future work should examine risks such as code bloat from excessive code generation and cognitive debt as developers offload more mental effort to assistants.
Yeah I don't disagree that selling components is going to be hard business in the age of AI. Just mostly pointing out that it was a good business previously.
Telerik, DevExpress, and a lot of other companies have made profitable businesses that have lasted well over a decade on that business premise. Selling solid and easy to integrate pre-made components has been a pretty good business for a while.
FWIW I only mentioned staff engineers because the survey found staff+ engineers reported the highest time savings. The survey itself had time savings averages for junior (3.9), Mid level (4.3), Senior (4.1) and Staff (4.4).