Not the OP but I've tried something like this for a couple things. It costs a $100 monthly plan for about 2 weeks or so, so $50 about? (which is equivalent to about $4500 with API pricing, if you were using Claude, or maybe $100 if you are using something with less grossly inflated pricing).
Working at bigcorp for 14 years so far and I struggle to think of a single day where I didn't need to consider algorithmic complexity or efficiency. Do you not write code that fetches things from a database? Do you not need to make tradeoffs between how much data you fetch at once, which fields you load, which things you cache, whether your query joins on the db or materializes things separately, whether you lazy or eager load, whether you are doing a O(1) or O(n^2) lookup and the tradeoffs, whether you can use a db index or not, memory/latency/compute/storage tradeoffs, etc? I feel like in even a simple bigcorp SAAS you need to consider this stuff daily.
Unless you are dealing with data at true scale, and not many people are, often the imperfections are hidden because they run fast, even if they are quadratic. I'm more referring to being actually forced to sit down and write out your own algorithm in a novel way.
Yes, during my BigCorp tenure I had to think about complexity all the time, but 99 times out of 100 there was an off the shelf tool available for my specific data structure and I didn't have to think about the algorithm at all beyond "oh there's a library that solves this for my specific data structure, and it's O(N)log n that will be fast enough". Whereas so much attention in interviewing traditionally was based on these "write a bubble sort algorithm from scratch" type questions which your average engineer basically never has to do on the job unless they are operating in a very high performance/scaling type of role.
I find this discussion interesting. I've had huge increases in accuracy and huge reductions in token usage by capping my Claude models at 200k instead of 1M. I find 1M unusable and wasteful and feel that 200k should be the default. This also makes sense given that the whole reason people use "Ralph loops" is to keep the context window small for all tasks to get better results. Of course, clearing it yourself and manually managing it is better, but if I have 8 projects going in different terminal tabs I'm not watching any one of them that closely to effectively do that.
Claude Design is good at making a bunch of UI pages in a single design look consistent, and it's better at making an initial starting UI than just asking Claude Code. Think of it like Anthropic's version of Figma. It honestly works pretty good and I use it often and feel that it saved me a lot of time. It's pretty token heavy though.
Why would you stop learning new things?
I lead a team of developers as part of my current role, reviewing and approving what they work on (in addition to doing development and architecture design as well) and from my experience, the difference in someone who has spent time building up their skills in how to do agentic development with AI is so insane. One person can build more than an entire team in some cases, while maintaining quality and needing little to no feedback, yet others using the same AI tools struggle to get anything done. How is this not a skill issue and why would one conclude that you need to stop learning if this is the case?
> How is this not a skill issue and why would one conclude that you need to stop learning if this is the case?
It's not the skill I'm interested in learning nor is it the same skill I spent my career building
My problem also is not just to do with "My future learning" it is also about the value and opportunity to use the skilled I already spent decades on. Which are now devalued heavily or will be in the very near future
Maybe to cheer you up: we're doing a few tests at our org, and we found that product-minded engineers still have a tremendous leg-up compared to other people when it comes to actually shipping products. It's not even a race.
It's not just quality of code, it's also speed of execution, maintainability. Why? Because we're not building 200 database tables + 200 endpoints when 1 table + enum suffices. Yes that happened. There was also one feature that I can't comment much on because it would doxx but: a PR from non-dev took months, was 100k LOC and rejected by product and engineering as low-quality. The same feature built by my team was 900 LOC, feature complete, shipped.
Nothing beats the combination of domain expertise and expertise in the medium.
I'm always learning new things. The things I learn jsut happen to no longer align with what current speculative crazy investors want.
>the difference in someone who has spent time building up their skills in how to do agentic development with AI is so insane.
and what if I do not need agentic development for my creations? my domain is not one where "building more" is the bottleneck. I don't need to ship faster, I nee to ship more deliberately
That take is pretty disingenuous and it makes it hard to take an argument seriously. Who are you to say they did nothing? If someone uses an AI agent to distribute tasks to it like a tech architect does to a team of developers by teaching what to do, and assigning to whom should do it, with examples and instructions, and then reviews the output, offers feedback, and iterates for a few weeks until something is complete, how is that not doing anything? What exactly are you proposing they did for those couple of weeks? Should I imagine that all architects have done nothing their entire life?
Are developers that use a "high level" language like C++ also doing nothing because the machine did all the work of compiling to assembly and machine code for them? Nothing to celebrate and no honor?
At which point does this argument stop being valid? Is the project manager the one that created the product? Is it the CEO that is paying the people to? Is it the bank that has granted the loan to build the company?
In my view, the one that "creates" is the one that puts in the majority of the effort. Under this definition, the average vibe coder isn't creating anything.
With this logic, what is the point to read a book about false events that did not happen? Can we please stop attacking everyone's version of fun or what makes them happy just because it isn't exactly what we like?
Totally inaccurate comparison. Garbage dumped on the side of the road is still garbage. It's more like if someone dumped lab-grown diamonds on the side of the road that are virtually indistinguishable from mined diamonds. Someone would be happy to take them and none the wiser.
> It's more like if someone dumped lab-grown diamonds on the side of the road that are virtually indistinguishable from mined diamonds.
Equating LLM generated code to "lab-grown diamonds" is disingenuous at best.
> Someone would be happy to take them and [be] none the wiser.
If the quality of GenAI PRs were equivalent to those authored by experienced contributors, then there would not be as many GenAI PR bans in FOSS operating system repositories.
The quality of GenAI PRs scales with the driver. Many are low-effort, ill-considered, overly verbose and otherwise bad. I've seen decades of similar patches/PRs from humans.
If it "looks like claude" in that it's overly verbose (in code or comments), missing tests, etc then it should be rejected for lack of merits. If the only indication is "this user fixed 10 bugs in an hour" and the PRs are otherwise fine on the merits, rejecting the PRs because an LLM wrote them is the same as rejecting them because you know they're from an emacs user.
The problem is "This user submits in 60 minutes enough PRs to keep us busy for a week".
You don't know that they are low effort PRs until you expend time and energy, while in the meantime more important PRs might be in the queue that can potentially never get seen if the submitter decides to keep that rate up for a week.
The project will die before you get to other's PRs decades later.
The answer might be to RR reviews from submitters and not treat PRs as first come first served.
That way other submitters don't have their PRs blocked.
I’ve been in your same situation for a long time now and I’ve been building a platform to help myself navigate through so many PRs, and doing all of this on github wasn’t sustainable, you could try it out and see if it helps your situation.
https://pyor.review
Like many things in complex projects such as operating systems, accepting PRs is not as simple as "if this one use of a tool works, why not accept it?"
Why? Because the onus of determining fitness of purpose and correctness has to be done by someone. So if a PR is buggy and/or lacking in test coverage, but was made by a contributor making an honest effort, then experienced contributors can help educate the person as to what is missing or needs to be considered. Ultimately, this is a form of apprenticeship.
Contrast that with someone using an LLM to produce the exact same PR. Who can be mentored? Who can be referred to materials which can deepen requisite knowledge?
But this is leaving out the part where the developers that clean up or rewrite... will do it using LLMs.
Have you tried refactoring or porting codebases larger than a million lines of code pre-gen-AI and again post-gen-AI? It's night and day difference. One would be insane to schedule a team on 8 months worth of grunt work porting from one language or framework to another which can now be done by 1 person in 4 weeks.
Of course the person driving it has to tell it exactly what to do and has to have the requisite knowledge to understand how to effectively structure or fix the software. Maybe new developers don't build this skill so easily anymore. But I don't see why a strong developers skills would atrophy in this case though unless they just never use their knowledge and never give instructions to the AI.
To developers speaking of skill atrophy: are you still making sure that when using LLMs you are actively exercising skills like system design, debugging, reviewing for clean code and just in general doing effective code review? If you are doing that, why do you feel skill atrophy? And if you aren't doing it, why not? What about LLMs prevents us from exercising these skills?
Do people actually use languages where it doesn't do any compile time checks on the API in 2026? Why would developers put up with the lack of that. I'm not in this ecosystem but what you are describing sounds like the bare minimum to me that should be table stakes.
I agree. But the data science/engineering space is enamored with Python. Makes good sense when doing interactive work. Makes no sense in production. But by that point, most developers consider it a sunk cost and just keep their Python apps limping along rather than rewriting.
That's why polars is a great option. Start prototyping in python, then a relatively easy port to a Rust app when the need hits.
You can still have extensive "compile-time" checking with linters and static type checkers. This makes Polars even better in typed Python, as it type-checks much better than the dynamic mess that is Pandas.
Polars is much better than pandas in this regard. But using it via Python still carries the risk of runtime errors.
Python's linters leave many holes unfilled - it catches some stuff but still leaves everything else to the runtime. Literally every Python application that I've worked on in the last 3 years a) is 100% type checked yet b) still hits massive numbers of novel runtime errors on the regular. Python's anemic type system is in no way a substitute for an advanced compiler.
When I deal with datascience, I rarely have type problems in my programs that python typecheckers can't catch. I do have type and dirty data problems of the dataframes/csvs/parquet I'm reading.
> I rarely have type problems in my programs that python typecheckers can't catch.
> I do have type and dirty data problems of the dataframes/csvs/parquet I'm reading.
Something about those two statements makes my brain explode. You rarely have type problems, except when dealing with data? Isn't the whole point of a program to deal with data?
Empirically false. Python's type system is not sufficient to describe runtime variants, period. I have worked on at least three system that used mypy in strict mode yet hit runtime errors constantly.
I get where you're coming from. A good type system should provide invariant guarantees about runtime behavior. But Python's does not.
