Everybody sabi say generative AI fit make real-real pictures, illustrations, and paintings just by tellin' am wetin to do.
But for business world, pipo dey focus on wetin generative AI fit do for program generation.
Conversational AI dey work with large language models, wey be like foundation technology, and e dey do well for talkin' different languages and translating between dem.
Programming languages, wey dem dey use to create programs, na also one kind of language. Human programmers, for one sense, dey translate software requirements wey dem hear into programming languages.
Na because of dis say conversational generative AI, wey dey use large language models, sabi programming well-well.
Wetin pass dat, programming na intellectual task where dem fit check if di results correct automatically and sharp-sharp. Dis na because dem fit run one program wey dem create and automatically check if e give di result wey dem want.
In fact, when human programmers dey create one program, dem dey often create test programs at de same time to check de results, dey develop de main program while dey check say e dey work as dem want.
Generative AI also fit dey program while e dey test, di same way. If human give am clear instructions, e possible say di AI go automatically try different things and finish de program until e pass all de tests.
Of course, because of wetin generative AI programming fit do and how human instructions fit no clear, plenty times de tests no go pass even after plenty trials. Also, when tests no thorough or dem make mistake, plenty times de program wey dem finish go get bugs or problems.
But as generative AI dey get better, and human engineers dey make their instructions better, plus di ways wey dey boost generative AI programming knowledge through internet searches, di scope for automatically generating good programs dey expand everyday.
Adding to dat, as business world dey focus on am, top companies wey dey do generative AI research and development also dey invest heavily to make generative AI programming capabilities better.
For dis kind situation, dem expect say how much and how many automated programming tasks dem fit give to generative AI go increase sharp-sharp.
Plenty pipo wey never develop programs before don set up simple development environment using internet information, then dem depend on generative AI for programming, finishing projects together as a team of two.
As a programmer myself, I dey use generative AI for programming. Once I sabi how e dey work, I fit finish software without editing de program at all, just by copying and pasting code into files according to generative AI's instructions.
True true, plenty times I dey get stuck. Dis na mostly because of small differences between my computer or programming development tool settings and normal setups, or because free software components dey newer than wetin generative AI don learn, wey dey cause one gap in knowledge, or because my requests dey a bit unusual.
For cases wey no get dis kind small differences or special situations, and when dem tell am to create very common software functions, e dey generate good programs for most situations.
To Di Liquidware Era
As a software developer, I fit release di software wey I create, and dat software, wey we engineers release, go come dey used by different different users.
Di future where anybody fit do dis software development with generative AI na extension of di talk wey we don talk so far.
But, dis one no be just change for di software development side; big changes also dey come for di user side.
Di work of tellin' generative AI wetin to do with mouth to automatically add or change functions for software fit dey done not only during di development stage before software release, but also during its use. Wetin pass dat, di software user self fit do am.
Software developers fit define wetin dem fit change and wetin dem no fit change, then release software with generative AI-powered customization features.
Dis one go allow users to ask generative AI to change small small inconveniences or screen design preferences inside di software.
Wetin pass dat, users fit add useful features wey dem see for other applications, combine plenty operations into one single click, or view screens wey dem dey always access all for one display.
For software developers, allowing dis kind user customization dey offer big benefits: e comot di stress of dem self dey implement feature requests, and e fit boost software popularity by avoiding bad reviews and dissatisfaction over how easy e dey to use.
When users fit freely change screens and functions for dis way, di concept go dey very far from wetin we normally dey call "software."
E go make more sense to call am "Liquidware," wey mean say e dey even more fluid and fit adapt pass software (wey don already dey more flexible pass hardware), and something wey perfectly fit di user.
Before, hardware alone dey do functions. Then, interchangeable software come out, wey make functions possible with combination of hardware and software.
From there, we fit imagine say Liquidware go come out, wey mean parts wey generative AI fit modify. So, functions go dey realized by hardware + software (wey developers provide) + Liquidware (user modifications).
For dis Liquidware era, users' ideas for modifications go explode.
One groundbreaking modification idea wey one user invent fit become a hot topic for social media, wey go make other pipo follow and modify different Liquidware applications.
Wetin pass dat, Liquidware wey fit handle different software applications for one integrated way also likely go come out. Dis one mean say users fit view timelines from plenty different social media platforms for one app, or search results fit integrate wetin dem find from plenty platforms.
For dis way, for one world where Liquidware don widespread, different devices, including PCs and smartphones, go dey provide functions wey perfectly fit each of our individual lives and activities.
One Tin Wey Dey Happen Now
For software engineers like me, e very important to understand say Liquidware no be something for future or something wey go happen in some years time.
Dis na because even simple Liquidware don dey possible already.
For example, make we say I be engineer wey dey develop web application for my company's e-commerce site.
Dat kind web app go get databases, sales management systems, and product shipping systems for servers wey dem dey manage in-house or through one cloud service. When one user buy something, dis systems go link up to handle payment collection and send out di product.
Core business systems and databases like dis, dem no fit just change am anyhow.
However, di design of one user-facing e-commerce site's web screen fit dey modified to fit individual users without causing big problems. Of course, if one user's changes affect other users' screens, dat one go be problem, but individual user-specific customizations dey fine.
For example, plenty modifications fit happen: makin' text bigger, changin' background to dark color, movin' frequently pressed buttons to one position wey easy for left-hand operation, sortin' items by price on one list screen, or displayin' di details of two products side-by-side.
Technically, dem fit achieve dis modifications by changin' di configuration files and programs like HTML, CSS, and JavaScript wey dey show di screen for di browser.
From security side, dis files originally dey run on di web browser. So, parts wey one engineer wey sabi web apps fit modify, only dey handle functions and data wey safe to modify.
So, for di e-commerce web app's server side, dem fit create one system to store dis files separately for each logged-in user, add one screen for conversing with a chat AI, and then modify dat user's HTML, CSS, and JavaScript files on di server according to their requests.
If dem present dis text, along with di existing e-commerce web app's configuration information and source code, to one generative AI, e go likely provide di steps and necessary programs to add dat kind functionality.
For dis way, Liquidware don already be current topic; e no go surprise if e be ongoing phenomenon right now.
Omnidirectional Engineers
Even if AI dey drive automated programming wey dey expand and di Liquidware era don start, generative AI alone still no fit handle software development completely.
But, e sure say how much importance dem dey give to programming for software development go reduce well well.
Wetin pass that, to develop software smoothly, you go need plenty knowledge and engineering skills, from general programming to cloud infrastructure, networks, security, platforms, development frameworks, and databases—all through di system stack, for de whole system to work.
Pipo wey get dis kind knowledge and skills dem dey call dem full-stack engineers.
Before-before, small number of full-stack engineers go handle de whole design, while di other engineers go focus on programming, or focus on specific non-programming areas inside di system stack, so dem go divide de work.
However, as generative AI dey take over programming, software development costs go reduce plenty, wey go lead to planning of different different new software development projects.
Because of dis, for each development project, engineers wey fit just write programs go no really dey necessary; instead, plenty full-stack engineers go dey in demand.
Wetin pass that, for dis situation, just having full-stack knowledge and skills no go be enough. Dis na because di kind software wey dem go need for different development projects go diversify, meaning say dem no go always request development using di same system stack. Wetin pass that, demands for complex systems wey need plenty system stacks go surely increase.
For example, de system stack for one web application dey different from dat for business or core systems. So, dem no fit give one full-stack web application engineer one core system development project.
The same way, web applications, smartphone apps, and PC applications all get different system stacks. For embedded software, like IoT, de system stack go dey completely different for each embedded device wey dem embed am inside.
However, as de importance of programming dey reduce and overall software development costs dey fall, de development of complex systems wey dey combine software with dis different system stacks go likely increase.
Even if dis kind development go need plenty different full-stack engineers to come together, engineers wey fit oversee de whole system and handle basic design go play a very important role.
Dis one mean say dem go need engineers wey get omnidirectional knowledge and skills across plenty system stacks, wey go pass de boundaries of individual system stacks.
Dem go likely dey call dis kind engineers omnidirectional engineers.
And just as de demand for engineers wey fit only program go reduce because of generative AI, one time go surely come when de demand for full-stack engineers wey just dey for one single system stack go also reduce.
If you want to still dey active as an IT engineer for dat era, you gats start now-now to follow de path to become an omnidirectional engineer.
Wetin Omnidirectional Engineers Dey Do
Di programming languages, platforms, and frameworks wey go dey developed plenty and different.
But, one omnidirectional engineer no need to sabi all of dem well-well, because dem fit also get help from generative AI.
If you leave am for generative AI, even programming languages, platforms, or frameworks wey you never use before fit dey generated just by giving am instructions with mouth.
Of course, e get risk of introducing bugs or security problems, or plenty technical debt wey fit make future changes hard.
To identify and reduce dis risks, knowledge of di specific language or library dey necessary. But, dis knowledge also fit dey gotten from generative AI. An omnidirectional engineer only need to sabi how to build strong procedures and mechanisms for detecting and preventing dis issues, or for handling dem after dem happen.
Dis procedures and mechanisms no dey change drastically with different system stacks. If di procedures and mechanisms for preventing bugs and security problems and ensuring future extensibility dey formalized, then di rest fit dey left for generative AI or engineers wey specialized for those specific areas.
Omnidirectional engineers no need to get detailed knowledge or long-term experience with every single system stack.
One of di major roles of an omnidirectional engineer na to design how functions go dey shared and how multiple complex software systems, wey dey work together across different system stacks, go interact with each other.
Wetin pass dat, thinking about how to develop and manage di whole software na also a crucial role for an omnidirectional engineer.
Omnidirectional Software
Make we look at wetin kind of software development an omnidirectional engineer dey needed for.
Before, I talk about di example of developing an e-commerce web application.
Under di order of an executive wey top management give work to refresh dis e-commerce web app, di planning team fit come out with dis requirements:
User Community Platform Integration: Dis one mean say dem go provide one platform no just for a dedicated e-commerce app or site, but where users fit interact about di products demsef and how to use dem. Di aim na to keep users, make pipo talk good about am, make content plenty through wetin users contribute, and join feedback (both good and bad) into product development, new product planning, and marketing.
Omni-device compatibility: Dis one dey make di user community and product information accessible from different devices, including not only web apps but also smartphone apps, voice assistants, wearable devices, and smart home appliances.
Omni-platform compatibility: Dis one include not only di company's own user community platform but also, for example, product listings and review sharing on big e-commerce sites, integration with social media, and functional and information linkage with different AI tools.
Business system refresh: While dem dey temporarily link with existing sales management and product delivery systems, dis one also involve refreshing dis systems. After refresh, di plan include real-time sales data aggregation and demand forecasting, and integration with inventory management systems. Wetin pass dat, linkage with regionally distributed inventory systems wey delivery companies provide and delivery services on di carrier side go dey phased in, wey go require di information system to gradually adapt its integrations accordingly.
Liquidware compatibility: All user-facing interfaces go, of course, be Liquidware compatible. Wetin pass dat, internal user interfaces for product development and planning (like information aggregation and feedback), system operations departments, and reports for management go also all be converted to Liquidware.
If dem present one development plan for dis kind complex software, one traditional software development team probably no go accept am immediately. Or, through discussions about system specifications, dem go logically show say e go need plenty plenty development costs and time, wey go make dem cut down di specifications well-well.
However, wetin if generative AI fit automate most of di programming, and more than half of di proposed system stacks bin already experienced by somebody for di team? And wetin if di team get one track record of successfully launching new system stacks, platforms, and frameworks from scratch with di help of generative AI? And wetin if you, as an omnidirectional engineer, don already start for dis path and dey intend to continue for am?
From dat perspective, e suppose look like a very attractive project. You go get to work with a planning team wey dey bring ambitious proposals from top management, and a development team with di potential to grow into an omnidirectional software development team.
E get also di peace of mind of existing systems. E also be a project wey dem fit grow small-small through an agile development process, starting with quick-win, high-impact features and gathering feedback from early adopter users.
Considering all dis, di development of dis omnidirectional software suppose look like a very attractive project.
Conclusion
With automatic programming wey generative AI dey drive, Liquidware and omnidirectional software development don already turn to wetin dey happen now.
For dis situation, IT engineers dey need to pass full-stack and aim to become omnidirectional engineers more and more.
Wetin pass dat, their scope go expand even more, moving past just IT systems to include omnidirectional business engineering—wey mean say dem go engineer organizational activities demsef, by connecting customers, internal employees, and AI—and omnidirectional community engineering.
And wetin pass even dat, I dey see say one field wey dem call omnidirectional social engineering go come out, with de aim to improve society completely.