- generate new modules/classes in your projects - integrate module A into module B or entire codebase A into codebase B?
- get someones github project up and running on your machine, do you manually fiddle with cmakes and npms?
- convert an idea or plan.md or a paper into working code?
- Fix flakes, fix test<->code discrepancies or increase coverage etc
If you do all this manually, why?
AI doesn't really help me code vs me doing it myself.
AI is better doing other things...
It can also encourage laziness: If the AI reviewer didn't spot anything, it's easier to justify skimming the commit. Everyone says they won't do it, but it happens.
For anything AI related, having manual human review as the final step is key.
The fact of the matter is, I am not even using AI features much in my editor anymore. I've tried Copilot and friends over and over and it's just not _there_. It needs to be in a different location in the software development pipeline (Probably code reviews and RAG'ing up for documentation).
- I can kick out some money for a settings sync service. - I can kick out some money to essentially "subscribe" for maintenance.
I don't personally think that an editor is going to return the kinds of ROI VCs look for. So.... yeah. I might be back to Emacs in a year with IntelliJ for powerful IDE needs....
Anyway -
Education is a very slow and difficult thing, because it is paired with the maturing of the individual along with sharing enough concepts to spark connection _but_ not so much as to overwhelm. Adult humans can make the individual judgment that algorithms can't - WIS not INT.
Regarding dysfunctions.
Children can absorb knowledge _very_ fast in the right environment. I'm uncertain how much that replicates across the whole population, but you can see this in the top-flight homeschoolers.
When we were looking for better environments for our kid than the neighborhood school, we realized that private schools have an advantage in that they can select the parents and effectively curate the environment. Most of the issues in the public elementary school were generated by dysfunctional parents combined with certain political choices on classroom management. The second is materially fixable given work - the first is not something a school board can fix. Much of the discourse on education needs to relate to the total educational delivery across family/student quartiles of capacity, rather than trying to cherry pick a student, or a class, or - . You see, it's very hard to teach when certain students have no self control and disrupt the class continually, and there is no facility to remove them from the class for the good of others. And as we all know- 90% of students are above average, and our kids are _definitely_ gifted. So there's no easy political way to solve the environment problem - which happens to be the key drag on education today.
I've spent a lot of time doing this sort of agentic coding and it's ... not great as your full time Thing.
Much better for it to be auxiliary boost.
I suppose that's true in one sense - in that I'm using EKS heavily, and don't maintain cluster health myself (other than all the creative ways I find to fuck up a node). And perhaps in another sense: It'll try its hardest to run some containers so matter how many times I make it OOMkill itself.
Buttttttttt Kubernetes is almost pure maintenance in reality. Don't get me wrong, it's amazing to just submit some yaml and get my software out into the world. But the trade off is pure maintenance.
The workflows to setup a cluster, decide which chicken-egg trade-off you want to get ArgoCD running, register other clusters if you're doing a hub-and-spoke model ... is just, like, one single act in the circus.
Then there's installing all the operators of choice from https://landscape.cncf.io/. I mean that page is a meme, but how many of us run k8s clusters without at least 30 pods running "ancillary" tooling? (Is "ancillary" the right word? It's stuff we need, but it's not our primary workloads).
A repeat circus is spending hours figuring out just the right values.yaml (or, more likely, hours templating it, since we're ArgoCD'ing it all, right?)
> As an side, I once spent HORUS figuring out to (incorrectly) pass boolean values around from a Secrets Manager Secret, to a k8s secret - via External Secrets, another operator! - to an ArgoCD ApplicationSet definition, to another values.yaml file.
And then you have to operationalize updating your clusters - and all the operators you installed/painstakingly configured. Given the pace of releases, this is literally, pure maintenance that is always present.
Finally, if you're autoscaling (Karpenter in our case), there's a whole other act in the circus (wait, am I still using that analogy?) of replacing your nodes "often" without downtime, which gets fun in a myriad of interesting ways (running apps with state is fun in kubernetes!)
So anyway, there's my rant. Low fucking maintenance!
you do have to know what you're doing and not fall prey to the "install the cool widget" trap.
Being authentic in the working world helps in so many ways. And it works when your goals and the goals of the company align. The advice to just shut up and code leads to no good outcomes for anyone.
People have different presentations for different social contexts. That's typical and normal. For a working example, the social context of the marital bedroom is not the social context of the city playground where you mind your kids. Differences in clothing, actions, words.
This spans into most areas of life.
You don't have to sterilize your work life - but you do have to have _boundaries_.
I would pay for zed.
The only path forward I see for a classic VC investment is the AI drive.
But I don't think the AI bit is valuable. A powerful plugin system would be sufficient to achieve LLM integration.
So I don't think this is a worthwhile investment unless the product gets a LOT worse and becomes actively awful for users who aren't paying beaucoup bucks for AI tooling- the ROI will have to center the AI drive.
It's not a move that will generate a good outcome for the average user.