By Mandar Chaudhari, Full Stack Geospatial Engineer, Land IQ | Researcher, George Mason University
Imagine building an application that helps a farmer understand how much water their fields are using.
You’ve got satellite-derived evapotranspiration data coming in, precipitation measurements from another source, field boundaries stored in a spatial database, and a dashboard that brings everything together.
Now suppose the precipitation data arrives before the latest evapotranspiration estimate. A field boundary has also changed, but one part of the processing pipeline is still using the older geometry.
The application might continue running without reporting a single error.
Adding a language model to the application wouldn’t automatically fix any of this. It might actually make the problem less obvious by generating a convincing explanation of an incorrect result.
This is a hypothetical example, but the underlying engineering challenges are common when applications bring together data from multiple sources.
It’s also why I think the conversation around AI will start changing in 2027.
We’ve spent a lot of time talking about what AI models can do. I think we’ll spend considerably more time talking about what it takes to make the applications around them dependable.
The model shouldn’t be responsible for everything
One of the more interesting changes I expect is that developers will become more comfortable giving AI a smaller role in an application.
That might sound strange considering how much attention AI agents are getting.
But consider a question like, “Which airports are within 150 nautical miles of this wildfire?”
A language model is useful for understanding the question. It can identify that the user wants airports within a particular distance of a geographic location.
The actual distance calculation, however, belongs somewhere else.
I’d rather send that request to a spatial database, use an appropriate geographic distance calculation, and retrieve the airports that satisfy the condition.
The language model doesn’t need to approximate the answer or invent a list of nearby airports.
It needs to help the user interact with a system that can calculate the answer correctly.
A financial application might need an exact calculation. A logistics platform needs reliable routing constraints. An environmental monitoring system needs to know which measurement belongs to which location and date.
In each case, the model can be useful without becoming the source of truth.
I expect we’ll see more applications built this way in 2027, combining generative AI with databases, specialized algorithms, and conventional application logic.
Good data engineering is becoming an AI problem
A lot of people talk about improving AI accuracy by choosing a better model.
Sometimes that’s the right answer.
But what if the model is receiving the wrong data?
Geospatial applications make this problem especially easy to understand because location, time, and measurement units all matter.
Suppose two environmental datasets describe the same agricultural area. One uses a geographic coordinate system, while the other uses a projected coordinate system. If the application handles the transformation incorrectly, a spatial join might associate measurements with the wrong area.
Or consider daily observations arriving from several providers. If one source reports values in local time and another uses UTC, records that appear to describe the same day might actually refer to different reporting periods.
Neither problem requires a more advanced AI model.
They require data validation, coordinate-system handling, timestamp normalization, and clear rules about how records are joined.
My prediction is that organizations investing seriously in AI will start paying much more attention to the infrastructure supplying the model with information.
That includes tracking data provenance, validating inputs, monitoring processing failures, and making it possible to trace an answer back to its original source.
These details rarely make impressive demos, but they matter when people depend on the results.
Sometimes a specialized model is exactly what you need
My aviation research at George Mason University offers a useful example of why I don’t think every AI application needs to revolve around a large language model.
Working with Dr. Lance Sherry, I’ve been involved in research examining commercial air-service opportunities at regional airports.
One of our projects uses machine learning to rank potential airline destinations based on the characteristics of an airport pair.
The approach considers regional demographics, economic activity, tourism-related indicators, airport characteristics, and patterns in existing airline networks.
The underlying model uses XGBoost, a gradient-boosted decision-tree algorithm, trained on historical airline service data.
We also developed an interactive application that lets users explore ranked destination opportunities for different regional airports.
What makes this interesting is that the model has a very specific job.
It isn’t trying to answer every possible question about aviation. It evaluates structured information and identifies airport pairs that resemble existing airline routes.
The resulting scores help prioritize destinations for further analysis. They don’t establish that a particular flight will be profitable or that an airline will start operating it.
A language model could eventually make the application easier to explore through natural-language questions. But it wouldn’t replace the underlying route-selection model.
I think this type of architecture will become more common.
Instead of choosing a technology first and finding a problem for it afterward, teams will increasingly choose different tools for different parts of a workflow.
That might mean using a traditional machine-learning model for prediction, a spatial database for geographic queries, and a language model for interacting with the results.
There’s nothing wrong with an application using several approaches. In many cases, that’s probably the more sensible engineering decision.
The failures that matter won’t always look like failures
Here’s another area where I expect software teams to change their approach in 2027: testing.
With conventional software, we’re used to checking whether functions return expected values, APIs respond correctly, and data processing jobs complete successfully.
Those checks still matter in AI applications.
But imagine a user asks an AI-powered environmental dashboard to compare water use between two fields.
The system returns a well-written explanation and a chart.
The request succeeds, but one field uses an outdated boundary while the other uses the latest geometry. The result looks correct, yet the comparison is unreliable.
This is where testing needs to go beyond checking whether software runs without errors.
We need to ask whether the correct data was retrieved, whether calculations were appropriate, whether results can be reproduced, and whether the system recognizes situations where it shouldn’t provide a confident answer.
I expect AI evaluation to become much more closely connected to the software development process.
Teams will need tests for individual model outputs, but they’ll also need tests for the complete workflow: data retrieval, validation, transformation, model execution, and presentation.
And those tests can’t stop after deployment.
The underlying data will change. External APIs will change. Users will find ways to ask questions that the original developers never considered.
Monitoring those changes will become a normal part of maintaining AI-powered software.
More automation doesn’t always mean better decisions
AI agents are becoming better at handling multi-step tasks, but greater autonomy doesn’t always mean better decisions.
Take our aviation route-selection research. A model can rank potential destinations from a regional airport, but it doesn’t account for every operational or commercial consideration. A high score doesn’t mean an airline should automatically launch that route.
The same applies to agricultural water management. Data can help growers understand water use, but actual irrigation decisions may depend on crop conditions, equipment, and other factors the system doesn’t capture.
I expect more organizations to design AI systems that support human judgment rather than trying to automate every decision.
What I Expect to Change
By the end of 2027, I think developers will be asking different questions about AI.
Instead of only asking which model performs best, they’ll spend more time asking where its data comes from, what happens when that data changes, how errors are detected, and which decisions should remain outside the model.
I don’t expect this shift to happen evenly. Some companies will continue building impressive demonstrations that never make it into regular use.
Others will spend months working through problems that are much less visible: database design, data integration, testing, monitoring, and application reliability.
Those are the projects I find more interesting.
The next stage of AI development isn’t just about making models more capable. It’s about building software around them that still works when the data is messy, the conditions change, and the results actually matter.
—
ABOUT THE AUTHOR
Mandar Chaudhari is a software developer at Land IQ and a researcher at George Mason University’s Center for Air Transportation Systems Research. His work focuses on geospatial software development, environmental data applications, aviation analytics, and applied machine learning. His research includes developing AI-based approaches to evaluating commercial air-service opportunities at regional airports.
