> > For someone like you, who likely has years of experience without LLMs, your brain totally understands good code/bad code, good architecture, and just general intuition around code and systems. LLMs must be an absolute gamechanger. But for someone like me who is starting out in this field, how am I supposed to build the years of experience and intuition that comes from manually writing code and building systems when companies are expecting AI to be used from here on out?
Answer: juniors need to work with seniors, and the seniors need to teach the juniors, and the juniors need to learn to use LLMs to learn, not just to do the work.
The bias to build might mean faster token burn through (higher revenue for the AI co). But I think it's natural. I often have that same impulse myself. I prefer all the codebases I work on that have minimal external dependencies to the ones that are riddled with them. In Java land it's extremely common to have tons of external dependencies, and then upgrade headaches, especially when sharing in a monorepo type environment.
We used to reuse code a lot. But then we got problems like diamond dependency hell. Why did we reuse code a lot? To save on labor. Now we don't have to.
So we might roll-your-own more things. But then we'll have a tremendous amount of code duplication, effectively, and bigger tech debt issues, minus the diamond dependency hell issue. It might be better this way; time will tell.
Not just to save on labour. To have confidence in a battle tested solution. To use something familiar to others. For compatibility. To exploit further development, debugging, and integration.
Speaking of rolling your own things, i had claude knock out a trello clone for me in 30 minutes because i was irritated at atlassian.
I am already using it for keeping track of personal stuff. I’m not going to make a product out of it or even put it on github. It’s just for me. There are gonna be a lot of single team/single user projects.
It is so fast to build working prototypes that it’s not even worth thinking if you should do something. Just ask claude to take a shot of it, get a cup of coffee and evaluate the results.
I'm sure after you've had Claude build it, you learned a ton of how to build such a thing (I certainly did for my projects).
Basically, the data model is dead simple, you just spin up a SQLite db, create a React frontend, grabbing a good drag and drop library that implements these cards, write some simple but decent looking CSS, some React and backend boilerplate to wire the thing together - and boom - you're done.
This sounds simple when I write like this, but the complexity comes from knowing what library to use, figuring out its API, and assembling the whole thing together - which Claude is great at, but once you see the whole thing put together, you come to understand these things as well, and become more skilled at building stuff like this.
But i don’t want to learn how to do that. I already know how to write code and i have built a bunch of production rust apps from scratch. I would prefer if i never have to write code. I don’t enjoy writing code, don’t take pride in having that skill. I enjoy the process of identifying a problem and producing a solution to that problem. Coding is just something i had to learn how to do in order to solve problems.
The absolute moment that ai is capable of producing all the useful code for a project I probably will never write another line of code again.
Yeah, that is the future isn't it? Because I've built the same thing for myself and have the same plans to not put in the work of sharing it with other people. It works for me and my friends and the contractors working on my house and I'm sure everyone else is doing it too!
Yes, code has always been the easy part. LLMs produce it even more copiously, so it is ever easier now, and yes, that makes the bottlenecks worse:
- communication between humans
"what are we to build?"
"what is the architecture?"
"how shall we design this?"
etc
- architecture review
- design review
- code review
- docs review
- ...
LLMs are also being used to:
- understand what is possible
- and how to achieve it
- architect
- design
- review
Only the communications part is an inherent bottleneck that we cannot completely fix with LLMs -- we're humans selling to humans, humans buying from humans, humans managing humans, humans trying to convince other humans. LLMs cannot make this part much more efficient than it already is.
But even with that one constraint about human-to-human communications, LLMs are improving throughput: by writing better docs faster, by helping us get the gist faster (though using LLMs to read docs that could have prompts embedded is scary), and so on.
Personally, where the communication burden is intense I don't think we'll see 10x, 5x, not even 25% efficiency improvements. But now consider projects where the communication burden is minimal as there is only one human -- personal projects, open source projects, that sort of thing. In those cases a 5x, even 10x efficiency improvement is not out of the question. Many projects have communications burdens that are not so intense that they can't experience 2x efficiency improvements.
The challenge will lie in safely maximizing those improvements and doing it better than the competition.
Answer: juniors need to work with seniors, and the seniors need to teach the juniors, and the juniors need to learn to use LLMs to learn, not just to do the work.
reply