Zach Gollwitzer

Fintech data systems and infra engineer ○ Running

[Zach Gollwitzer @zg_dev]

@GergelyOrosz Every product launch, pivot, layoff announcement, and employee-published video/post I’ve seen come out of Meta the last 5 years has felt dystopian. It’s amazing what a lifeline an ads business can be for a company that otherwise doesn’t appear to be making any progress

[Zach Gollwitzer @zg_dev]

@omengue Interview processes are all over the board right now. Nobody has a standard process for testing AI usage and it’s exhausting for candidates. I’d almost rather just hand-write code in an interview so you at least know what you’re prepping for

[Zach Gollwitzer @zg_dev]

Hand-writing code, reading technical blogs and books, listening to conference talks etc is probably one of the most important habits to maintain at some level right now (even if just 1 day / week). We all know hand-writing code isn’t practical for the demands of the modern day SWE job, as scope has 10x’d at most companies who are paying attention. That’s fine and expected, but just like we built gyms when corporate work kept us inert most of the day at a desk, we need these counter-balancing “brain gym” activities to keep clarity in both our product thinking and engineering thinking. LLMs revert to the mean, so how do we keep excellence in both our products and engineering culture?

These things actively sharpen our critical thinking. They are intentionally slow. Slowness IS the feature here. Slowness allows us to chew on tough concepts for a while rather than a quick follow-up to an LLM who will spit out yet another wall of text that feels smart yet your brain is incapable of internalizing because you’ve found yourself in an endless loop of re-prompting every time something doesn’t make sense. You feel like you’re absorbing so much new information and “orchestrating” everything when really, you’re being fed mountains of options and have lost the agency to steer the ship.

Clear technical thinking is the single most important engineering skill right now. The LLMs are becoming experts at implementing a clear spec. We lose our quality of outputs when the LLM-induced laziness kicks in on hour 8 of tapping the keyboard and we no longer remember what the spec was. We give into the temptation to say, “I think the LLM has it from here”. But it doesn’t. It doesn’t know your business and will introduce compounding complexity if you let it. In software, the last mile is the most important, and in the agentic era having the ability to think clearly and subtract things is the path to achieving quality software.

[Zach Gollwitzer @zg_dev]

@vboykis A few months ago I started making an intentional effort to fight against this and it brought me back to a clarity of thinking I forgot existed. Its like the next level of “digital detox”

[Zach Gollwitzer @zg_dev]

Hand-writing code, reading technical blogs and books, listening to conference talks etc is probably one of the most important habits to maintain at some level right now (even if just 1 day / week). We all know hand-writing code isn’t practical for the demands of the modern day SWE job, as scope has 10x’d at most companies who are paying attention. That’s fine and expected, but just like we built gyms when corporate work kept us inert most of the day at a desk, we need these counter-balancing “brain gym” activities to keep clarity in both our product thinking and engineering thinking. LLMs revert to the mean, so how do we keep excellence in both our products and engineering culture?

These things actively sharpen our critical thinking. They are intentionally slow. Slowness IS the feature here. Slowness allows us to chew on tough concepts for a while rather than a quick follow-up to an LLM who will spit out yet another wall of text that feels smart yet your brain is incapable of internalizing because you’ve found yourself in an endless loop of re-prompting every time something doesn’t make sense. You feel like you’re absorbing so much new information and “orchestrating” everything when really, you’re being fed mountains of options and have lost the agency to steer the ship.

Clear technical thinking is the single most important engineering skill right now. The LLMs are becoming experts at implementing a clear spec. We lose our quality of outputs when the LLM-induced laziness kicks in on hour 8 of tapping the keyboard and we no longer remember what the spec was. We give into the temptation to say, “I think the LLM has it from here”. But it doesn’t. It doesn’t know your business and will introduce compounding complexity if you let it. In software, the last mile is the most important, and in the agentic era having the ability to think clearly and subtract things is the path to achieving quality software.

[Nic Barker @nicbarkeragain]

One of the biggest problems with using LLMs as a google replacement for programming, is that getting zero relevant results on google used to be a signal that you had the wrong idea about the root cause. Whereas LLMs will happily indulge any terrible idea you suggest.

[Addy Osmani @addyosmani]

https://t.co/ze3x7bgsL4

[Zach Gollwitzer @zg_dev]

@arvidkahl Even at these numbers, it’s in the hundreds of TPS, which isn’t unprecedented. I think the real challenge is the entire system was probably architected around upper bound constraints that seemed like hard ceilings (what a human can produce) and AI codegen broke those assumptions

[Zach Gollwitzer @zg_dev]

They need a massive simplification of the UI and to completely scrap the “copilot auto-complete” stuff with Duo which feels super outdated at this point. Insert provider-agnostic AI flows at the edges of the SDLC and make CI/CD runners 10x better than GH

Structurally, they’ve got a lot of opportunity esp since they’re mostly making money off slow-to-adopt enterprises, but execution risk is huge, and so far they really haven’t proven they can out-execute anyone, including GitHub (who hasn’t set a high standard)

[Zach Gollwitzer @zg_dev]

There’s a big difference between “no, we can’t” and “no, we shouldn’t”

The former is declining in value; the latter increasing in value

Conflating the two misses out on an important quality of the AI software revolution

[Jonathan Ross @JonathanRoss321]

For 50 years, software engineering ran on code rationing. Writing code was expensive, so we rationed it carefully through roadmaps, RFCs, prioritization meetings, and scope reviews.

This created a role: the No Engineer. No, that won't scale. No, we don't have bandwidth. No, that's out of scope. No, we need a design doc first. The No Engineer was valuable for 50 years. Every "no" saved real money. Their judgment was the rationing system.

