I have generally been a generalist in my career. I am not nearly as wide a generalist as Claude.
I do get good mileage out of my creative brain parts and hubris..
lawik
Nerves Core Team
tfwright
I’ve observed a massive shift in the capabilities of AI, Claude at least, in the past few months. Last fall it felt impressive but still a toy and I shuddered to think of Claude authored production code being shipped. Over the last month we have ramped up Claude integration with our development process and my productivity is up 10x at least. I will say code quality is dropping. We are shipping more code that is not as well-tuned despite my attempts to add as many guard rails as possible because my arguments only have so much weight when the cost of rewriting is so low. The CEO who hasn’t touched the code in years is pushing up huge PRs with major features we have not had the resources to tackle and is only so receptive to my warnings. My biggest fear at this point is getting dragged into a “black-box” model for application development where there is simply too much code churn for me to have any ownership over anything but the prompts. I can’t imagine the pleasure and satisfaction in the craft remaining the same, if it remains at all.
edit: I realize this just makes me sound like every old dude gone before and AI is in some respects no different than any other technology, but I’m not so sure. Time will tell
5
Vidar
The black-box model is scary, but I feel less so for functional programming with pure functions. If the inputs always give the right outputs do I really need to know the details in between? (For speed and resource use yes, but the ability to know it is a correct black box makes it less scary). If I can test those I sleep well I think. And then there is the real world and side effects, but at least less surface area to really worry about.
I also think that maybe Claude and Co at some point will be able not to just make it work, but also explain or better yet prove that it works. We are not there yet, but the future is a long time.
(I faintly remember there used to be something called “formal verification” which seems largely forgotten about today. Maybe that will make a comeback. If it can be proven to work I will happily take a black box component).
I think there is also a case to be made for diversification according to risk. For critical system or life support I would not use LLMs today. But for most other things I’m beginning to open up to the thought. Indeed my main project these days is mostly Claude coded with me doing the requirements, direction guidance and big picture decisions. And chatting with big letters as needed. I might even have taught Claude some new words on occasion.
For me the ability to make, prototype and test with such ease is very refreshing and satisfying.
(I’ve sure had my share of Claude frustrations so there is that too. But I’m thinking give it another year and we will really be cooking).
2
Zurga
This has been the nuanced take I was waiting for in this thread. Yes, an LLM will sput out 1000 lines of code without a hiccup, but the actual developers that need to work on it will spend days refactoring. The effects of outsourcing seem really similar.
1
Vidar
Not my experience. If anything Claude is better at planning layers, contexts and boundaries for easier extensions and refactoring than I am. (Which is not very hard to achieve, but nevertheless). The real trick is that Claude is pretty good at refactoring if needed. That is my story and I’m sticking to it!
0
nxy7
Just another datapoint but for me LLMs are better than the work outsourced guys were doing (and also better than big chunk of my company workforce).
I guess the big thing is that someone needs to keep high level architecture in his head at all times though because without it commanding AI is just less effective. Also it helps to have high code standards. Many of my coworkers didn’t care about code quality even a bit, I guess it will also be reflected in their AI work as they won’t guide models as much (even without guiding the quality of AI output is higher than human output though so I still count that as a win).
I wouldn’t say that using LLMs is similar to outsourcing. Even just the sheer speed makes them uncomparable (as in even if effect is similar at first glance, the speed of delivery gives you new possibilities like deeply exploring design space, making 5 variants of some thing and picking the best one).
3
egeersoz
After Opus 4.5 came out, I migrated my 180k LoC project (generating real revenue from real customers) from a one-Postgres-schema-per-tenant to a shared-schema data topography and architecture where everything is under public and scoped by tenant_id. As one can imagine, this was a massive undertaking and required:
- a complex series of data migrations for 150+ tenant tables, grouped into levels, with each level ordered based on interdependencies
- post-migration data integrity checks and testing (make sure counts match, FKs match, etc. etc.)
- post-migration performance benchmarking scripts
- rewriting all the context modules and their queries to take and use
tenant_idinstead of a stringtenantprefix - modifying the controller contracts
- essentially rewriting the test suite, including factories and mocks
- a huge amount of manual testing
The migration also required changing integer PKs/FKs to uuids. The reason this had to be done was because we were previously using IDs as user-facing display numbers (e.g. Invoice #3829), and in the new system these had to be preserved. So the work also involved adding new tenant-scoped display_number columns that would contain the old schema-scoped integer IDs, making sure they auto-increment correctly moving forward, and rewiring everything accordingly.
The final diff was +50k -18k. You read that correctly: one branch, fifty thousand lines added, eighteen thousand removed or changed. About 15k of the new lines were documentation, plans and Ecto migration files. The rest were new code and new tests.
Without AI, this would have taken me multiple months and there’s a good chance the sheer scale and tediousness of it (as well as the risks) would have burned me out. I also would not have been able to add new features easily. Especially because I have a full-time job.
With Opus 4.5, it took two and a half weeks (mostly evenings and weekends). I read every line of documentation/plan it wrote, every line of code change that it made and tested everything thoroughly, both manually and also using ancillary AI chat sessions where I intentionally kept context limited. Then I deployed the branch to staging and had several users do UAT using their own (migrated) data. They found:
- Two bugs related to the data migration itself (I had some
{:array, :integer}columns where the integers were FKs and the AI didn’t catch that, and neither did I because I had completely forgotten about them) - Some cosmetic issues where the UI was still showing
id(now uuids) instead ofdisplay_numbers - Four HTTP 500 errors in some rarely used features, caused by modified API contracts where the FE was still calling the endpoint with the original payload shape. Easy fix.
So yeah. An eight year old medium-sized Elixir project went through a titanic architecture change in a short timespan. AI planned out the entire thing, wrote all the code for it, wrote all the post-migration data integrity checks and performance benchmarking scripts, rewrote most of the test suite, and modified the FE to match the updated API contracts. It also wrote the operational step-by-step for the rollout. We deployed it in a “big bang” fashion and it has been fully stable.
Here’s the fun bit: I actually got a few quotes for this project, and they ranged from $100k to $175k, and estimated timelines ranged from four to six months. In contrast, my total AI spend during the 2.5 weeks was less than $2k. Make of that what you will.
6
Vidar
And I was amazed at which ease Claude implementing some 4000 line statistics library.
That is at another level entirely!
0
Lucassifoni
80% of the way through a massive refactor where I am neck deep in, about 15 full days now, assisted by opus 4.6.
I’ve thought about doing this architectural change for the last 18 months but could not justify its cost, being alone. My experience is about the same as yours except that I am creating a new prod, doing a lot of manual intervention in the plans and QA, and will migrate each tenant one by one to make it less dramatic. My tenants are fully isolated anyway so I do not have a real choice there.
For the record, I never planned that this specific app would become a real company, so I am refactoring it from single-tenant (« server closet » model), local storage, singleton processes, to a multi-tenant architecture, object storage, and horizontally scalable. Never planned for it to be sold to more than 1 client at the start 
.
Creating a lot of automated « architecture checks » helped a lot. Making the changes as mechanical and TDD-driven as possible helped too. Without this tooling my other options were not doing this migration at all, or seeking funding, despite having planned it carefully for « when I will have help », my plans were only a huge github issue for my own attention, and an (un?)healthy dose of hope.
I also considered throwing everything away and restarting from scratch with a scalable model from the get-go but it wasn’t an option that I was keen about, for obvious reasons. I don’t like wasting an useful app.
4
egeersoz
Yeah, my motivation for the architectural change was actually the same as yours: eight years ago me and my (non-technical) cofounder’s business plan was to sell to a relatively few large companies, for which a “one-schema-per-tenant” model makes sense. Since then we’ve switched to targeting smaller firms and solo shops. And it turns out having thousands of schemas in Postgres causes a lot of problems and bottlenecks in all kinds of places. I found this HN thread where people shared similar/identical experiences.
3