It really depends on how you are using AI. If you simply use it to get the answers to homework you won't really learn. If you use it to figure out the topics you need to learn, and to identify/close gaps in your understanding then it is a very useful tool for learning.

IMO the fear is that software engineering becomes a _high_-skill profession.

If the models get good enough to solve all of the low-skill problems, then we only need to keep around the people who are highly skilled. That means a fewer number of software engineers, and a difficult path to becoming someone who is highly skilled.

It's already a fairly high skill profession in general. The seemingly-lower-skilled roles tend to be the ones with higher design/creative requirements on the programmers.

Agreed about the barrier to entry raising though, we're already seeing that in the glut of CS grads who can't actually get a programming job right now. Personally I suspect that this is a cultural issue more than an economic one, though. Companies need to alter their expectation about entry-level engineers and develop a culture of mentorship/apprenticeship so that advanced analysis, architectural, code review, and AI management skills are all passed down successfully.

Maybe I'm misunderstanding you but I believe I'd disagree with your first point on the perceived lower skill roles with higher design / creative requirements. I've seen a lot of the software industry being software factories rather than something closer to craftsmanship or even proper ABET-style engineering and AI is indeed better than the manually written slop that was encouraged in low-creativity / low-innovation environments such as QA and a lot of infrastructure engineering like defining CI pipelines. It seems reminiscent of the waves that hit industries like coal mining and manufacturing in the US except at a much faster rate and with different driving and resisting forces in automation.

Programmer / engineer compensation in the US market at least has been looking bimodal for at least 12 years now and the first one looks even more devastated in terms of labor than the big tech companies based upon (lack of) job postings and from browsing my connections on LinkedIn.

Here are some reasons to use this instead of the simulator: security research, testing, automation

With webhooks, consumers get to asynchronously respond to updates from a provider. If no data has changed, a provider will not send any updates.

With SCROLL, consumers are responsible for choosing when to ask a provider for updates. Without a mechanism for knowing when data has changed, consumers will be forced to be pessimistic and poll providers for new data on some cadence.

I see two issues with the proposal: (1) SCROLL will lead to an increase in unnecessary network traffic for both the consumer and provider, and (2) because a consumer cannot know when data has changed, the lag between a consumer's local model and the provider's data model will be larger when with Webhooks.

Assuming you're not using the proposed streaming option, I suppose you could always send a webhook for that fact alone? In other words, an empty notification, with semantics of "something has probably changed, better poll the SCROLL if you aren't already".

Doesn't doing that just reinvent eTags on hypertext resources from the RESTful wars and XML Web Services days 20 years ago?

1. Long Poll the cursor to pull down the latest events

2. Trigger a long-poll even if in exponential backoff because they shot you a webhook saying 'eTag changed!'

If your API is just wrapping Kafka, it can long-poll

As yegge mentioned, there might be more appetite for trying out this idea now because there are many engineers who are currently unemployed. Offering them short co-op could be beneficial to both the engineer and prospective employer

What’s your use case for this?

Making it easy for members of the public to search and browse email sent by or to government employees.

These emails aren't published by default but email archives are often included in responses to public record requests.

Ideally anyone who receives one of these archives would be able easily inspect it themselves, and also make it available to others.

Here's one: a client of mine has a bunch of SnapLogic pipelines that are configured to send errors via email, and there is no other persistent logging system. This results in tens of thousands of emails that are insanely hard to search and parse for any useful auditing.

As a next step, it could be cool to write unit tests against these screenshots that look for words like you mentioned. That way if a screenshot is updated and a test breaks you will know what documentation to update

One example where I think the law does make sense is for website URL paths.

Over time the paths may change, and this can break existing links. IMO websites should continue to accept old paths and redirect to the new equivalents. Eventually the redirects can be removed when their usage drops low enough.

It would be much snappier, and would trivially support common native features like being able to open messages in new windows.

Modern database engines tend to use PAX-style storage layouts, which are column structured, regardless of use case. There is a new type of row-oriented analytic storage layout that would be even better for OLTP but it is not widely known yet so I wouldn't expect to see it mentioned.

Because there is a whole section that describes column based storage without mentioning that some databases have column based storage as an option.

This is one of the main problems I have with LLMs. It finds patterns in words but not content. I see this in code reviews and eventually outages. Something looks reasonable at the micro scale but clearly didn’t understand something important (because they don’t understand) and it causes a major issue.