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

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?

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

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

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.

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!

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.

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

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

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.

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

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.

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.

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

This is a poor comparison, but I do get what you’re attempting here. It’s also absurd that we are leveling land everywhere around me to build warehouses. No one is really complaining about that, either.

Anyone else working on something like this or know of any projects attempting it?