dirtbag__dad

what do you work on that isn’t CRUD?

I don’t believe that nobody is doing it well. May I ask who is doing it well? Either in house or with an AI reviewer vendor.

For me, what works is highly templated directory structure and rules that linters can quickly check and enforce. Every PR is a cookie cutter design filled in. There are only a handful of things you need and they’re all just CRUD at the end of the day. You can employ the same very few design patterns and primitives across a lot of your stack. Review is so fast, if you trust your CI to do its job and the developer to actually QA their own work.

What isn’t working is the sheer volume of PRs. Even with CODEOWNERS directing attention to only high impact changes, it is a constant distraction. I’m not sure how to handle SOC2 where we need a human reviewer on all code. Lastly, agents shit the bed when they touch spaghetti, esp when it’s sitting next to structured patterns. IME, the best way to get around this is to just rewrite features from scratch. But in this current world of instant completion and reward, it’s been challenging to convince people to commit to more ambitious lifts.

Finally, I want review more than ever. A team can’t keep up with the pace of change even if it was all perfect. I like the idea of more up front planning, but the code is ultimately what matters.

I’ve twice put in my 2 weeks and have been fired on the spot. In one case, I had to ask for permission to work for a couple days for free so I wouldn’t leave my teammate hanging (the situation unfolded rather suddenly).

Knowing what I know now, I’d still put in my 2 weeks, but also be prepared with my new employer that I might start immediately, depending on how old employer takes it.

This is also my experience, but when I saw how few tokens/second with a large model it gets locally I was bummed. I’m wondering if I’ll be obligated to upgrade in the near future

The point is that the implementer shouldn’t have to investigate to know whether the key’s value is nullable.

This to me feels more like a developer skills issue than a problem with the LLM. At my day job, we banned using untyped data structures like this entirely well before LLMs because no one could read code that passed them around.

You could use a data structure that better articulates an optional field, like a dataclass with type hints or a pydantic model. Then you, your coworker, and the agent alike, aren’t guessing at whether the key’s value is optional.

Another example in this vein is having many optional parameters on a function or api route, that drive behavior deeply nested in the application logic. Or maybe they were there for testing and never deleted. No one comes across this code next and understands it easily. How could you expect a LLM to understand it, either?

I find it funny when people blame the LLM for dog shit code, but at the same time have a pollock painting of code they load into its context, and are like “put a person in the horse and carriage!” And the LLM is like “bro I just see dots and squiggles but you asked so boom!”

This is what’s up! Having worked on several medium sized python projects where linting and type checking were introduced late in the game, having them as a first class feature of the package manager will save so much unnecessary pain.

IMO, part of the problem is that people just don’t know that linters or tools like this exist at all. This is the best type of product marketing where the product gets meaningfully better, while educating the users for free.

At an early stage startup, like OP is asking about, you can expect engineers to do everything.

This is a story that cheap employers tell. Hire for “growth potential” in order to save $50k, and in return the rest of the team is taxed for many quarters, results are mid at best.

Of course it is true that some juniors outperform competent seniors. It’s also true some seniors are just checked out. But when you are willing to hire folks with meaningful years of experience, you get meaningfully better velocity and quality. It doesn’t matter how simple or complex the problem is.

Yes! As another Pennsylvanian, this is a hard requirement for my forever home. The idea that I’d go all-in on a large property in an undeveloped area, only for the surrounding land to get developed or demolished is scary. State game lands is a way to protect against that outcome.

Also a concern is proximity to fracking and now data centers. Not sure how to see if neighbors sold their underground…

As an anecdote, my parent’s home, where I grew up, is a small plot along my town’s watershed property. When the price of lumber went up recently, the town council conveniently remembered that the watershed property was once a massive “tree farm,” and since has leveled all of the surrounding woods. We never expected this. It has been emotionally crushing.

There is surely a tremendous amount of waste and noise right now. But does it _actually_ matter what the code looks like for a desktop app that’s useful to a small handful of people? Every single implementation has at least one person who thinks it’s dog shit, no matter how correct or perfect it is. We have to get past this. If you really can’t stand it, build the thing yourself or some deterministic rails to reel it in.

And, there are also people who know what they’re doing building things they couldn’t before.

This situation is a net positive, and not too different than before. It’s up to you to navigate the noise.

This, with an extremist take on code quality via linting in ci, is no doubt the future, at least for maintenance and extending the interface kind of work.

1. How does this work with greenfield lifts where the scope and final vision are not yet figured out?

2. Sorry if I missed this in the post, but will you open source this system?

This resonates with me. I joined a climate tech company to help save the world. I built data pipelines like anywhere else

> I also see a lot of Devs simply trusting that the code is correct, they are losing touch with the code.

My team has a non-engineer vibe coder who doesn’t know how to even use git, but managed to put together a large application that serves enterprise customers better than the real SWEs we had working on the project.

We’re in the process of porting their code into the main codebase, and it’s obvious to me, not so much them, that there is an insane amount of waste. But I’m not sure whether that’s a bad trade off, the end product works and llms get whatever he needs done.

