This resonates with me. I joined a climate tech company to help save the world. I built data pipelines like anywhere else
237 karma · joined December 13, 2019
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?
At the same time, I’ve invested in tooling that prints and lints architecture I want, so which model is less of an interesting decision, because the results tend to be very close.
Can someone help me understand why sales is immune to this strategy and still is employing the “more bodies” approach. I thought we were working smarter in 2026?
I don’t know. I’ve invested heavily in building internal tools that scaffold code and lint the filled in architecture/code design. That with a ratchet pattern, to allow for new rules that have errors across the existing code base, but to asymptotically fix them, is working pretty well.
Example - all modules have tightly scoped design primitives (I’m using hexagonal architecture for the backend, for example). And all code has BDD tests, which is what I spend much of my time reviewing, since cases written in human sentences is easier than looking at so many files of code.
There is a relentless upkeep to draft rules that respond to the workarounds the agents come up with to adhere to the design I want, but it’s slowly approaching perfect. What has helped here tremendously is I use hooks to llm as a judge the decisions the llms make, and then have them review/raise the questionable ones after a first pass is completed. In general, this is snuffing out the slop effectively.
All to say, someone asked me recently what model I prefer. In this approach, the model doesn’t really matter to me because the code is consistently what I want. I’ll choose a model because it has better mcp speed (codex), or a more thorough scope (Claude code).
Where this IS true is when we’re building a net new pattern. The agents are not great at it. BUT most code can fit into the few patterns I’ve created, and what can’t you lock down a new pattern to enforce over a couple iterations of it. Almost everything, at least in SaaS, follows a template.
Who is this good for? My company, Anthropic/Openai, but not me? Maybe if I was investing in a side project I’d feel differently.
At any rate, the thought of bringing the agent out of my work machine and into my pocket or bed with me is terrifying. I hope it doesn’t come to that.
I guess the author has never worked on a dog shit system with no tests at all and constant downtime.
I have worked with “complexity averse” engineers who would rather fix the edges over and over again, than roll up their sleeves and just get the job done.
I just don’t believe that using new tools is at odds with avoiding complexity.
Sometimes you have to take it to the chin, and get to use the new shiny thing along the way to move much faster.
- programmatically enforce your style with in-house linters and scaffolders. Be highly opinionated
- if you # ignore anything, leave a comment explaining why
- use bdd so your cases are human readable and must update with the code (unlike a stale comment)
- follow the same pattern in all your services (I love hexagonal design for backend). If you break from the design have a good reason for it
- COMPOSE your code. It’s almost always the case that two endpoints or jobs or whatever happen to have a few things in common, but differ wildly. Don’t get DRY, just import those things in each spot and don’t entangle them with each other, it’s too confusing
- scope your interfaces tightly. No optional params unless the domain is actually optional. Make separate jobs or endpoints for different configs. I can’t figure out wtf all your configs were from 4 years ago and neither can you
- code is default testable with DI/DIP
- always run tests running real infra like testcontainers - cement ci/cd as your guardian. Employ every linter you can.
- hammer workarounds with comments in the code
- break all systems into small problems and nothing is challenging technically (though the domain might be!)
- work with less people on your code. It’s easier to stay aligned and follow the same patterns
- don’t expect anyone to figure it out. You need to champion your changes. Do code reviews, hold their hand, show them the way
- clear out mundane items like installfests, local auth, server reloads. Slow dev pisses people off
- finally, and most important, employ an org policy for review. Don’t let shit fall through the cracks unknowingly. It compounds. You have skills now as a quick and dirty to eval and enforce. Use them!
Not really. Today I learned of a story where a vibe coding PM deployed a vercel app, which was in its entirety a single react component that serves a banner, that was embedded via an iframe into an entirely separate web app, whose repo they have full access to, because they needed to get a modal component out the door, but were blocked because they “couldn’t upload the image to s3.” (They could just use the public/ or assets/ directory and have the cdn pick it up, too.)
People do the most insane things when they are tight on time and don’t have the intuition to do a bit of research up front. If you ask them, they’re solving the immediate problem at hand. If you ask anyone else who interacts with their work, they’re disrupting our days/weeks/months/years when we have to step through systems that don’t know any better.
If you have the muscle to plan ahead, even a little bit, which is usually just following the same pattern over and over again, then you are fine.
In this world you are still optimizing for the now problem but you have also solved, to some and ideally a better degree, some future problems for free
Says who? One of the most enriching things about coding with agents is I have them provide new information, tools, patterns, whatever as a follow up to every feature I work on. I’m learning a ton and it’s helping me build better with agents, too.