DEV Community: Bernard Wiesner

Does AI Really Make Developers 10x More Productive?

Bernard Wiesner — Tue, 29 Sep 2026 21:02:04 +0000

The trend is everywhere: AI has come for dev jobs and can now perform 10x or even 100x faster, according to some out there. This would mean reducing headcount, as a single dev could do the work of 10.

But is this really accurate? There seem to be two main trends right now:

1. Vibe coding with AI

Some companies are focusing heavily on speed and releasing new features without requiring devs to review code anymore. In fact, they are not encouraged to take the time to understand the code produced by LLMs. So the flow is:

Define the feature/specs
AI implements it
AI reviews it and fixes any issues
AI tests it
AI creates the PR
The dev might run some more reviews using AI on the PR, might test it locally, and finally clicks approve and merges

The dev never really looks at the code or tries to understand what AI did.

This workflow can truly boost performance for certain tasks, such as creating well-defined new features or releasing a brand-new product. However, it also has major trade-offs in the long run.

Yes, you might meet a very tight deadline to release this product, but can it really scale and grow in the long run? What happens when there is a production issue and you have no clue what AI wrote? What happens when AI can't seem to fix the production issue you are having, even after you pasted all the context you have, and it keeps failing to fix the issue? You have to dig into the code.

And here is where it bites you: you are not at all familiar with the thousands of lines of slop that were written. And I am not talking about a brand-new project. I am talking about a project that has been vibe coded over months, with new requirements built on top of each other over and over, often with features that might conflict with each other or quick fixes that haven't been addressed because no one is taking care of the health of the codebase. The focus was always on shipping fast and zero maintenance.

You could spend hours or even days trying to figure out how to bring your production system back up. This will only amplify over time. Your initial 10x or 100x boost is now greatly reduced by trying to figure out the system and understand why some logic was written in a way that makes absolutely no sense.

This reminds me of when I first started developing a website 20 years ago using Dreamweaver. I got started quickly, but had a hard time fixing issues when they arose, and looking at the code it produced was a huge pain. Of course, AI is at a different level, but there are similarities with vibe coding.

This could certainly improve over time. I could imagine AI monitoring the health of your whole system, being able to communicate with you about the system and its trade-offs while you create a new feature outside of your IDE or code, and proposing scaling changes, migrations, abstractions, or refactoring as needed. However, this might take some time to get right, as it introduces considerable risks.

2. AI-assisted, responsible coding

Others are following an AI-assisted and responsible coding approach, where you are expected to fully own and understand anything AI writes. This flow is much slower than the one above, initially at least, as you have to spend considerable time reviewing, correcting, or modifying AI-produced code to keep it maintainable and feel comfortable with it.

You are not fine with machine-looking code. You want to produce easy-to-understand code for humans that is maintainable by humans in the long run.

Even with very well-defined specs, when you are working on complex systems, there will always be decisions and trade-offs you have to make. Do I need to refactor this to add this new feature? Do I need to introduce a new pattern that was previously not there for this new spec? Does this need to scale? Does another feature need to be deprecated? Should this feature be abstracted into a microservice? Should I migrate certain data to handle the new spec better?

These kinds of judgment calls can't be made by AI alone. AI follows existing patterns and produces quick outcomes. Yes, for a well-built system, AI can really shine initially. It copies the patterns that exist and can quickly add new features on top of them. However, this is temporary. If you keep doing this without reviewing what AI is adding, even in well-built systems, over time it will start making wrong judgment calls on its own, which will add up over time.

You should certainly automate smaller tasks that you feel confident don't need too much review or design changes. I still view this as responsible coding, for example a flow such as:

Open Jira task
From Jira delegate to an agent to:
- Creates MR
- Reviews MR
- Tests MR with close to real data
Dev picks it up, reviews, test on local, approves and merges

So, how much more productive are we?

The question remains: how much more productive are you with AI? From experience, I would say it depends. For certain tasks, you are certainly much faster, such as boilerplate, setting up certain structures, or starting a new project from scratch. However, we need to be careful when measuring performance.