OTOH, I’m an experienced SWE who is taking a stab at writing dev tooling in rust, which I don’t know and don’t have the time rn to learn. I am very aware there is a lot of waste, the project is obviously moving slower than if I was more involved with design. I was ok with the trade off but I’m growing antsy now.

All to say, it feels to me that vibe coded tech is a viable path so long as you accept what you’re going to get.

The one exception I see rn is when we try to do brownfield work, LLMs get very confused and simply cannot manage an old dog shit human written system with a new set of concepts floating in. Jury is out whether this will also happen with ai slop, but again maybe it just doesn’t matter

I don’t know why this was downvoted. I have children and the first thing I questioned was whether the author has kids.

The intro to the article feels like the author asked a LLM to summarize journal papers about consciousness. It seems there is not a consensus around what it is.

Can anyone in this field provide a directional overview of what we think consciousness is in 2026?

meetyogi.com | Senior Software Engineer, Backend / Product | $180-220k | Hybrid NYC | Series A | 35 headcount, ~10 in engineering

Yogi aggregates and analyzes millions of customer feedback data points from online retailer reviews, social, cx ticketing systems, etc to help companies make better decisions about their products and markets. We operate mostly in CPG, where our customers are household brands you'd recognize, both enterprise and up-and-coming.

--

Everyone is kind and engaged with work at Yogi. It's a nice vibe.

Our stack is pretty standard SaaS - python (fastapi, prefect), postgres/clickhouse, react/typescript web app. The app experience is what you'd expect from a data analytics platform - charting and agentic workflows that generate insights from the data.

