Why Devin AI can't take your job

Highlights: Devin AI debunked, unnecessary VS Code tools, and Fisher-Yates shuffle challenge

As cloud adoption increases to run modernized applications, costs can quickly rise out of control. How do best-in-class companies manage their storage spend while continuing to grow the business? Clumio, a cloud-native backup solution, depends on cloud storage to run their entire business. They took a FinOps approach to optimizing their costs, and reduced their AWS dev costs by over 50%.

Can you solve this coding puzzle?

We’ve made changes and fixes to Play. View updates.

Devin AI.

They claim it’s the silver bullet for all software creation, a miraculous tech outperforming every other AI model and handling real-world programming with ease.

With recent news of Nvidia CEO, Jensen Huang, confidently predicting the impending death of coding, surely this Devin AI thing must be the first nail to go in the coffin.

Mhmm.

Sounds suspiciously familiar... AutoGPT, anyone? GPT Engineer? LOL.

Oh no... before jumping on the bandwagon we need to take a closer look at the deception behind this supposed game-changer.

The first glaring issue is the lack of transparency surrounding Devin AI's performance metrics.

Sure, they claim it's superior, but how did they arrive at these numbers? And where's the proof? There's a conspicuous absence of generated source code to back up their claims.

Without this crucial evidence you can't take their word at face value.

Can Devin AI really make a meaningful impact in a real-world repository? Doubtful. And what about limitations? Not a word. It's as if they want us to believe Devin AI is flawless, without a single drawback.

Coding is already challenging enough; Nobody need contend with this:

So we need to keep this number as low as possible to minimize this resource usage; ad also stopping these extensions from clashing with one another or with native functionality.

When you add a new HTML tag, this feature automatically adds the corresponding closing tag.

Extensions for this

These extensions add the auto-closing feature to VSCode:

  • Auto Close Tag (12.3M+ downloads): "Automatically add HTML/XML close tag, same as Visual Studio IDE or Sublime Text".

  • Close HTML/XML Tag (344K downloads): "Quickly close last opened HTML/XML tag".

But feature already built in

I already use these settings to enable/disable the auto-closing of tags in VSCode:

  • HTML: Auto Closing Tags: "Enable/disable autoclosing of HTML tags". It is true by default.

  • JavaScript: Auto Closing Tags: "Enable/disable automatic closing of JSX tags". It is true by default.

  • TypeScript: Auto Closing Tags: "Enable/disable automatic closing of JSX tags". It is true by default.

Add the following to your settings.json file to turn them on:

Can we write the Fisher-Yates shuffling algorithm in a declarative and functional way with zero mutations, all in a single one-liner statement?!

Let’s find out.

Some time ago I was creating a small card game for Android and I needed to shuffle the cards before sharing them to the user and opponents.

Well I didn’t know about the standard shuffling algorithms, so after some thought I came up with this:

But after reading more about Fisher-Yates on Wikipedia, I discovered serious problems with my algorithm:

I was swapping each item with a random element in the range of 0..n, but this was wrong.

As explained here, this made it more likely for the array to get shuffled in particular ways.

The right way was to use the range 0..i to swap with the current element i in the loop.

With this I could make sure every possible shuffled result would have an equal chance of happening.

How exactly are we supposed to go about this?

Can we try this?👇

No we can't; We used ES6 swapping to shorten the code but we still mutated the array. And cloning doesn't count.

We need to figure out a way to swap the array elements immutably - create a new array with items swapped.

Thanks for taking the time to read today’s issue.

Don’t let the bugs byte,
Tari Ibaba