Zach Gollwitzer

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)

I thought this morning that maybe the market is mispricing GitLab. For context, their stock has fallen in value by >50% over the last year. So I spent some time this morning testing out the product end-to-end (creating a repo, checking out trending projects, pushing code, opening a merge request and reviewing, etc.). Well, there is a reason not everyone is talking about migrating to them during this otherwise obvious moment of opportunity: the product is just not that different than GitHub, and in a lot of ways it's IMVHO just worse. Unless they reinvent the product in a big way, GitLab doesn't seem to be well positioned to take advantage of GitHub's current moment of weakness. Their products are just too similar to each other. Ultimately, I decided the company is not worth buying at this moment in time. Maybe that'll change, but right now the source control products I'm paying attention to don't resemble GitHub at all; whatever comes next will look completely different.

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

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.

@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

@zg_dev @_CallMeMacy But what would you recommend for beginners. Who are just starting their programming and web development journey. About the ai usage By the way your channel helped me a lot while starting the web development journey.

Lately, I've been advising founders to vibecode their own CRM that reads their emails, calendars, and keeps things up to date in real time. It took me 2 hours to create my own using Claude Code (and I've never coded in my life). Am I crazy for suggesting this or do others agree?

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

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

The frustrating part is that the Claude Code team, along with people deep in AI psychosis, have been gaslighting anyone who raises concerns about Claude Code's recent issues. "your reasoning setting is wrong" "oh that benchmark is wrong" "we checked our code, nothing is wrong" "skill issues" "Hate" is a strong word, but when you're paying a lot of money for a product and it actually makes your job harder, to the point where people make you start questioning the quality of your own work, it really becomes a problem. I'm glad they identified the issue, and I genuinely want them to succeed, along with Cursor, Codex, OpenCode, and others, we need more alternatives, but we also absolutely need open benchmarks. anthropic.com/engineering/ap…

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)

Talking to smarter folks than me, I'm convinced many of the AI folks in my timeline are full of shit. Nobody is "running 20 agents over night" and building stuff for actual users. Maybe some are building internal tools or disposable software. Maybe. But building software people like using? That doesn't get hacked on day one or blow up after the 3rd user? Nope. I don't even understand what that's supposed to look like. Do you work out a 57 pages document that perfectly describes what you want to build and then summon 14 agents and have them run wild for 6 hours? And what comes out on the other end isn't a broken pile of shit? Nope. Not buying it. PS: it may also be that I have an IQ of 82 and can't figure it out.

@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

staff/senior engineer thought:

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

RLS was a mistake and folks exposing that level of complexity to less technical users is asking for trouble. It was a mistake in Firebase. It’s a mistake in Supabase. It will be a mistake in the next product too. I personally - even knowing how to secure it - would never touch it. It’s the worst security footgun you can imagine. One small mistake and your data is available to the world.

> 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

I've been using Claude Code exclusively for 6 months and I'm still not convinced on this whole AI thing. There are some *seriously* insidious problems that worry me, and I don't see them being fixed any time soon. Every release of a new model, I see hundreds of posts where people think because they one-shotted X or Y, software jobs are cooked (I've probably made one or two of these posts myself). But none of those examples are actually representative of real-world software. If I set it to work on an ambiguous or highly complex problem that has a lot of branching in the solution space, I've noticed the following: - It can often generate a working solution in one-shot, which gives me a false sense of confidence that the AI knows exactly what it's doing. - As I continue to work the problem, I've noticed the AI will start to narrow its focus more and more, not considering how a fix or solution plays into the big picture. - The quality of a solution depends on *how* I prompt it, which is really, really bad. Software engineering should be deterministic, not a dice roll. - It will often ignore instructions I have explicitly stated in the rules file, which removes any confidence I have in the code it generates. - It consistently overstates its confidence in a solution. I literally just got this response from Claude: "I overstated that. Honest answer: it depends on the scene and implementation; the 2–4× figure was too confident." If I had never pushed back, I would have been operating on incorrect information. - It is far too agreeable. If I'm not careful in my wording, the AI will blindly follow my instructions, even if they are suboptimal. I want a real coding partner that challenges my ideas, not an ass-kisser. Don't get me wrong—AI has helped me build some amazing things faster than I ever could without it. But the more I use it, the more I begin to question the direction things are headed. If the AI was more direct about what it (not) capable of, it'd be a lot easier to work with. But being gaslit every step of the way makes the process stressful as hell. Going back to manual coding isn't even an option since the value of having AI *potentially* generating the correct code in 1/10 or 1/100 of the time is literally too good to pass up on. Sorry for the rant, drank way too much cold brew this morning.

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

Pre-LLMs, human devs often constructed codebases that struck a practical balance between codebase philosophy (ie DDD) and pragmatism. In the human world, splitting up every feature into repositories, value objects, factories, entities, etc didn’t *always* make sense So we implemented the philosophy in areas where it mattered, and took pragmatic shortcuts in areas where it didn’t (ie direct domain model interactions in the controller vs service layer, it’s the beauty of a framework like Rails!) I think one of the interesting findings here in the LLM era is that it can be challenging to encode these pragmatic decisions into a rules file It’s very hard to tell an LLM, “if the feature is simple, skip the DDD philosophy and all the patterns we use and be pragmatic about it, but when it’s complex, use all established codebase patterns” It’s much easier to say, “this codebase uses DDD. All controllers call a service, which loads an aggregate through a repository, and invokes behavior on the aggregate” The LLM does great with those sorts of instructions. Even though there’s a lot of extra code to write and most features don’t need all the ceremony, it feels increasingly valuable to have these consistent patterns in a codebase Given the vast number of brand new startups funded 2025-2026, it wouldn’t be shocking to see many of these companies adopting old “over-engineered”, “overly-ceremonious”, “impractical” engineering ideas at the start of their codebases to optimize for consistent LLM outputs It’s obviously more token costs to generate this much extra code, but the maintainability benefits seem to offset that in the long run

Bob runs an essay-writing business in college. Bob’s essays receive A’s at the best price, so his business grows. Bob loves writing the word “egregious” in every essay. Bob scales his business, capturing 50% of essay market. Now, “egregious” shows up in more essays, despite not being popular before. The word “egregious” hasn’t become more popular. Bob is just writing more essays.

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.

Me prompting claude at 3AM:

@adamhjk And I'm even hesitant to call it "over-engineering" because in the agentic context, it's not. Agents are superb at over-engineering when they don't have a harness (both CLI tool + consistent code patterns)

@zg_dev Right - the lack of practicality and over-engineering suddenly is just what we need in a world where we don’t read the code, but do need to be able to express when it’s become unwieldy.

My experience is the opposite. At the highest rate of speed (where engineers can only really understand the outcome, but not the output) constraining the patterns is wildly helpful. For example, the difference between an entity and a value object is annoying by hand. But it’s super useful when the agent does the work - it allows you to pay less attention to the specific output, because you can rely on the shared vocabulary *and* the common implementation and structure. When it comes time to refactor, or when you need to extend the software in all the ways DDD makes easy, the actual implementation guidance is critical. The OG poster’s take is reasonable, and was largely mine for most teams before I moved to have AI be my SDLC (rather than having it *in* my SDLC, or not using it at all.) But once you move to building the machine that builds the machine, you will be very grateful for those common shapes and patterns. They unlock the suppleness that we used to find only by painstaking hand crafting.