I found a piece of code that uses the first 16 bytes of the input file as IV. This immediately set off some flags in my head, but I have no idea how bad it really is. So, how bad is it? Obviously we're storing the first block in plaintext as the IV, but can we get any other information out?
As you have ascertained, a passive adversary can immediately learn the first 16 bytes if they didn't know them already.
The adversary will also immediately learn for any pair of messages how long a prefix they share: if the first block is unencrypted and the same, then the IV for the second block position is the same, and so if the second blocks are the same the ciphertext is the same, and so on recursively as for as many blocks as the messages share in common.
If the adversary can predict the first block of plaintext in advance and possibly control subsequent blocks, then the adversary can furnish two messages for the second block of plaintext to confirm whether you're storing them. (In disk encryption, this is called watermarking.)
If an adversary can control the first two blocks of plaintext, then they can build a codebook of the encryptions in order to verify guesses about other plaintexts for the second block. Padding oracles may compound the problem and leak more faster.
These are the first few things that leap to mind. There may be others. Generally, when you break the security contract of a crypto primitive, it's bad news. You should fix this as soon as possible and, if nothing else, adopt an authenticated encryption scheme like NaCl crypto_secretbox_xsalsa20poly1305. Ideally, you should write down a design document about what you're trying to do with what resources for whom, about your threat model, and about the security properties you want to provide, so that the next auditor or curious developer to come along can quickly assess whether your goals are reasonable and, independently, whether you've achieved them.
The danger I see with using the beginning of a file as the IV is that the beginning of files tend to be fairly predictable. For example. Linux shell scripts tend generally have a first line of "#!/bin/bash" - 11 characters (12 counting the Linux end-of-line LF character). If each file has a separate key this isn't much of a risk, but if the same key is used for multiple files then the IV reuse can result in problems (see this question or this question, or this question for examples)