LLMs will be the end of code rationing. Code is cheap now. And while the No Engineer is explaining why something can't be done, the Yes Engineer has already shipped three versions of it.

If you're a Yes Engineer, the next decade is yours.

[Zach Gollwitzer @zg_dev]

GitLab has a solid core product for the AI era and I think their stock has been over-punished given both the financials + pure play offering. They’ve got answers for the entire SDLC, are provider agnostic, and have a perfect chance to capitalize on the “sandboxed agents” trend running at relevant points in the SDLC.

That said, 100% agree w/this. The UI/UX is completely overwhelming. There is too much on each page, and it distracts from the good stuff the platform offers.

A massive UI overhaul would be a great way to re-launch their product and convince the market they’re a serious alternative for more than just big enterprises.

[Jason Cox @jasonbcox0]

There's a lot of confused people in this thread on why GitLab isn't an acceptable drop-in replacement for Github. I will periodically add some examples. These are UX monstrosities that make it *unusable*

[Aparna Dhinakaran @aparnadhinak]

https://t.co/GR8wqBoETN

[Zach Gollwitzer @zg_dev]

@AbhiramTek38379 @_CallMeMacy A CRM build would be a great learning project. Teaches basic data modeling, contact lifecycles/reconciliation across multiple systems, background jobs, SMTP providers

I'd build by hand without AI if learning is the primary goal

[Zach Gollwitzer @zg_dev]

I think customers would be much happier with 2 separate status pages:

1. Uptime - traditional status page with incidents that affect uptime metrics, are deterministic known bugs, and can be fixed fast

2. Quality - a status page that acknowledges degradation of outputs based on some combo of open benchmarking and customer reports (this issue was overwhelmingly prevalent amongst Claude power users here on X)

I get that these degradations could take days or weeks of correlation data to pinpoint.

It was the fact that Anthropic blamed the users and didn’t acknowledge it could be something that was changed internally that caused problems.

No, customers wouldn’t be happy seeing issues go up on the “quality status page”, but would at least appreciate acknowledgement of the issue

These sorts of issues just can’t be represented properly on a traditional status page

[ClaudeDevs @ClaudeDevs]

Over the past month, some of you reported Claude Code's quality had slipped. We investigated, and published a post-mortem on the three issues we found.

All are fixed in v2.1.116+ and we’ve reset usage limits for all subscribers.

[Zach Gollwitzer @zg_dev]

Regardless of how they handled it, it is wild to live in a new world where bugs take weeks to identify, customers are gaslit in the process, and even when you identify, fix, and publish a post-mortem, you still can’t provide 100% attribution to a root cause

“We changed our system prompt which degraded responses” could only be caught by evals, which involves at least some judgment and opinion; a stark contrast to how we’ve evaluated and fixed software for decades

[Zach Gollwitzer @zg_dev]

3-4 in parallel is my max. Guess I don’t have as many cores hardwired in my brain as some.

I think it also comes down to:

- your tolerance for bugs / bad software design (mine is low)
- your budget
- your project scope (in real world enterprise software, most ppl don’t have enough scope/access to truly justify 24/7 agents outside package upgrades and simple bug triage)

The “overnight agents” narrative seems to be highly experimental, although there are some companies out there who I genuinely believe have at least cracked a basic proficiency here, even if for simple routine tasks (ie Stripe, Ramp, etc). But then again, these are companies with huge R&D budgets and time to experiment.

I don’t buy the narrative outside of these contexts (sure, I believe the LOC narrative; just not the “enterprise grade quality + extra LOC” one)

[Zach Gollwitzer @zg_dev]

@siddharthkp The friction of slowness, and the costliness of bad design decisions is how any great SWE became great, and we’ve deleted that layer from the SDLC. I imagine this is more of a talent pipeline issue 5 years down the road than anything else, but I feel this

[Zach Gollwitzer @zg_dev]

I feel like RLS can potentially make sense as a fallback, or, if the team strategically places a lot of logic in the DB (eg fns, triggers, check constraints, etc) and is already incorporating those changes in the SDLC

To me, the biggest issue here in the vibe-coding era is abstracting away the entire idea of authorization from app development. If the platform granularly handles it, but leaves it to the user to get right, you’ve now got a situation where the “dev” (maybe technical, maybe not) isn’t thinking about authorization day to day, and even worse, the agent has no context around it either. So yeah, a massive footgun

[Zach Gollwitzer @zg_dev]

> build a beautiful codebase with strong patterns manually
> drop an agent in there and say, “this codebase is a mess, we need to refactor”
> without pause, the agent will always reply, “honestly, you’re right. Want me to start with XYZ module?”

It’s this sycophantic behavior that makes everything 10x as hard because as the dev, you have to keep a lot of mental discipline to always stay in the driver seat

The second you get lazy, which is easy when you’ve talked to an agent for 8 hours and you’re tired, the agent will follow your terrible, fatigued ideas and you’ll generate so much bad code in those last couple hours that the previous work isn’t worth much

It’s the same thing we’ve always dealt with. More bugs are introduced when we’re tired and it’s often best to step away from the keyboard before doing too much damage

In today’s world, not only do we generate 10x as much code during this fatigued state, but we also have this urge to leave the agent with a task to work on while we step away

[Zach Gollwitzer @zg_dev]

It’s crazy to think that malicious hackers, many of which are highly technical are using the same AI tools to build their exploits while the industry is reducing the tech workforce, relaxing code standards (implicitly), and pushing more LOC than ever before