For example: "A bug is reported, and you are asked to investigate and fix it." You can simply paste in the bug description, and AI might have a fix for you very quickly. You push the changes, and it looks all good. However, you were not aware of why that bug surfaced in the first place or of all the related code and logic that surrounds it.

If you were to dig into the code, let's say for one hour, looking for the bug, you would learn a lot about the system and how it was built. You would make a mental map of the codebase and get familiar with a lot of the logic surrounding it, especially if it is readable and well built. You learn to debug logs, understand monitoring systems, and might learn about an unrelated bug in the process.

Later, in a meeting, someone asks about a certain spec. You immediately know it and are familiar with it, and can answer quickly without having to reach for AI to figure it out. You can very quickly debug issues and connect unrelated issues with what they could probably be caused by because you know the system. You are on top of it. If you have no clue, you have to reach out to AI every time and depend on it. This will slow you down over time.

Additionally, the skill of looking at code as live documentation, especially when it is well built and optimized for humans, is very valuable. You can very quickly understand specs by looking at code. Often, asking AI and reading what it says is slower when trying to understand specs. First, you are not 100% sure that what it is saying is really accurate, and second, you might take longer to really understand all the related logic and specs from the output it gives you compared with actually analyzing the code yourself.

Well-written code that is developed with great DX in mind is often more readable than reading about specs in plain English. This is certainly not true for messy code or low-level code with a lot of complexity. AI can be much more helpful for understanding those kinds of codebases.

It's tricky to measure performance with AI because you are measuring long-term versus short-term performance. In the short term, yes, certainly, you are probably a few times faster using AI. However, in the long term, are you really much faster?

If you are working on big, complex projects and are constantly reaching out to AI to figure out the system over and over again, you don't have a mental map of the codebase and need constant assistance. You might not be much faster than a dev who knows the ins and outs of the system and is not using AI at all.

However, if you do have a strong understanding of the codebase and are able to fix issues or add new features confidently without AI, you can certainly be much faster with AI assistance, as you can quickly identify related issues and review the code it changes because you are familiar with it.

It is a bit of a paradox because the more you start using AI, the more you start losing ownership of the codebase. Reviewing code doesn't create the same sense of ownership as writing code manually. It's much better than not reviewing it at all, but over time, you do start losing ownership of the codebase. Additionally, there is a risk of cognitive deskilling when you only review code and rely heavily on AI.

Personally, I would say the performance boost is somewhere around 2x with AI currently, nowhere near 10x and certainly not 100x. That is with AI-assisted, responsible coding. And even this 2x is questionable depending on what you are working on and whether you are measuring the long term or the short term.

I think many people right now are underestimating how fast devs could code manually. You were not literally typing every character. You often copy-pasted a lot of common patterns, mass-reassigned things with shortcuts, used IDE-assisted refactoring, and used autocomplete. I believe many people are underestimating how smart devs were and how much context you could absorb prior to AI.

Yes, AI is very impressive, but devs could do the same or more without hand-holding. I mean implementing a complex solution with zero bugs, with total comprehension of all affected parts and confidence in your solution. That skill is gradually fading in devs nowadays.

I believe AI certainly does boost performance, and everyone should use it. However, I also believe you should keep owning the code and, once in a while, not rely on AI to perform certain tasks, with the exception of autocomplete. Keeping your cognitive sharpness will later help you get more out of AI-assisted coding in the long run.

This is certainly true for bigger, more complex systems. For smaller, newer projects that just need a quick mockup and release, it's a different story. Do not spend too much time on it if you just need a quick release, vibe coding without properly reviewing the code can be perfectly fine here.

Laravel as a microservice using GCP PubSub, an alternative to laravel queue.

Bernard Wiesner — Thu, 15 Sep 2022 06:20:00 +0000

Laravel queue vs PubSub

Laravel queue is great and easy to use, however one big disadvantage is it's not microservice friendly. You need to couple your jobs with your app code and run your queue worker on the same repo.

