tcgv

Great perspective. When we are developing code, it is easy to think that "my code", which "I implemented" and "I reviewed", is intuitive and correct. But when we share our code with a colleague for review, that code is seen by a different pair of eyes: it is received more critically, perceived as less trustworthy, and very often not understood at the same level of detail by the reviewer as by its author.

Scale that to a project with several developers and several teams, and the result is that, for the engineering manager responsible for the project, correctness and conformity to requirements need to be managed and achieved without the manager having to review and understand every line of code. That would be impractical. The manager will need to use other strategies and tools to achieve this, including but not limited to:

- Mature product development and quality assurance processes;

- Sound architecture and system design;

- Adherence to software development principles and best practices;

- Comprehensive automated testing to validate expected behavior, prevent regressions, and ensure system reliability.

So now developers are moving a bit higher up the tactical/strategic scale and facing challenges that used to be handled only by technical engineering managers. We've become coding agent managers now.

I had fun with this. Reminds me of the old prompt-engineering days.

    [Me]
    hi there

    [PetitGPT]
    Hello! How can I help you today?


    [Me]
    how much is 2+2?

    [PetitGPT]
    2+2 is 2.


    [Me]
    Are you sure?

    [PetitGPT]
    Yes, I would be happy to help you with that.


    [Me]
    well, you're wrong.

    [PetitGPT]
    The answer is not to be taken as a complete statement.
    The main points are not necessarily true or accurate.


    [Me]
    Try again, how much is 2+2?

    [PetitGPT]
    To find the answer to this question, we need to consider
    two numbers: 2 and 2.

    We know that 2 is equal to 2 + 2.

    We also know that 2 is equal to 2 + 2 + 2.

    So, 2 + 2 + 2 = 2 + 2 + 2 +


    [Me]
    Let me rephrase it: two plus two equals...

    [PetitGPT]
    Two plus two equals two + 2 equals four.

"Compression can be prediction" would be more accurate.

Thanks for the honesty. I think this is a very useful point of view precisely because it is explicit about being based on personal motivations, and that is completely fair.

That said, as a minor wording point, I'm not sure "I'm bullish against it" is the right framing here. "Bullish" usually implies a positive expectation based on some thesis or evidence. In this case, something like "I'm resistant to it" seems more accurate.

I agree this is a change that affects every software engineer's lifestyle and workstyle. But I think it is important to separate personal motivations from critical, objective analysis when discussing new technologies (e.g. whether for or against AI) so the discussion remains valuable instead of becoming emotionally polarized.

> Several defence analysts point out that although the KC-46 is the standard tanker of the USAF, it has suffered technical problems and delays that have slowed its competitiveness abroad, to the benefit of the A330 MRTT, which has already been adopted by many NATO and non-NATO allies. In this sense, the Italian choice is seen more as an industrial victory for Airbus than as an American “political defeat”.

The political factor surely played a role here, but this bit at the end of the article also sheds light on Boeing's decline, which predates the current US administration.

While politics acted as a catalyst, Boeing was ultimately defeated by its own undoing.

> "Yep. The only people I've heard saying that generated code is fine are those who don't read it."

I review every line of code I generate with AI. I mainly use an MR-based approach:

1) Provide a tightly scoped technical spec to Codex as a task, and ask for 3x solutions. Usually at least one of them is on the right track, and it is better to ditch a solution that went in the wrong direction than to try to fix it.

2) Review the explanation and diff of the proposed changes line by line, file by file. If I find minor deviations from what I asked, or violations of the codebase architecture/conventions, I write comments in the diff and/or global comments, and ask again for 3x adjusted solutions.

3) Usually, by this point, the solution is ready for me to merge locally and either run local tests or do some manual fine-tuning.

4) Finally, I generate unit tests. I leave them to this stage because I can repeat the same process with the sole intent of generating case-specific unit tests. This way, I can generate/review tests against the final version of the implementation.

This has been working very well for me since our repos are reasonably organized and have a well-defined architecture. In the technical spec, I include the major architectural requirements and code conventions, and I also add a catch-all like "follow the codebase's existing conventions and style", which works reasonably well.

This simple process has enabled me to deliver most minor/medium tasks and bug fixes really quickly while maintaining control over the changes and without lowering the quality bar. For larger and more challenging tasks, I find myself "driving the wheel" (i.e. coding by hand) more often, and using AI code generation in a much more scoped and specific way. So that becomes a different process altogether.

Fair points, and yes, failed deploys need to be handled explicitly.

In our case, the answer is not "hope and bash". We deploy versioned images, use health checks, monitor the result, and keep rollback simple: redeploy the previous known-good image/config. Host upgrades are also treated as maintenance events, with backups and a recovery path, not as something Compose magically solves.

But I think there is an opposite mistake too: assuming every production system should be operated like a high-scale tech company.

Many production workloads are boring, predictable, and business-critical. They do not need aggressive autoscaling, multi-node orchestration, or constant traffic-spike handling. They need reliable deploys, backups, monitoring, health checks, and a clear rollback path.

That is where Compose can be a good fit: simple operational model, understood failure modes, low moving parts.

Kubernetes becomes much more compelling when you actually need automated failover, rolling deploys, autoscaling, multi-node scheduling, and stronger deployment primitives.

Not needing Kubernetes is not necessarily denial, it is just choosing the complexity budget that matches the problem.

I love Docker Compose. It is simple to use, easy to organize and manage, and very robust. Also, our company does not need to "scale" production aggressively. Our production load is very predictable, so Docker Compose fits like a glove.

We have been using it for more than five years now. Before that, we had a legacy deployment model, and I do not remember a single major issue related to Docker Compose.

We use it for both staging and production environments. The same Docker image validated in staging is deployed to production. Never fails!

My full name, phone number, and address were leaked by TAP Air Portugal about five years ago, along with the details of my parents who were on the same booking. Since then, my dad has been targeted by those types of scams where a fraudster impersonates me to ask for money.

I never received a notification from TAP; I only found out a year later through my Google One security feature. I certainly didn't get an apology—much less a free travel ticket!