wreath

Leadership not so much. Its mostly engineers who interpret shipping fast as “no code review” and other risky things like automated deployment with poor test suite, all while taking months to go from idea to implementation and nobody seems to be payin attention to this part

Silver lining is that this slows down the all the crappy half baked vibe coded crap from being shipped.

> 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.

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.

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

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.

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)?

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.

And what of the original author is not there anymore?

Even with enough money, you may not be able to attract/keep talented engineers who are willing to put up with such a work environment (the codebase itself, and probably the culture that led to its state) and who want to ship well built/designed software but are slowed down by the mess.

PMs do different things in different organizations.

In my last job, PMs were responsible for identifying problems that were worth solving and align with the overall company vision and plans within the owned domain, and design+engineering decided how to solve those problems and what to build. Of course with collaboration w/ the PMs (and EMs).

The job before that, PMs wrote jira tickets and nagged engineering when tickets will be delivered. The "what problems to solve and what to build" questions came straight from CEO/CTO.