For example lets say you have an e-commerce website and you want to process the payment in the background and then sent an email to the user if the payment was successful. You would need to write your job inside the same repo as your web app, and when you deploy to production, you would need to deploy both your web app and your batch server that is running the queue worker with the same repo code.

The above use case has various issues. Your web app code is tightly coupled to your background processing jobs. If you make some changes to your job it will add risks to your web app release since its in the same repo.

By using pubsub we can introduce a scalable microservice architecture that can solve above issues. Lets look how to implement this.

What is PubSub?

PubSub is a design pattern related to publisher and subscribers. You can publish to a topic and all subscribers that are listening on that topic will triggered. As an example:

topic: purchase-submitted
1. subscription: send-processing-email
2. subscription: charge-user

As you can see from above the topic purchase-submitted will be published from your web app when a user completes a purchase. There are 2 subscriptions subscribed to that topic, they will both get triggered at the time of publishing to the topic. First, is sending an email notifying the user their purchase is being processed. The second subscription will attempt to charge the user and if successful will send a purchase complete email. The subscriptions will get processed on a separate repo, we can call it a PubSub API repo.

Let's see how we setup this architecture using laravel.

GCP PubSub configuration

You need to have a GCP account and configure your topics and subscriptions on PubSub.

First create a topic:

Then create the subscriptions and link them to the topic above:

Configure your subscription as push and enter your PubSub API endpoint (your laravel dedicated repo to process subscriptions):

You can configure additional options for your subscription, such as the acknowledge deadline and retry policy based on your preference or leave it as defaults.

Web app code

For publishing messages to GCP, you can use GCP's PubSub for PHP library, or you can use my library that acts as a wrapper around GCP's library. The benefit of my library is it provides a clean fluent API and allows you to easily mock and test your PubSub logic.

I will be using my library in this tutorial. Install it by doing:

composer require bernardwiesner/laravel-gcp-pubsub

Then you can simply publish to your topic from your app code when a user submits a purchase request:

    use PubSub;
    // ...
    PubSub::topic('purchase-submitted')
    ->publish(['purchase_id' => $purchaseId]);

That is all you need to do on your web app code. There is no need to have any of the purchase logic or email sending logic. That will all be on your PubSub API on a different repo.

PubSub API

You need to create a new repo that acts as an API. This API will be triggered by GCP pubsub when you publish to a topic.

Simply create your API endpoints inside api.php with the endpoint of your subscription as configured on GCP:

Route::post('/pubsub/send-processing-email', SendProcessingEmail::class);

Then inside your controller you can process the jobs:

class SendProcessingEmail extends Controller
{
       public function __invoke(Request $request): HttpResponse
    {
        $message = $request->message;
        $data = json_decode(base64_decode($message['data']), true);
        $purchaseId = $data['purchase_id'];
         // your email sending logic

        return response()->noContent(204);
    }
}

As you see above its required to base64 decode the message data, this is a requirement of GCP pubsub. Also on the last line a successful response code needs to be send back to GCP to mark the message as processed. If you do not respond with a success response code and the acknowledge deadline you configured on your subscription expires, the same message will be send again from GCP and your job will be triggered again until it succeeds.

For example, if you configured your acknowledge deadline as 10 seconds on your subscription, but your API for sending an email takes more than 10 seconds, your API will be called again from GCP. To avoid duplicate jobs make sure you configure your ack deadline on GCP pubsub with a reasonable time. Alternatively you could kill your php script if it passes over a certain time, for example:

    protected function registerTimeout(): void
    {
        pcntl_async_signals(true);
        pcntl_signal(SIGALRM, function () {
            posix_kill(getmypid(), SIGKILL);
        });
        pcntl_alarm(10);
    }

The above code will kill your request if it takes more than 10 seconds, making sure you dont send an email twice. You should match your timeouts on php side with GCP side to avoid duplicate messages.

Delay messages

In laravel queue you can delay jobs, this is more tricky using GCP pubsub since the way pubsub works is it triggers all subscriptions at the moment you publish to the topic. However there are some workaround to this.

