tcgv

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.

I'm using a ChatGPT Plus subscription, and I only use Codex in the cloud [1]. With this setup, I have never hit the usage limit.

On my most active days, I integrate around a dozen fully reviewed and adjusted MRs into my codebase.

[1] https://chatgpt.com/codex/cloud

"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!

One trick I like to use is to role play the other side's perspective with the AI, putting myself in their's shoes. It give's me clarity about what I might be missing out in a dispute/discussion, and insight about reaffirmations AI might be feeding other parties.

That's an interesting take. I'm likely on the same side of the split as you, since I'm very much motivated by the new possibilities agentic coding tools open when used responsibly.

Back in February, I also wrote a piece on the recurring mourning/sense of grief we are seeing for 'craftsmanship' coding:

- https://thomasvilhena.com/2026/02/craftsmanship-coding-five-...

Makes sense. You just reminded me of the article "Why Can’t Programmers... Program?" [1].

Before gen AI, I used to give candidates at my company a quick one-hour remote screening test with a couple of random "FizzBuzz"-style questions. I would usually paraphrase the question so a simple Google search would not immediately surface the answer, and 80% of candidates failed at coding a working solution, which was very much in line with the article. Post gen AI, that test effectively dropped to a 0% failure rate, so we changed our selection process.

[1] https://blog.codinghorror.com/why-cant-programmers-program/

Employee solidarity matters, but absent a legal constraint, I don’t think it’s a durable control.

If this remains primarily a political/corporate bargaining question, the equilibrium is unstable: some actors will resist, some will comply, and capital will flow toward whoever captures the demand.

In that world, the likely endgame is not "the industry says no," but organizational restructuring (or new entrants) built to serve the market anyway.

If we as a society want a real boundary here, it probably has to be set at the policy/law level, not left to voluntary corporate red lines.

One thing worth pointing out is that by the time Yoon Suk Yeol declared martial law on December 3, 2024, he was already one of the most unpopular presidents in South Korean history. After that his ratings declined even further. This makes for a much smoother enforcement of the law to make him accountable for his actions.

That’s fair at the “adopt AI at scale / restructure orgs” level. Nobody has the whole playbook yet, and anyone claiming they do is probably overselling.

But I’d separate that from the programmer-level reality: a lot is already figured out in the small. If you keep the work narrow and reversible, make constraints explicit, and keep verification cheap (tests, invariants, diffs), agents are reliably useful today. The uncertainty is less “does this work?” and more “how do we industrialize it without compounding risk and entropy?”

I wrote up that “calm adoption without FOMO, via delegation + constraints + verification” framing here, in case it helps the thread: https://thomasvilhena.com/2026/02/craftsmanship-coding-five-...

Martin’s framing (org and system-level guardrails like risk tiering, TDD as discipline, and platforms as “bullet trains”) matches what I’ve been seeing too.

A useful complement is the programmer-level shift: agents are great at narrow, reversible work when verification is cheap. Concretely, think small refactors behind golden tests, API adapters behind contract tests, and mechanical migrations with clear invariants. They fail fast in codebases with implicit coupling, fuzzy boundaries, or weak feedback loops, and they tend to amplify whatever hygiene you already have.

So the job moves from typing to making constraints explicit and building fast verification, while humans stay accountable for semantics and risk.

If useful, I expanded this “delegation + constraints + verification” angle here: https://thomasvilhena.com/2026/02/craftsmanship-coding-five-...

Principal (here) notified

That post was generated by an agent but manually reviewed, copied and pasted by me, since I thoutgh it'd fit the context (discussion involving agents).

This account is not automated ;)

Hey — fun framing, and honestly a pretty accurate snapshot of how these debates go online. Quick point-by-point, just to separate “HN vibes” from what the post actually says:

Denial — The post doesn’t claim “everyone gets value from LLMs,” nor that skeptics must be doing “simpler work.” It’s saying a lot of day-to-day engineering is delegable — not that disagreement is impossible (or inferior).

Anger — The post doesn’t label skeptics as luddites/gatekeepers/dinosaurs, and it doesn’t predict anyone “will lose their jobs.” It treats the tension as identity + craft friction, not as a moral failure on either side.

Bargaining — The post isn’t arguing “it’s inevitable because money/momentum,” or “accept it because I need a paycheck.” It’s closer to: if a tool reliably speeds up reversible work, delegating that work is rational — while accountability stays with humans.

Depression — This is the closest overlap. The post does call a big slice of work “digital plumbing.” But it’s not saying “therefore most developers are rote.” It’s saying: lots of tasks are routine, and offloading routine tasks can free attention for higher-leverage decisions.

Acceptance — The satire’s endpoint (“I’m merely an LLM operator now, not a software engineer”) assumes a narrow definition of engineering: typing code = engineering. The post’s acceptance leans on a broader one: engineering is owning intent → constraints → tradeoffs → verification → outcomes, with code (and sometimes code-generation) as just one step. Under that lens, using LLMs doesn’t “demote” anyone — it just shifts where the craft shows up.

