I assume the "gatekeeping" decision to not implement a feature request is coming from someone responsible for the product, not from a developer.

> Workflows like jira_close.yml use deprecated atlassian JIRA actions and have a dependency on the gh-actions repo. This is not ideal and unecessarily complex. PR updates jira_close workflow to use direct API calls via curl. It preserves custom fields used too.

I won't speak to this projects' management and how they prioritize things, but from my own experience, pre-AI, this type of change would have been firmly in the "this is a minor annoyance, put it in the Tech Debt Backlog alongside the 50000 other tickets" and never actually done. The cost of a human investing the time understanding how to fix the problem, doing code changes, testing them, and deploying them is just way too high for what actual value this change brings, which is close to nothing.

Now with AI, it's as simple as firing up an agent and telling them to make a change; as much effort as writing that backlog Jira ticket in the first place.

Similar to the problem open source is having with low-value PRs, companies are going to have to start realizing that code is not free to review or maintain, even when it's generated for ~free, in their internal processes. Just because an agent can fix a minor tech debt annoyance with a few lines of instructions doesn't mean it should.

[0] https://github.com/snowflakedb/snowflake-connector-net/pull/...

I specifically remember a prolific HN commenter working on an AI video startup claiming that by the end of 2025, children would be able to create Hollywood-quality, feature-length movies using available AI video tools.

I believe this person's startup has (wisely) pivoted to building AI-powered tools for the movie industry.

Too true. This isn't limited to AI, either. The most obvious example in my lifetime was during peak blockchain hype, when people who had never worked in finance convinced themselves that blockchain was going to act as the backbone for how money gets moved around. As if the problem that needing solving was Bank of America doesn't trust Capital One to update a number in their database.

The nice thing about AI, at least, is I can always push back and tell people, "Sure, we can do this with AI. I just need you to use Claude or ChatGPT manually to prototype how it would work." This normally results in the requestor realizing that there's human judgment calls involved in the inputs, process, or outputs that require meatbag intelligence.

Maybe it wasn't clear in my comment, but this was already happening in many large organizations pre-AI: you had a small contingent of competent senior developers whose job was to review and correct outputs from junior and/or outsourced staff. From people I've spoken to in these types of situations, they're very happy with getting rid of their offshore teams and using AI instead.

If you're a good dev, you can totally prompt Claude to not do this and correct itself, that's not an issue. The issue is that bad devs won't even notice this is happening in the first place.

If you're in a product company and your development backlog is empty, run. That company is about to go out of business.

Now the competent developer can just run agents and do the same review process, except it's ~free (relative to human salaries, even outsourced).

So we've got a bimodal distribution going on where the bottom X% of developers have become essentially worthless while the top Y% of developers are now more valuable than ever.

This is all predicated on true autonomous vehicles though, not the half-baked non-solutions that exist today.

ehhh. In my experience, being able to code is a necessary but not sufficient skill for a software developer. The only exceptions I've seen is having some extremely deep expertise in a niche technical field (and even then I wouldn't call that being able to code well, so much as technical domain knowledge).

When I was hiring at AWS the view for my team (RDS) was that there wasn't much difference in expectations between algorithmic coding ability for juniors and seniors. The primary technical differentiator for seniors was architectural and operational. But even more important than those was the nontechnical stuff; mentorship, being able to communicate ideas clearly and succinctly (no point in being able to architect a system if you can't communicate it in a way people understand), interacting with other teams, demonstrating understanding customer and business value, etc.

> AI consistently advised people to save during their working years, draw down savings in retirement, invest heavily in diversified stock funds, and reduce stock exposure after age 45.

This is analogous to saying to an aspiring software developer, "You should write clean and testable code, have clearly defined API boundaries, and a repeatable build process." All very true, but also so general and basic that it's not helpful.

It only takes Draftkings writing a very large check to Google before it responds to financial questions with solid advice before ending with, "Since you have a few spare hundred dollars laying around, why not try a high-risk investment into same-game parlays?"

1. Don't use a third-party auth provider, if you can't build out an OAuth provider in an afternoon you shouldn't be entrusted with login credentials

2. Don't use Github, if you can't build out an internal Gitlab instance in an afternoon you shouldn't be entrusted with securing source code

3. Don't use Github Actions or CircleCI, if you can't self-host a Jenkins server in an afternoon you shouldn't be entrusted with secure deployments

4. Don't use a lawyer or outsourced HR, if you can't draft legally binding employment agreement in an afternoon you shouldn't be entrusted with hiring people

Intelligence is being able to set up your own postgres database with backups, PITR, retention policies, HA/replicas, and everything else needed to prevent catastrophic data loss. Wisdom is realizing that's a solved problem completely unrelated to your business, so you don't have to.

> Use foreign keys with cascading deletes for low-volume tables, particularly where database consistency and correctness are important. Careful at higher volume.

This might be just me, but I hate cascades, for a very simple reason: at most places, the majority of developers "live" in the Python/Node/Go/whatever application that talks to the database, not the database itself. Cascading deletes (or updates) is basically magic and it can be very hard to understand "why did deleting a row from table A delete something from table B automatically". Especially if someone sets up the cascading wrong! IMO it's better for long-term maintainability to emit explicit delete clauses. Correct use of foreign keys will prevent any issues with database consistency.

> Tricks for large table migrations

The pitfalls and workarounds are all correct, but worth pointing out tooling already exists[0] for managing this for you. Making changes to large tables should be as simple as running a command (and then nervously monitoring for the next 24 hours as the data copies).

Other things to consider,

1. Get used to separating application and database deployments early. It is impossible to transactionally deploy both a schema change and an application change simultaneously, there will always be some delay where the versions of database and application are out of sync, and you will eventually run into a situation where the database change deploys fine but your application change does not. Once your app is in production, get in the habit of only doing backwards compatible schema changes: all new columns are nullable or have a default, no renaming of tables/columns, etc.

2. In the same vein, figure out a schema management strategy early. You really don't want your database deployment process to be "senior dev runs some DDL manually on production from his machine". I'm still partial to liquibase because it's the devil I know, but there's other tooling like Flyway which exists.

[0] https://github.com/shayonj/pg-osc

How is this even a direct comparison? Most companies I know of which use Kubernetes are using it on a cloud provider. Even if it's kubernetes on EC2 rather than hosted e.g. EKS, those companies are also happy to use lock-in services like RDS and S3.

Optional[T] is now T | None. Means exactly the same thing but doesn't require an import. Support for the older syntax presumably won't be removed for a long while regardless.