Using my library, you can use the delaySeconds() API to delay the processing of the job. This will add an additional attribute to the payload called available_at with the time the job is available to be processed:

    use PubSub;
    // ...
    PubSub::topic('your-topic')
    ->delaySeconds(30)
    ->publish(['your data'], [
        "your-attribute" => "your-value"
    ]);

Then you need to add a middleware to your PubSub API repo to delay the job if its not yet ready by returning a non success response code:

    public function handle(Request $request, Closure $next)
    {
        $availableAt = (int) ($request->message['attributes']['available_at'] ?? 0);
        if ($availableAt > time()) {
            return response()->noContent(409);
        }
        return $next($request);
    }

The subscription will be triggered again until the available_at is met and the API returns a success response code.

Conclusion

By using GCP PubSub and a dedicated laravel API for processing jobs you can scale your jobs and benefit from a microservice architecture.

Additionally you can add additional subscriptions to your topic and configure the push endpoints to any external API you might have, be it laravel or any other language. This is great for decoupling and scaling.

JS array vs object vs map

Bernard Wiesner — Tue, 04 Aug 2020 07:20:55 +0000

Like other programming languages, JS has data structures, such as arrays and maps. Maps are key pair entries or associative arrays however maps can cause confusing in JS, lets first take a look at using an arrays as a map:

let students = []
students[0] = 'Mark'
students[1] = 'Mia'

console.log(students)

If we check the contents of the students array we get this:

Now lets take a look at an object:

let students = {}
students[0] = 'Mark'
students[1] = 'Mia'

console.log(students)

Lets check the contents of the object:

Looks almost same as the array, both have key pairs. Lets mix things up a little, lets say our keys are dynamic and we want to access the value of the student by its id. Lets do this with an array:

let students = []
students[0] = 'Mark'
students[10] = 'Mia'

console.log(students.length)
// 11

Wait what? There are 11 students? Since we are using array indexes as dynamic keys this is causing empty slots.

If we would loop and console log every student, we would get this:

for(student of students){
  console.log(student)
}

9 undefined entries, this could cause a lot of issues related to performance and integrity. So we should not use arrays with dynamic keys, having empty slots is not good. Another reason to not use arrays as maps is that you cant assign non numeric indexes on arrays as keys.

Lets do the same with an object:

let students = {}
students[0] = 'Mark'
students[10] = 'Mia'

console.log(Object.keys(students).length)
// 2

Works fine, only 2 entries, no more empty slots and now we can access the student directly by its id:

console.log(students[10])
// Mia

However what happens when we invert the order of the ids?

let students = {}
students[10] = 'Mia'
students[0] = 'Mark'

console.log(students)
// Object { 0: "Mark", 10: "Mia" }

Oh, the insertion order isn't maintained in the object. It seems like they are getting sorted numerically. Ok, so lets use strings.

let students = {}
students['10'] = 'Mia'
students['0'] = 'Mark'

console.log(students)
// Object { 0: "Mark", 10: "Mia" }

Same result... What about if we use alphabetic characters will they get sorted?

let students = {}
students['key-10'] = 'Mia'
students['key-0'] = 'Mark'

console.log(students)
// Object { "key-10": "Mia", "key-0": "Mark" }

Oh, they didn't get sorted this time. So if we use non numeric characters the insertion order is kept.

In JS there exist 2 different types of maps, maps related to regular objects and maps related to the Map object.

Lets take a look at the new Map object in JS introduced in ES6.

let students = new Map()
students.set(10, 'Mia') 
students.set(0, 'Mark') 

console.log(students)
// Map { 10 → "Mia", 0 → "Mark" }

Oh the insertion order was preserved. We can also access the id of the student directly.

console.log(students.get(10))
// Mia

So what to take from this?

Dont use JS arrays as a map or associative array.
If you need to access a value by key and don't care about insertion order, you can go with a regular object.
If you care about insertion order go with a Map object.

Beware, ES6 Map object may not work with certain things such as v-for in vue 2.