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.
[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.
> 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.
Throughout my career, I’ve described this as “polite persistence is how you effect change.”
This is so important. One of the things that kills company culture before the company even takes off is getting a sense from the founders that they're just trying to fool desperate/clueless people into working for them for less than what they're worth.
The startups that actually succeed have the philosophy "find the best people and pay them a lot". All the successful unicorns and decacorns over the last 15 years have a reputation of paying people well. There is literally not one startup I can think of that succeeded but has a reputation of underpaying.
And if you're unable to pay employees well then you're simply not well-capitalized enough and should drop the project.
By definition, paying employees well means paying them above-market, not market rate. If you pay people market-rate, nobody writes home about the compensation. Market-rate is also not "underpaying" i.e. below-market.
Paying above-market rates is walking a tightrope. On the one hand, experienced employees who are well-versed in your systems and your organization are indeed worth more than market-rate (i.e. someone new), and compensating them as such will retain them. On the other hand, it also retains poor performers, who you want to steer to finding roles elsewhere. Being ruthless about firing fast is one option, but it's a deal with the devil - it erodes psychological safety among people who stay unless the firing is unanimously desired and there is a consensus among everyone who remains that it was necessary. So if you handle the firing wrong, you affect performance and social cohesion everywhere. If you pay market-rate, it's easier to just make someone miserable until they self-select out and find work elsewhere.
Unfortunately (or fortunately?), all successful startups pay above-market because equity compensation in the right company can be a life-changing amount of money. So most successful startups seem to successfully walk that tightrope.
I define market rate to be the best rate that somebody will pay for your talent (minus Faustian outliers).
"Above-market rate" is an oxymoron. If someone is offering to pay you above the prevailing best rate then obviously you're going to sell to that buyer and it becomes the new market rate.
It really depends on the organization, its mission, the employee pool, and the local cost of living.
Most software engineers are relatively well-paid compared to the wider labor market, even the engineers who are "underpaid". Kahneman's research showed that once you have enough money to pay your bills, making more than that has rapidly diminishing returns for your happiness. It's much more important to fit in - like your boss, like your coworkers, like your work, be recognized, have good work-life balance. None of that really requires above-market compensation.
When a firm pays below-market rates, it's a sign of one of two things: either they're abusing people who can't find work elsewhere, or people are happy to stay in spite of it. The latter are often really good places to work.
HN loves to complain about how money ruined the software industry. Let the people who will chase a raise from $180k to $210k go elsewhere. Let the people who want their moonshot at life-changing wealth go talk to a VC. There are other opportunities for people who realize that money isn't everything in life.
I don't think we actually disagree here. I agree broadly with everything you said. My point was mainly I don't see a reason to support that assumption that if pay pushes out low performers, I don't see a reason why it wouldn't equally push out high performers? This goes on the assumption that lower performers optimise more for pay than higher performers?
Low pay pushes people to leave, regardless of performance. The argument I'm making is that, in such an environment, you retain high performers through non-economic incentives (sense of belonging, appreciation, etc.) and push low performers out by not providing those. Why would anyone ever stay in an environment that also underpaid you and where you also weren't appreciated and gave you subtle hints to leave? Under-paying actually makes it easier to push out the people you don't want. Under-paying does indeed risk pushing out high-performers; my argument is that this is risk and not a guaranteed destiny, and that high-performers may be incentivized to stay by other means.
Even startups that beat the incredibly long odds to become successful mostly aren’t successful enough to make up for a long stretch of not earning BigCo RSUs.
I agree with most of this. However in my time I've never seen a company that was a., successful and b., prioritizing tech debt/upkeep at the same time. I presume AI will fix this however maybe not since it's so tempting to defer strategic decisions to it.
I have seen tech companies flourish which had tech, or tech-adjacent leadership. I've never seen a really good tech company that was lead by an MBA, a "vibe bro", or someone looking to get rich quick. It almost always comes from a genuine passion to solve problems in a certain domain.
One key point is also hires, hiring slowly and not keeping bad hires around. Bad hires really pull everyone down and it's really difficult to work around bad coworkers.
I personally actively filter out companies who don't use Slack. The way communication is done in a company reflects practically every company decision. (Conway's Law)
> I personally actively filter out companies who don't use Slack. The way communication is done in a company reflects practically every company decision. (Conway's Law)
Do you actually mean "don't use Slack" or actually just "use Teams"? If the former, I don't think that makes a lot of sense unless you own a lot of Salesforce stock. There's a number of Slack alternatives that pretty much deliver the same experience.
> I've never seen a company that was a., successful and b., prioritizing tech debt/upkeep at the same time.
Maybe you have only worked in start ups? I have certainly seen products fail or partially fail because of tech debt. One product was extremely unproductive to work on because of a patched together architecture. To the extent that bugs were introduced easily but took so long to turn around that customers left the product and told us that was the reason.
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.
Okay, but Clean Code* would advocate you extract that function to its own class with a new abstraction and it would ultimately wind up way more complicated than the extra params in a function signature
> 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.
I feel for you both working with straw men day to day. I’ve worked mainly in Python for two decades and have neither seen such a thing nor considered, even to be a bastard, doing such a thing.
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
"postgres is so stable I will never trust a rewrite."
"covering 100% of postgres regression suite doesn't guarantee you have replicated every behavior."
Folks who are okay with LLMs think the regression test suite is the spec and is the guarantee of stability. How else can it be? If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?
Folks who are against seem to imagine a platonic ideal of PG which conveniently is the original PG implementation by tautological definition. So no rewrite can ever meet their bar.
> Folks who are okay with LLMs think the regression test suite is the spec and is the guarantee of stability. How else can it be? If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?
I think this deserves a real response.
First, an analogy. I drive along a cliff with no guardrail. How do I not drive off the cliff? By knowing how to drive. Sometimes people mess up and drive off the cliff
In practice people are operating Postgres as a machine, more than an abstract spec. Minor releases exist, but the changes are made by people operating the machine and who have a fear of making the machine break.
There are also performance characteristics that are part of an informal spec. While you can definitely write regression tests on performance, theres loads of value in stability of internals because people who have problems look into the machine and discuss it.
The internals might change, but there’s a lot of friction. So… you can have a lot of informal knowledge about.
If everyone working on a software stack is bathing in this informal knowledge, then the decision making is based on that. Things like what is meant to be in a minor or major release is understood. And people make those judgement calls.
After all, even if you have regression tests if you’re making changes you’ll need to write new tests! How do you know your new tests are right? That the new behavior is right?
PG is the entire machine. Fortunately we have version numbers, migration strategies, etc. But “here’s a new binary that passes the test suite and… maybe changes everything not covered by tests maybe doesn’t”. Why bother suffering when there are totally reasonable gradual rewrite strategies?
And of course… every bug in the world… got through despite a test suite! What software out there doesn’t have bugs?
And if the behavioral difference in the rewrite does affect people… I guess that’s something right? “Oh this isn’t a bug because it wasn’t covered in regression tests” is not that tenable.
If you are saying the PG regression suite doesn't cover these perf tests - that is fair. I consider perf to be part of the "regression framework" generally.
>> How do you know your new tests are right? That the new behavior is right?
This is a more generic question in the LLM world. Reliable verifiers is what drives LLM loops. If you don't have these, you have no idea if you are actually making progress or you just generated code that returns 42 for every question. You needs something to actually ground the LLM output against. For existing features, the reliable verification is the existing regression/perf suites. For new features, the regression/perf suites should expand to fit. There are ways to go at this that range from ad-hoc (line/branch coverage) to fully formalized (verification-aware languages like Dafny).
> If you are depending on some behavior not covered in the regression tests, how do you know the next minor release won't break you?
Decades of intrinsic knowledge. Which a rewrite lacks.
imho the issue is the language used. AI rewrites are cheap and cheap exercises require a great deal of scrutiny and proof of correctness. Simply using regressions test lacks the intrinsic knowledge of a decades old codebase stuck in developers minds.
Claiming a rewrite is better because it passes all tests is a flex, a new version requires a boatload of evidence for people to accept it as an improvement and not just "passes tests, written in rust via LLM so it must be better". Run it in production for a year in a sufficiently large system and you might be somewhere.
>> Decades of intrinsic knowledge. Which a rewrite lacks.
You mean the ones encoded in the regression suite? I think your argument is valid in many medium-to-faang firms where the application is going to have encoded business logic that isn't explicitly tested for. If anything, projects like PG are the exact opposite: no business context and regression suites that test every possible scenario due to the accumulation of bug fixes and context over many years.
>> Run it in production for a year in a sufficiently large system and you might be somewhere.
How do you know every release of PG doesn't break in the setting of "a year in a sufficiently large system"?
> no business context and regression suites that test every possible scenario due to the accumulation of bug fixes and context over many years.
Spend time enough with a codebase and you’ll know stuff about its behavior that is not encoded in a test suite. Especially when you need to adjust an integration tests due to the modification of an invariant in a dependency.
> How do you know every release of PG doesn't break in the setting of "a year in a sufficiently large system"?
Because the postgres team is professional and will take care of publishing a changelog for what has been modified since the last version.
I think what folks want, but aren't quite able to articulate, is an ongoing community and effort that indicate a project will be healthy and maintained. We want to be able to rely upon the software that we are choosing to use.
Regardless of the technical choices, whether Rust is better or worse, whatever -- pgrust popped into existence thanks to one person driving an LLM through 7000 commits in ~2 weeks. It produced something that passes the regression tests. Even as an LLM-sceptic, I think that's amazing.
From that point, though, it appears to have been completely abandoned. There hasn't been a commit in a month, other than a brief tweak and a note that an as-yet unpublished version that's even betterer is in the works. IDK. I don't think we've acclimated to the shock of the change LLMs create, but if the outcome is a forest of exciting new projects that have a bus factor of 1 and little to no collaboration, I think that's a disservice to this profession.
I am not saying anything about the viability of that particular project; just that one argument that was repeatedly made in that thread which I think is frankly nuts.
Yeah. I guess what I'm saying is that I feel like we're all still stuck debating these things on technical merits alone. The `bun` rewrite and `pgrust` both expose something -- I find, at least! -- uncomfortable about how we understand the technical side of our profession, but I think the social side remains the same.
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!
reply