I don't think organization will be able to do this themselves. Transforming vague ideas into a product requires an intermediary step, a step that is already part of our daily job. I don't see this step going away before a very long time.
Non-tech people have the tools to create website for a long time, though, they still hire people to do this. I'm not talking about complex websites, just static web pages.
There will simply be less jobs that there is today.
Regarding job security, in maybe 10 years (human and companies are slow to adapt), I think this revolution will force us to choose between mostly 2 career paths:
- The product engineer: highly if not completely AI driven. The human supervises it by writing specification and making sure the outcome is correct. A domain expert fluent in AI guidance.
- The tech expert: Maintain and develop systems that can't legally be developed by AI. Will have to stay very sharp and master it's craft. Adopting AI for them won't help in this career path.
If the demand for new products continue to rise, most of us will be in the first category. I think choosing one of these branch early will define whether you will be employed.
That's how I see it. I wish I can stay in the second group.
> - The product engineer: highly if not completely AI driven. The human supervises it by writing specification and making sure the outcome is correct. A domain expert fluent in AI guidance.
If AI continues to improve - what would be the reason a human is needed to verify the correct outcome? If you consider that these things will surpass our ability, then adding a human into the loop would lead to less "correct" outcomes.
> - The tech expert: Maintain and develop systems that can't legally be developed by AI. Will have to stay very sharp and master it's craft. Adopting AI for them won't help in this career path.
This one makes some sense to me but I am not hopeful. Our current suite of models only exist because the creators ignored the law (copyright specifically). I can't imagine they will stop there unless we see significant government intervention.
When the design closely aligns with the real world problem it solves, communication pathways are natural and you don't really have to care much about them.
What matters is the Actor's role and making sure it represent a strong domain concept. The rest follows naturally.
But to be fair, it's never that simple and you always end up with some part of a system that's less "well-designed". In that case,figuring out who talks to who can quickly become a nightmare.
Actors are great on the paper, but to benefit from them, you need great understanding of your domain. I tend to use it later in the development process, on specific part where the domain is rich and understood.
I worked for multiple companies remotely and the thing that worked the best for me was:
- Everyone must be connected to Discord in an audio room.
- Encourage pair programming.
- Record every meeting make them available to everyone.
- Log every decision in a central place, easy to browse and discover.
- Meet regularly (IRL) with you colleagues.
By far the most important point is always being on Discord. You can quicky jump in someone's room and feel very connected to your teammates. Obviously, like in a real office, don't disturb someone if it can be managed asynchronously.
If you like Caddy for it's ACME capabilities, then you might enjoy Traefik as well. It supports HTTP, TLS ALPN and DNS challenges and can be configured in one line as well.
I already use it as a web server and reverse proxy so it's a better match. I've tried traefik in the past and it wasn't as simple as caddy to configure. Caddy has some well thought out magic (like creating a sane modern php config with just one line).
But we could argue that if webapps were more used on mobiles, new APIs would have been opened to facilitate cross-app integrations.