I get that some specialisation is useful, but I would like to see more T-shaped data folks.
I think the specialisms are really helpful for hiring - data engineering and data science involve a lot of different things so it's a lot easier to hire someone if you don't require skill in both.
That said, I think we have a culture problem in defining our roles narrowly, I've seen data scientists look down at data-pipeline parts of their job, and ignoring model latency and deployment; data engineers be deeply uncurious around what happens to the data after they put it in a warehouse; etc.
The best people I've worked with, within data and elsewhere, are the ones who are curious about every aspect of the stack, even if they mostly focus on one side.
15, 20 years ago, me and my T-shaped skills could get by just fine with a database server, a NAS, and some frank conversations about priorities.
Nowadays it’s not enough to to know how to work with databases and files. There’s also all these platforms: databricks, snowflake, new relic, sentry, datadog, GitHub actions, prefect, dbt, kubernetes, cassandra, elastic, and on and on and on. Each brings a new set of idiosyncrasies, its own terms for things, its own enterprise integration headaches. It’s just a hell of a lot of knowledge to ask one person to cram into their head on top of whatever skills and domain expertise form the actual core of their job.
That makes sense for an enterprise. Enterprises have a lot of bodies to throw at the problem, so they can have an expert for each tool who’s available to support everyone else. And they like to have support contracts and SLAs, which you can get from à B2B vendor but not from the KISS principle. And they don’t mind great heaping piles of unnecessary and mutually conflicting abstractions because that sort of thing is just SOP for a large bureaucracy.
But if you want - need - a system that one person with T-shaped skills can reasonably fit into their head, this is not the way.
Every era views itself as an intricate snowflake, but they rarely are.
Me too. There were no data engineers when I was a baby data scientist (15 years ago now).
I think that this was a terrible idea (the splitting out of roles). I remember once being asked in an interview if I was able to pull my own SQL or would I need an analyst. That kind of split always struck me as absurd, given that the only way to build a decent model is to know the data very well first..
> That said, I think we have a culture problem in defining our roles narrowly, I've seen data scientists look down at data-pipeline parts of their job, and ignoring model latency and deployment; data engineers be deeply uncurious around what happens to the data after they put it in a warehouse; etc.
I honestly feel like this is driven by the titles. I will note that most of the unsuccessful/bad data scientists I've met were the ones who only cared about the models. As I always said to people, I can run sklearn in a loop over model families if that's all you bring.
> The best people I've worked with, within data and elsewhere, are the ones who are curious about every aspect of the stack, even if they mostly focus on one side.
This is probably just a good signal in tech in general, some curiosity is really required to be successful in this industry.
Stakeholders prefer a single point of dev contact so you can never get rid of the role, and you can only repeat that for so many domains or solutions before you run out of hours in the day. Trying to spread this ownership across a team results into either horizontal or vertical specialization which are the two dysfunctions. I'm not sure why this is like this in data.
30 min livebug fix and review for me on a job I specced out? Ticket to another team to review and schedule for next sprint and thus 2 weeks of metadata likely lost or malformed.
These setups look great (but full of invisible friction) when things are going well but shit the bed as soon as you come across the simplest of human errors that needs a solution.
Then the BI people (who had never written a line of code except maybe some SQL) got jealous, started calling themselves "data engineers", broke everything ("what do you mean 'we need tests???'"), and ruined the title.
Back then his bank started building a data science/engineering dept, and he jumped ship, and essentially did the same work for 2x the salary. Let me tell you, understanding Black-Scholes and what the data actually means and how to source it, as well as what finance people actually are looking for is a skill that's 1000x as difficult to get as learning R/Python/Pandas etc.
An analyst then loads this up with whatever visualization software or 3rd party BI tools and interprets the findings and I've found this varies from giving a simple presentation after AI tools do everything for them to doing full on R Studio analytics such as these models https://www.stat.cmu.edu/~cshalizi/ADAfaEPoV/
If the analyst then selects a feature set from the data and performs machine learning I've found they are called 'Data Scientists' otherwise they are analysts but these titles mean something different everywhere.
And yet if a data person were to try the same on your specialization, surely this would also be well and good.
It's always been possible to massage your data to fit whatwver case you want to make. Previously you had to go through a data analyst and convince them to let go of their principles. Now you can just let an agent figure it out.
So how do you make sure insights are actually shareable (and trustable) with other parts of the company?
I think just exposing the metrics layer is probably the answer here.
It's kind of funny that the industry has tried to democratize data for so long, but now we scramble to restrict access to protect users from making incorrect decisions.
Like for example
>It doesn't know how your company counts revenue, or which of several similar-looking tables is the real one (it is revenue_cpx_new_revised_v2_use_this_one )
This assumption mostly only holds for non-clean data ( which is mostly a result of humans being lazy and backlog being clogged up ). As AI starts building more of the pipelines upstream - this becomes a non-issue.
Even for existing pipelines, I'd expect fixes to move upstream: when an agent encounters ambiguity at query time, the useful output isn't an edit of the context,but a PR that fixes it.
Umm, the model knows the same way humans know: either by looking into slack threads/confluence pages/emails… If your model has access to those things, then it can know. And I foresee that in the near future the model can simply have an incarnation as a Slack member, and when context is not enough, they will simply ask people around (and update docs accordingly)
I've never had business users as excited about data and they're spewing out visuals on their own with Claude and an MCP connection. They're sharing them with one another. It's still new and shiny and it's created challenges in terms of curation and we have a lot of "source of truth" discussions when folks wander outside the data model, but this is a genuine revolution in the discipline. There's a lot of truth in the article.
I made my 20 year career as a person who could do stuff with computers, software engineer etc. Every time I hear someone say, "my non tech friend who vibe coded an app got a bug he couldn't fix" etc, my response is they are using the wrong model and give it a few months. And I say this with great pain, I am in no way an AI booster, just a realist.
As long as we do not hand over our collective decision making power to the machine god, which I don't think is a good idea and am not sure is even possible, the world out there is at this moment still shaped by humans, with other humans, for humans.
I have this feeling that there is more about society and economics than efficiency. I have right now people I know that work in jobs that could have been automated for many years to a very high degree. That is even without AI.
Counterpoint: This is not only possible but has effectively already happened. From the outside, the current trajectory is indistinguishable from humanity serving the AI, pulling all possible resources out of literally everything else in order to burn them on AI R&D, training and inference.
I think the bar is much higher - something like "AI runs our political and social institutions" - the economic institutions it's involved with currently don't meet that bar.
Big companies though, are more concerned with value and risk. Say some data model provides $5 million in value, hiring a data person to check "everything is kosha", even if in theory someone could vibe code it by prompting an LLM, is a pretty good investment if it derisks the process.
What makes that quote so special that it is worth pointing out as "the best" in 11/2026?
Related: https://news.ycombinator.com/item?id=50438318
Edit: by "semi-auto", I mean auto mode + lots of manual involvement, as opposed to an agent loop or other yolo strategies
I'm also working on transitioning from a classic SWE to a small independent team doing our own products.
Sure I won't make as much money for doing bullshit changes in some old legacy system but I will actually deliver things people will like using, and I'll be in touch with other people on a daily basis.
I'd like to also use a model on my owm hardware, but alas, I'm relatively young in the industry and my wallet is not fat enough for a local AI stack.
I.e the reality has so far been ~2 years behind the hype.
I'm not saying I like these companies, or that I think the economics of any of them is sane. Just saying LLM's are capable.
edit. For some context, I only use open weight models these days and rather hope that big closed firms go bust.
AI still needs lots of guidance, and might seem like a genius that does everything on its own, until you give it to people who can't guide it and things begin spiraling out of control.
I've been solo prenuering for the last year so didn't have a lot of data from others but your comment convinced me its a problem worth solving, so I put this together https://vitruvius.8by3.com/
Its hard wip, pushed seconds ago, paint still wet. But the idea is to "enforce" good architectural practices for your agents. Can store constrains and ADRs in git so everyone in a team (everyones agents) can read from the same page.
I try to avoid justifying my own existence, but its a reason why I think skilled engineers are way more productive using LLM's than person off the street. Because they can confine them. Though there is no technical reason that ability can't be codified.
"Slower" is doing a lot of work there. It's the difference between an engineer or two wrecking havoc doing a major refactor and convincing a manager that it's ok while you're away on vacation, and the same engineers failing to convince the manager because it will take forever, and quietly dropping the project after hitting the first roadblock.
"How long is this going to take?": "a week" vs "a quarter" makes a huge difference.
Extreme speed is a form of quality; the fear is that it enables bad things to happen.
They weaponize the HN rules here. Which is frustrating, because one has to break the letter to defend the spirit.
Or it could be a kid that watched too many tech YouTubers.
But, fundamentally, that doesn't matter, because functionally it's as described.
___
Huh, actually, if I look back on my extensive conversations with LLMs and compare those with human conversations, the whole idea of a greybeard memorizing manpages is something they liked to come up with much more than humans do (if at all).
The idea of a greybeard kinda died out in normal conversation a while ago. Mostly, at least.
Good job on the abliteration I suppose.
PS: Yes I mostly work from a laptop.
Like a PT for AI's ... Getting them into shape, and fighting strong.
This fake job title sounds like what BI analysts or analytics engineers should be doing as part of their job, not a new job. These jobs are the ones that are usually working on the modeling, answering business questions, and making data accessible and would be creating the context, prompts, and evals to make sure it's working as intended. I think really, analytics engineering and BI should be combined.