> A bad or below average dev with AI will run your product and company into the ground in a matter of weeks.

I had a recent experience with this. Although it was months and not weeks and there were other factors into play such as the market etc but the last company i was in had a poor engineering culture with inexperienced engineers equipped with AI output some of the lowest quality features for both customer-facing products and internal dev tools. A lot of customers churned, and im sure quality us part of the reason.

Do you mean this applies to other engineers who are less experienced than yourself or only to you?

Same here. I sometimes dont feel like typing but I use voice dictation, that should be the first option in a text convo imo.

I use dictation a lot and god it’s so bad. I have to correct something every single time.

Which is part of the reason why sending a voice message that the receiver might have to read a transcription of is so bad.

And it doesnt play reallt well with Aurora

> Learn data structures and algorithms. Understand finite state machines and context free grammars. Learn at least some mathematics. Discrete math, Boolean logic, and statistics. Learn how operating systems work, networking, databases, compilers, machine code, low-level details like registers and the cache hierarchy. Learn more obscure programming languages: like Lisp, Prolog, Haskell, and Forth.

Also, these may seem like separate subjects but there is some overlap especially once you work with things like databases in production at some scale.

To me AI conversations are exactly like ones about VIM config etc. ok cool, but show me something cool you built with it, and most importantly something that was worth the cost.

Otherwise, it sucked the air out of everything else especially in tech and startup culture.

I don't think this is a good resource for an intro tbh. Unless you are interested in proofs and have some probability basics covered, it feels quite dense.

I liked Principles of Product Development Flow a lot more because it was easier to digest, although it's a different application of queuing theory.

That is also a good book containing a few practical applications of queueing theory, but it won't do anything to help you analyse your own systems on a more fundamental level.

Yeah I totally agree. My point was that it can be intimidating as an intro book to the topic. Excellent material otherwise

What kind of problems do people solve that require this amount of money per month, let alone per day?

Is anyone reviewing the output of the generated work (PRs, docs etc)?

No, and nobody is going to find it when the guy from a third world village using a fake name that they hired to vibecode features puts a bitcoin miner in one of his daily 10k line agentic PRs.

At work we are literally forced to use AI and it’s part of our performance review. Even though I really like coding by hand, I have to now use AI so I can keep my job. I will try this out though, 2 days per week using AI and the rest handcoding, enough to stave off the inevitable lay off perhaps.

Surely it can’t be hard to token max at work the same fucking way people have games Jira metrics for years and years.

If I’m ever in that position (everything I work on it air-gapped, it’ll never happen) I would make it a priority to figure out how to game that bullshit metric so I could get on with solving actual problems.

I imagine a lot of people do this. Metric becomes a target, etc.

I recommend trying "make this code more enterprise", it seems to pull in the joke and start overengineering everything and giving them absurd names.

And what of the original author is not there anymore?

The world will not end. I’ll get there.