In terms of the moment, we're reaching the bounds of some early domain assumptions, while also figuring out how to expand into new ones. On the code front, broadly speaking we're improving quality and process each quarter by an order of magnitude. AI has been a boon for us. (I've personally invested a lot in our dev tooling to make code output high quality and deterministic)

There's a lot of greenfield opportunity and also scale challenges to be solved on existing tech. No shortage of things to do, ownership is as much as you want to take on.

--

Interview process is a chit chat with our CTO, an onsite with a practical coding exercise (not crazy i promise), a system design conversation, and behavioral interview.

Email me at jon.young(at)meetyogi.com or connect w me on linkedin /joncyoungii if you want to learn more. Happy to answer any questions you have honestly and refer you if it makes sense on both ends

I can validate that is frustrating. An inability to articulate more than the code is bad and it’s complicated is surprising from a TL.

That is probably the case in most companies, and as I said it’s not that hard to identify what is impacted by that dog shit code.

Having a spike/PRD/TRD process, really anything written by a human long form, can help build alignment. This is because you have ample time to ask questions and dive deeper, and it’s not personal it’s just part of the process.

I’m not sure whether the charts I created were themselves the convincing piece of evidence. They just happened to be where I found common ground easier and then maybe the rest just clicked

More or less. I set up DBM on datadog and built a dashboard with common db perf metrics. You can set thresholds as dotted red lines across the y-axis of charts to articulate moments of danger.

> The continuous struggle is to find ways to increase the value our platform provides to the users of the system.

IME as a staff+ platform engineer*, it is dead obvious what increases user value. What is truly challenging is building a story around why anything should be worked on at all, when platform sits the furthest from customers.

I previously worked with a seasoned PM from FAANG who had low technical chops but somehow placed themself in the final decision maker seat for platform work.

They relentlessly blocked work that I described repeatedly in details: data quality was hurting, latency was dog shit, etc. But “bad data model? What do our customers care about our data model and pipelines that are confusing to maintain?”

It wasn’t until I showed some basic charts about our core database being oversubscribed and at risk of a more serious incident. At that point, we finally had the same understanding of the problem at the highest level and I was granted (lol) approval.

This admittedly took me almost a year to figure out. Others just trusted my judgement. The takeaway for me was really good tho. Even technical people probably don’t know wtf is going on in your domain, and metrics gets everyone on the same page, because numbers and charts are easy to understand.

* Platform is used too broadly so hard to say what the author exactly means by this.

Do you have any examples of this approach?

I’m a full time SWE and AI has been a boon for my career and software in my personal life.

I’m plowing through huge projects at work I never dreamed possible before agentic development. And now I can write side projects with the limited time I have.

My current take is that AI is still broadly terrible at writing code on its own (I use codex and Claude code). What has made me effective is writing dev tooling that deterministically write and enforce code design.

My team uses the tools I wrote, and with (much but not complete) confidence we can ship good code reliably with ease.

BUT, to get there, it took a lot of SWE experience, mostly from drowning in shit code for many years. to know what is actually good takes knowing what is bad. And to scale that out across many engineers, to give them “taste” for free, is not trivial. Without this tooling, I probably would have lost my mind tbh.

I get the gripe with AI. If you don’t know what the code is doing, someone else who reads it will, and you’re wasting their time unless you’re asking for something different than looking at the code. Maybe you have a product you want reviewed. In that case, does the code matter as much as a SDK? Doubtfully.

> A coding assistant helps provide structure that I don’t trust myself to impose.

I believe you think you have some good rails, but it’s relative. Maybe it’s helpful to you but to a seasoned person or even objectively it just isn’t. Or maybe it is good, idk.

At any rate, asking for grace when shitslopping code in doesn’t tee you up for mentorship. Investing in learning code itself and being honest about your limitations, for me at least, wins more points than dishonesty, which I see is a recommendation in another comment.

You SHOULD be using AI in 2026 when you know how to steer it. And if you don’t know how to, you SHOULD constantly check yourself and level up. Every loop of your agent is an opportunity to learn.

You got this!

If you ask any model to write as tables to enumerate points, and BDD for logical flows, it’s like 50x less strain on you

[for companies with idk 100 or less headcount] Good culture boils down to:

1. Predictability. Flavors of it: deliver features on time, roadmap stays mostly stable, on demand requests are known about ahead of time, business struggling or doing well transparent, tech debt / upkeep are first class citizens of planned work. All of this is project management and communication.

2. Org pays market rate and has good benefits. Employment is an exchange and esp for those who work hard, they deserve the recognition.

3. “People” (aka HR) is taken seriously. The team is expected to be checked in. Those who aren’t get fired. Ideally, there’s enough in place for individuals to come to their own conclusion that they should be fired. See #1. When a req is open it’s a top priority of whoever is in charge.

You can be PM-nonexistent or PM-heavy with lots of meetings and JIRA. Maybe you can accomplish all 3 above in both worlds. My experience is that process when done right moves the needle. No process leads to nonsense and process for the sake of process grinds it to a halt. It all gets better when the leaders are bought in or self aware enough to get out of the way.

If you push for change long enough, and aren’t an asshole about it, just genuinely interested and motivated, there’s a chance you’ll see your vision for better culture materialize.

For non-engineering teams my playbook is:

1. Get in all their support or public slack channels, watch for acute moments of freak out or consistent schlep blindness. 2. Meet with the head of the team once a month for 45 mins and get them to list out what just sucks.

You can limit chit chat very well this way.

You’re only going to be able to do so much so broadly picking the problem that is closest to the business’s immediate pains can be a win. Or maybe that’s already being swarmed on so you knock out a bunch of random stuff and get broad recognition.

For technical teams, almost every single thing I ship:

1. cements a new pattern or contributes to a new one that my team can use 2. improves cicd speed or checks

You can usually knock out the non technical team work and pick off 1 from technical team work along the way

Everything I do (except specific bug fixes) force multiplies, otherwise I’m wasting my effort.

I don’t feel like I need to talk too much to my teammates about their engineering problems. I’m doing the same work ultimately, so I have a solid understanding of what moves the needle

Edit: convincing the organization that your work is important gets much much easier when you have metrics and charts that make the case for time well spent. It could be a buggy ass feature, or a meaty pipeline the business relies on. Prove that it’s hurting the customers and ultimately the bottom line. Battling over and convincing of scope becomes less important when you’re talking in the same language as non technicals

This has been my experience until the past 6-9 months, when AI got good enough that I can build rails to prevent more bugs while also hammering through critical issues, redesigns, etc.

It’s never been better to be a staff+ engineer, where you can knock shit out of the park and tee up your team to do the same all at once

> just bringing back random knowledge from previous jobs or self study, and being able to apply it to the problem at hand.

Being smart, at least in the context of the workplace, is about being checked in to whatever you’re doing, and drawing connections across your experiences.

New claude models, at least in the context of Claude code, are broadly lobotomized. Move extra slow, write loads tooling scripts you didnt’t ask for, and don’t actually complete the task at hand. They’re like rain man.

Idk though it ebbs and flows. Rn latest OpenAI models are capable of long focused decent work. Surely it’ll flip at some point in the near future /sigh

I think you’ve missed the point of clean code if this is your gripe with it.

Every time you over scope a function signature, because you want to handle that other case, you add mental tax to the next person. This accumulates, burns time, and now confuses agents, which is time and tokens ($).

No one wants to work with a dogmatic individual but I’d rather a nit picker than a human or agent slop machine.

> The actual problems in the code I work with are not the spaces at the end of line or imports in non-alphabetic order, it's the 10-line list comprehensions that are so long that they're impossible for me to parse.

100%. Almost all of my time burned navigating code is not hung up on stylistic conventions but on nasty services with inconsistent abstractions and patterns.

BUT, conventions and consistency make code easier to read and write, period. If you’re debating over single or double quotes that’s almost a fireable offense IMO.

Additionally, when you have a culture that delegates to tools as much as possible, the focus sharpens in a healthy way.

If you can lock down a test suite that ensures parity, then who cares what shape the lift ultimately looks like.

A full rewrite in different language that fails to be idiomatic is a step backward operationally, even if you stand to gain on issues the new language just eats for free