Completely backwards - the fun in the job should be to solve problems and come up with solutions. The fun in the job is not knowing where to place a semicolon.

https://www.latimes.com/environment/story/2025-10-04/chevron...

The guy who made this site is selling a $7k stove? Good luck with that, my dude.

"Perfect code from the agent everytime" isn't really what the expectation is. Bugs are always going to be shipped into production, no matter who or what is writing the code. Where SDLC is really getting compressed is in the iteration phase.

For example:

- "This is a known good state; write tests to enforce this state" is something that takes minutes now instead of days. That is incredibly powerful for understanding and maintaining a system.

- Bugfixing is a matter now of an agent watching error logs, diagnosing traces, and immediately issuing PRs with suggested fixes, something that again would have taken hours at least and is now down to minutes (and can be a 24x7 operation, which for most businesses is a revelation).

- Engineers have the freedom to land enhancements that in the Before Times would have sat in the backlog for months and years on end because of the time commitment. That has knock-on effects of quality, features, and just overall improvements for users.

It is a very, very, very different world that we're operating in, and what used to be huge steps of the SDLC now take less time than checking your email in the mornings with your first cup of coffee.

Then, as part of the session, you would artificially introduce a bug into the system, then run into the bug in your browser. You'd see the failure happen in browser, and looking at Cloudwatch logs you'd see the error get logged.

Two minutes later, the SRE agents had the bug fixed and ready to be merged.

"understand how these systems actually function" isn't incompatible with "I didn't write most of this code". Unless you are only ever a single engineer, your career is filled with "I need to debug code I didn't write". What we have seen over the past few months is a gigantic leap in output quality, such that re-prompting happens less and less. Additionally, "after you've written this, document the logic within this markdown file" is extremely useful for your own reference and for future LLM sessions.

AWS is making a huge, huge bet on this being the future of software engineering, and even though they have their weird AWS-ish lock-in for some of the LLM-adjacent practices, it is an extremely compelling vision, and as these nondeterministic tools get more deterministic supporting functions to help their work, the quality is going to approach and probably exceed human coding quality.

This is not exactly that, but it is one step up. Having agents output code that then gets compiled/interpreted/whatever, based upon contextual instruction, feels very, very familiar to engineers who have ever worked close to the metal.

"Old fashioned", in this aspect, would be putting guardrails in place so that you knew that what the agent/compiler was creating was what you wanted. Many years ago, that was binaries or bytecode packaged with lots of symbols for debugging. Today, that's more automated testing.

https://en.wikipedia.org/wiki/Jevons_paradox

That is just such a wildly cynical point of view, and it is incredibly depressing. There is a whole huge cohort of kids out there who genuinely want to learn and want to do the work, and feel like using AI is cheating. These are the kids who, ironically, AI will help the most, because they're the ones who will understand the fundamentals being taught in K-12.

I would hope that any "solution" to the growing use of AI-as-a-crutch can take this cohort of kids into consideration, so their development isn't held back just to stop the less-ethical student from, well, being less ethical.

- Just start typing

- Let the LLM analyze what you're typing, given the RAG database of everything else you've added, and be able to make those kinds of correlations quickly.

- One-button approve the backlinks that it's suggesting (or even go Cursor-style yolo mode for your backlinks).

Then, have a periodic process do some kind of directed analysis; are you keeping a journal, and want to make sure that you're writing enough in your journal? Are you talking about the same subjects over and over again? Should you mix things up? Things like that would be perfect for an LLM to make suggestions about. I don't know if Roam is thinking of doing this or not.

You cannot get, for example, a new Focus in the US market. When you could, they were much higher quality.

The only Chevrolet you can buy in the UK is the Corvette. Chevrolet makes nine SUVs, four trucks (with however many infinite variations), and exactly one shitbox non-Corvette car.

If US automakers started turning their eyes towards smaller more efficient cars, where hauling Brayden to and from their soccer games didn't require multiple tons of steel, then they could compete in the EU market.

What do you mean, I can't scale up because I've used my hardware capex budget for the year?

And the root of the problem is peer dependencies and the JS community's lack of backwards compatibility and maintenance.

Take any decently-sized JS application, whether React or whatever else. Put it in Github. Turn on dependabot. Watch your pull requests go up by 5-10 PRs per week, just to bump minor versions, and then watch how 1 of those PRs, every single time, fails because of a peer dependency on a lower version.

This has been a problem forever in the community, and there's no good solution. There's also just no feasible way to make a solution due to the nature of the language and the platform itself. You just have to absorb that problem when you decide to use eg Node for your backend code or React/etc for your frontend code.

For example -- not long ago, when you wanted to do l10n/i18n for your business, you'd have to go through a pretty painful process of integrating with eg translations.com. If you're running an ecommerce site with a lot of new products (and product descriptions) coming online quickly, that whole process would be painful and expensive.

Fast forward to today -- a well-crafted prompt to Llama3.1 within a product pipeline makes that vendor completely obsolete. Now, you could argue that this kind of automation isn't new, you could have done it with an api call to Google translate or something similar, and sure, that's possible, but now you have one single interface into a very broad, capable brain to carry out any number of tasks.

If I was a vendor whose business was at all centered around language or data ETL or anything that involves taking text and doing something with it, I would be absolutely terrified at someone writing a 20-line python script with a good system prompt that would make my entire business's reason for being evaporate.

To compare, 3.9 million cars sold in Q3.