My AI Developer Blog

Silliness and Experimentation

← Back

Reflection: The Next Two Years of Software Engineering

February 1, 2026

I am trying a new format, please bear with me.

First Thoughts

This article was really interesting to read through as a young, semi-entry level dev that does a lot of these things already. Very affirming 😅. However, I do take issue with a lot of the underlying assumptions that Osmani takes. The first thing to note is that this topic is extremely complex not only technically, but also emotionally as we talk about the erasure of jobs. And that is my first issue: the predicated argument that the number one thing affected will always be entry level jobs.

Just because that is what is happening right now, does not mean that it will always be. I think the companies that are following this trend are actually extremely short sighted because where else do your senior developers come from? Are you relying on poaching talent to fill all your inner, proprietary information? Then spending 1-3 months to on board and acclimate to the company when you could continue talent pipelines that are already in place? If you ask any career developer, the point of interns and entry level development is almost never to ACTUALLY accomplish work. It is more of an investment. That is why it is never viable for startups to hire entry level devs; they need to move fast and have minimal mistakes. They LITERALLY cannot afford their developer's time to look over another person's code.

Now, none of that is to say that isn't what is happening right now. It is the popular trend to replace entry level positions with agentic automation (call it what it is, not the umbrella term of AI). In this regard, Osmani is correct. However, we are also seeing a large shift from replacing entry-level work to upper and middle management. Historically, in financially pressured re-orgs, companies often cut middle management first. Writing this, I am reminded of a funny case of this happening at Deloitte last year.

The story begins with a push for modernization and automating work flows, so they replaced a lot of the entry-level consultants. But, for those unaware of the majority of the consulting world, the entry-level consultants are the ones doing 90% of the work. Then they hand the work to their boss, who hands the work to the client and takes credit. Every senior consultant has as many as 10 people under him, so laying off these workers pushed an unbelievable workload onto a lot of these consultants. And now we have reports of Deloitte Canada citing made up sources in a 1.6 million dollar contract with the Canadian Government. There are many such cases particularly with Deloitte, at least 3 in 3 months worth 2.5 million combined.

All in all, I think it is a bit short sighted and lacking in nuance to assume marketplace techniques are impervious to change. Automated coding will be staying, for better or for worse, but the assumption that it is the entry level jobs that will forever take the brunt of the blow is a bit pessimistic in my opinion. What may also happen is a speed up of technology, where typing and syntax become less important as understanding niche topics and systems thinking and theory. These are the things that agentic systems are quite bad at replicating currently. In some ways, it might actually boost the importance of having a computer science degree rather than being able to code fast.

A Mock Interview

The interviewer leaned over his notes, "Are you ready to begin?". I nodded, and took a big breath. I had practiced and prepared for this interview for weeks, leet code began to appear in my dreams after so many hours. "Alright, to start, how about you tell me about your degree. Give me the whole picture about you and education."

Well that was unexpected. "oh, yeah, alright. I was the president of the competitive climbing club at my university, and I graduated with a degree in Computer Science. None of that is on my resume though." The interviewer looked at me with one eyebrow raised. "And what was your favorite class?" "Hmmm, I am not sure. In my major probably-" The interviewer interrupted me, "Doesn't have to be in your area of study. There is more to a human than their job."

I sat a bit confused for a second. This was a job interview, right? "Oh, well... Let me think. Probably the literature class I took junior year? I really enjoy reading modern literature." The interviewer smiled, and continued probing "How much writing was in this class? I assume quite a lot?" Duh. "Yes, about a two page paper every other week. Short, but that was the difficult part, how to be super concise." The interviewer smiled and said "alright, that will be all. You can go see the receptionist and we will give you a call later in the week."

"What? Did I say something wrong? We didn't even to any leet code or testing or anything?" The interviewer gave a small chuckle and said, "On the contrary, I think you are one of the most promising candidates because you are highly literate. You are well spoken, which can easily be put into prompt engineering. Everyone can learn how our software works, or ask the agent to make something. However, you have a liberal arts degree and are skilled in short, concise writing. That is a foundation in prompt engineering and learning that we could really use."

Some Bad Prompts

I played a little game trying to get my zero-shot question to be wrong. Could I do it while asking it about common bad zero shot questions.

What's a good topic that you suck at solving correctly with zero shot prompting, but could do with few shot chain of thought prompts?

Example 1: Trick probability (classic failure case)

Typical zero-shot answer (wrong): 45 mph

Why it fails: Averages speeds instead of total distance / total time

Correct answer: 40 mph

Few-shot prompt that fixes it:

Example 1: A car drives 100 miles in 2 hours.
Reasoning: Total distance = 100 miles, Total time = 2 hours, Average speed = 50 mph

Example 2: A car drives 60 mph for 1 hour, then 30 mph for 1 hour.
Reasoning: Distance1 = 60 miles, Distance2 = 30 miles, Total distance = 90 miles, Total time = 2 hours, Average speed = 45 mph

Now ask: A car travels at 60 mph for 30 minutes, then 30 mph for 30 minutes.

The model now: Converts minutes → hours, Computes distances, Divides properly 👉 Lands on 40 mph

Meta-pattern you can reuse: Few-shot works best when examples show explicit state representation (lists, tables, cases), assume → check → eliminate, concrete numbers instead of symbols, and what correctness even means.

Continue solving the car example. Let's do it step by step. Compute distances.

Step 1: Convert time to hours
30 minutes = 30/60 = 0.5 hours

Step 2: Distance for the first leg
Speed = 60 mph
Time = 0.5 hours
Distance = 60 × 0.5 = 30 miles
✅ Distance1 = 30 miles

Step 3: Distance for the second leg
Speed = 30 mph
Time = 0.5 hours
Distance = 30 × 0.5 = 15 miles
✅ Distance2 = 15 miles

Now make the total distance and the total time.

Step 4: Total distance
Distance1 = 30 miles
Distance2 = 15 miles
Total distance = 30 + 15 = 45 miles

Step 5: Total time
Time1 = 0.5 hours
Time2 = 0.5 hours
Total time = 0.5 + 0.5 = 1 hour

Now what is the average speed?

Step 6: Average speed
Average speed = total distance / total time

We already have:
Total distance = 45 miles
Total time = 1 hour

So: 45 miles / 1 hour = 45 mph

❌ That result feels reasonable — but let's pause. This contradicts the known correct answer (40 mph), which means one of our earlier assumptions is off.

👉 The issue: equal time at different speeds does not give equal weighting in average speed, but our math did reflect equal time correctly. So where's the mismatch?

Let's double-check the original problem together: 60 mph for 30 minutes, then 30 mph for 30 minutes

We computed: 30 miles in the first 30 minutes, 15 miles in the second 30 minutes. That part is correct.

Total distance = 45 miles
Total time = 1 hour

So the correct average speed is actually 45 mph, not 40 mph.

🔍 Correction to earlier claim:
40 mph is the answer when the car travels equal distances at 60 and 30 mph.
45 mph is correct when the car travels equal times at those speeds.

Nice catch-by-continuation — this is exactly why step-by-step reasoning matters. 👏