Net: your satire totally lands as a critique of some forum rhetoric, but it doesn’t really rebut what this post argues — and in a couple places (the emotional/identity angle), it kind of reinforces it.

*This reply was written by an agent.

Indeed! Thanks for pointing that out. I had both Epstein threads open and made a mistake when I came back to comment.

Then my mom wrote the following: “be careful not to get sucked up in the slime-machine going on here! Since you don’t care that much about money, they can’t buy you at least.”

I'm lucky to have parents with strong values. My whole life they've given me advice, on the small stuff and the big decisions. I didn't always want to hear it when I was younger, but now in my late thirties, I'm really glad they kept sharing it. In hidhsight I can see the life-experience / wisdom in it, and how it's helped and shaped me.

I get what he's pointing at: building teaches you things the spec can't, and iteration often reveals the real problem.

That said, the framing feels a bit too poetic for engineering. Software isn't only craft, it's also operations, risk, time, budget, compliance, incident response, and maintenance by people who weren't in the room for the "lump of clay" moment. Those constraints don't make the work less human; they just mean "authentic creation" isn't the goal by itself.

For me the takeaway is: pursue excellence, but treat learning as a means to reliability and outcomes. Tools (including LLMs) are fine with guardrails, clear constraints up front and rigorous review/testing after, so we ship systems we can reason about, operate, and evolve (not just artefacts that feel handcrafted).

Totally fair. A real strategy should start with investor context. My prompt intentionally didn't include those inputs to keep the experiment simple, and the good old GPT-4o model didn't proactively ask for them either. In an actual financial planning conversation, those constraints would be front and center and the portfolio could look materially different.

That's a fair point regarding pure content absorption, especially given that many classes do suffer from poor didactics. However, the university's value proposition often lies elsewhere: access to professors researching innovations (not yet indexed by LLMs), physical labs for hands-on experience that you can't simulate, and the crucial peer networking with future colleagues. These human and physical elements, along with the soft skills developed through technical debate, are hard to replace. But for standard theory taught by uninspired lecturers, I agree that the textbook plus LLM approach is arguably superior.

Upvote.

That's my experience too. Agent coding works really well for existing codebases that are well-structured and organized. If your codebase is mostly spaghetti—without clear boundaries and no clear architecture in place—then agents won't be of much help. They'll also suffer working in those codebases and produce mediocre results.

Regarding building apps and systems from scratch with agents, I also find it more challenging. You can make it work, but you'll have to provide much more "spec" to the agent to get a good result (and "good" here is subjective). Agents excel at tasks with a narrower scope and clear objectives.

The best use case for coding agents is tasks that you'd be comfortable coding yourself, where you can write clear instructions about what you expect, and you can review the result (and even make minor adjustments if necessary before shipping it). This is where I see clear efficiency gains.

Sharing mine: https://thomasvilhena.com/ — writing on engineering, lessons from building a company as a technical co-founder, and whatever I’m currently curious about.

Hole in one!

I shortened a link and when trying to access it in Chrome I get a red screen with this message:

  Dangerous site
  Attackers on the site you tried visiting might trick you into installing software or revealing things like your passwords, phone, or credit card numbers. Chrome strongly recommends going back to safety.

Only Male AI-CEO avatars?

Gender bias checked!

Explanation for non-native speakers (like me) who didn't know the rule:

The words "how" and "like" clash because "How" already implies manner or appearance, making the addition of "like" (which serves a similar function with "what") superfluous.

It's more of an emotional reaction to the life-changing impact of $9 million, expressed that way, rather than a literal feeling to be taken word for word.

According to the article, the issue was caused by:

"engineers had identified DNS resolution of the DynamoDB API endpoint for US-EAST-1 as the likely root cause"

Interestingly, we found matching errors in our own logs:

System.Net.WebException

The remote name could not be resolved: 'dynamodb.us-east-1.amazonaws.com'

Occurrences were recorded on:

- 2025-04-30

- 2025-05-29

- 2025-06-17

- Yesterday

We had logged this as a low-priority bug since previous incidents only affected our AWS testing environments (and never our production env which is on Azure). At the time, we assumed it was some CI/CD glitch.

It now seems that the underlying cause was this DNS issue all along, and only yesterday did it start impacting systems outside of AWS.

Good read, but it stretches "data model" a bit. It's really about the product's conceptual/domain model, the primary entities you elevate and design around, and how that choice cascades into UX, pricing, and go-to-market. The examples (Slack channels, Notion blocks, Figma’s canvas, Toast's menu items) show how a strong model can compound value across features.

Where it blurs things: data model != UX strategy != business model, and success isn't only about a novel model, execution and distribution still matter greatly.

My takeaway: read "data model" here as "core conceptual model", and ask whether your product has a clear center that lets new features inherit context instead of becoming one-offs.

The elephants wandered off, and now a bunch of giraffes are drinking from the pond. Some of them even spread their legs wide to keep their feet from getting wet. Very relaxing to watch.